支付体系(三):支付产品之收银台设计详解
编辑导语:随着移动支付的发展,人们越来越习惯于无现金的生活。用户在移动端进行支付、账户充值时最常用的功能模块就是收银台,本文作者从项目实践出发,对收银台功能设计的流程以及过程中需要注意的问题进行了梳理盘点,与大家分享。
线下购物场景中,收银台是顾客在超市最后停留的地方。互联网的发展,线下场景转移到线上,线上的收银台也是用户在网站最后的停留位置。
交易的存在是支付发生的前提,使用支付方式让交易完成,支付是交易达成的最后一个环节,这通过支付产品之一的收银台来实现。
公司内部往往有多条业务线,凡是商业活动一定涉及收款,支付系统扮演平台的角色,为多条业务线提供收款能力,接入的业务线我们称之为商户。
支付平台向商户提供C端支付产品和B端商户平台两种类型的支付产品。商户接入一种C端支付产品向用户提供支付服务,同时使用B端商户平台向C端支付产品进行功能配置,这样商户就具备了收款能力。
今天重点讲C端支付产品的收银台。
之前有一些人问到我,支付还需要专门的产品经理吗?接入国内的支付宝和微信不就完了嘛。事实上,大家看到的支付只是冰山一角,仅看商户平台的功能模块中,风控、路由、对账等都是大家看不到的后台支持模块,前端觉察不到却需要花很大功夫去做。
一、概念解释
以支付平台的角色来看(支付平台往往接入多家支付渠道,比如支付宝、微信支付和京东支付等),需要解决公司各个业务线在不同场景下,对收银台提供支付方式的不同需求。
所以收银台有两层概念,分别为:能够提供的收银台类别以及各种收银台上能够支持的支付方式及提供支付方式的支付网关。这里涉及到三个名词概念:支付产品、支付方式和支付网关。
1. 支付产品
适用不同业务的不同场景的API接口,不同收银台类型即不同的支付产品。这里定义了四类:
- PC收银台:电脑PC端完成支付的收银台;
- H5收银台:手机内的H5网页上完成支付的收银台;
- APP收银台:商户APP内完成支付的收银台(APP上使用,不含前端页面);
- API收银台:提供给商户自己进行包装成自己收银台前端页面的底层接口(不含前端页面,商户自己设计前端页面)。
不同的支付产品有不同的优缺点,比如PC和H5收银台相较于API收银台,商户接入不需要开发前端页面,接入后可直接使用,但缺点可能是与上游的业务系统UI风格不一样,所以商户接入时要视自己的实际情况而定。
大家对支付方式这个概念很熟悉,对支付产品这一概念可能陌生。事实上,支付宝、微信支付等对支付产品有明确的定义。
例如微信支付根据用户不同的支付场景定义了不同的支付产品:付款码支付、APP支付等。
在APP上使用微信支付时,我们常常称作微信支付,但从微信支付产品角度看,称APP支付。(大家可以自行去微信支付开发文档上查阅)
2. 支付方式
不同支付产品的支付方式在支付流程时可能会有差别,比如PC收银台的支付宝是外跳转到支付宝收银台页面。但用户在浏览器中访问商家网页应用,选择商品下单、确认购买,进入支付环节,选择支付宝付款,用户点击去支付,进入到支付宝支付路由页面。
3. 支付网关
PC收银台的支付宝和H5收银台的支付宝,这两种支付方式对应的支付网关都是支付宝网关。
不管是接入PC支付宝还是H5 支付宝,首先都需要商务层面先签约,同支付宝签约这两种支付产品,成为我们支付平台的两种支付方式,进而支付平台的两种支付产品也得到丰富和完善。
总的来说,支付网关是为了提供不同类型的支付方式,多种支付方式丰富了支付产品,支付产品向公司不同业务提供服务。
业务的持续发展需要不断完善支付产品,比如线上拓展到线下,那就需要新增线下的一种支付产品,进而也需要对应线下的支付方式和支付网关。
支付方式和支付网关并不是1:n的关系,有些支付方式并不仅仅通过一种支付网关来提供,比如招行快捷支付,既可以通过支付宝网关也可以通过银联网关,从系统稳定性或者商务层面的网关费率等因素考虑,同一支付方式对接不同的支付网关也是支付平台要拓展的方向。
二、收银台产品设计思路
1、明确用户目标。明确用户使用你的产品要完成什么任务,这里用户使用收银台是要完成支付。
2、拆解用户行为路径。根据用户行为过程:触达-参与-完成,拆解用户使用收银台这一产品的支付过程:支付前-支付中-支付后,在这三个阶段中用户分别有在该阶段要做的操作行为。
3、为每个阶段找到对应的产品目标。产品是用户行为的载体,产品必须要有目标,这样才能聚焦。收银台的总目标为安全、简单,至于为什么是这两个目标,这得从支付的起源说起。
在近二十年来,支付方式经历了不少演变。支付方式从最早的现金交易,到后来的刷卡消费、线上支付,以及分期支付。支付这些年一直在变化、在丰富、在演进,但它一直在解决两个核心问题:信任和效率,对应到支付产品上来,即是安全和简单。
4、找到衡量产品目标的数据指标。产品好不好,数据来说话。用户操作行为的各个阶段指标为时长和转化率,但北极星指标为用户从达收银台列表到支付完成,获取支付结果这一整个订单成功转化率。
三、收银台功能设计
整体上分三块:用户使用的收银台前端页面、商户对收银台进行配置的商户平台和看不见的支付系统。
3.1 收银台
按照前面讲到的用户行为路径支付前-支付中-支付后列举功能点依次为:
(1)页面的通用模块
页面的标题、底部的一些信息展示。
(2)订单相关信息展示
订单有效时间。业务系统告知,订单有效时间可能不唯一,比如常规订单也许1小时,但是活动订单也许15min。
订单待支付金额。订单需要支付的金额,业务系统告知,值是唯一不变的,即使用余额、礼品卡等和支付宝组合支付,该值也不应该变,表明订单需要被支付金额,而不管使用何种支付方式支付。
商品信息和发货信息。业务系统告知,非必须字段,看商户订单类型,如苹果官网主要售卖高客单价商品,用户对商品和地址会更关注。
(3)支付方式展示
涉及到可展示出来的支付方式有哪些以及这些支付方式的的排序规则。
(4)默认支付方式选中规则
默认让用户使用哪种支付方式,减少用户的操作成本(直接选择底部确认支付按钮发起支付)。可以用户自定义设置,比如京东的收银台默认支付工具。
也可以采用动态策略。动态策略一般从几个方面考虑:用户最近使用的支付方式、用户最常用的支付方式、限额满足条件、公司推广的支付方式等,这个要根据公司的业务发展来综合考量默认支付方式的展示规则。
(5)营销信息展示
支付也涉及营销,比如分期支付方式的免息配置,某种支付方式的推广,与银行或通道洽谈的优惠
政策,例如,绑定XX银行的卡享受随机立减优惠等。
(6)确认支付
确认支付后,支付系统和第三方网关开始交互,调用后端获取支付参数和支付网关,请求网关发起支付请求。确认支付时还要考虑此时是单一支付,还是组合支付或者是拆单支付。
用户选择支付方式,确认支付后,开始发起支付。不同的支付方式支付流程有较大差异,这里以商户的H5收银台,用户选择支付宝支付,且用户已安装支付宝为例。
- 用户在浏览器中访问商家网页应用,选择商品下单、确认购买,进入支付环节,选择支付宝付款,用户点击去支付,如下图 1;
- 进入到支付宝支付路由页面,支付宝处理支付请求,并尝试唤起支付宝客户端,如下图 2(此页无法自定义删除);
- 进入到支付宝页面,调起支付宝支付,出现确认支付界面,如下图 3;
- 用户确认收款方和金额,点击立即支付后出现输入密码界面,如下图 4;
- 输入正确密码后,支付宝端显示支付结果,如下图 5;
支付后用户主要是回到商户网站确认订单支付状态,商户也要根据支付结果个性化展示订单处理结果。
3.2 商户平台
向商户提供配置收银台的一些功能,以下为主要功能模块介绍。
- 接入商户信息配置,如商户号等信息。
- 渠道中心。渠道的账号配置、渠道是否可用、渠道关联的支付方式等配置。
- 支付方式中心。支付方式禁用策略、支付方式排序策略配置。
- 风控中心。黑名单、风控规则引擎、风控告警等配置。
- 路由中心。支付渠道的分流规则配置,在不同端,不同业务和商品,不同的用户,可以使用什么支付渠道。
- 营销中心。免息、支付方式推广等配置。
3.3 支付系统
看得到的支付产品后面一定有看不到的系统支撑着,这是支付系统。这里只做简单讲述。
用户进到收银台列表,支付系统会当前的业务订单生成一笔自己的支付订单,用户每选择一次支付方式,支付系统会请求第三方创建一笔交易,交易中的交易号用来跟第三方网关交互,同时支付系统也会创建一些参数向第三方网关发起支付(发起支付成功,第三方页面才会打开),若用户支付成功,支付系统还会将该笔交易流水推送给财务系统,供财务进行对账查询。
四、总结
以上为收银台的简要介绍,可以发现,大家看到的某电商收银台这层皮,其实只是冰山一角,真正在解决问题的,是多数人都看不到的水面下的血肉和骨骼。
如果你想从0到1设计一个收银台,需要先做好以下几个准备:
(1)了解公司业务模型
知道业务是怎么样的,售卖的是什么商品,是电商、游戏、课程售卖等等。其实就是卖什么,怎么卖的问题。假设是电商平台,卖的是实物商品,假设售卖课程,卖的就是虚拟商品,实物商品和虚拟商品要考虑的业务规则肯定不同。
(2)选择支付方式
想好计划为用户提供什么可用的支付方式,比如微信支付,支付宝支付,银行卡快捷支付,账户余额支付?一般微信支付宝就够了,难免有用户想直接绑定信用卡去支付,虽然通过微信支付宝也可以使用信用卡支付;这个看平台选择,如果有能力尽可能给用户更多的选择,覆盖更多的用户群体需求。
(3)签约支付通道
支付宝或者微信的某一支付产品,不能直接接入,首先要合同签署。
(4)确定收银台的支撑系统
收银台要想能完成支付至少需要哪些系统,账号、渠道和支付方式的数据结构是怎样的,哪些功能做成可配置,这些要提前做好技术方案。
(5)根据网关提供API文档接入
最后一步根据网关提供的API文档接入支付和退款流程即可。
#相关阅读#
#专栏作家#
花开不败,微信公众号:涵小仙女,人人都是产品经理专栏作家。文艺女青年一枚,白天工作,晚上码字,爱美、爱跑步、爱旅行,愿我手写我心,余生不将就。
本文原创发布于人人都是产品经理。未经许可,禁止转载
题图来自 Unsplash,基于 CC0 协议
专栏作家
涵小仙女,微信公众号:涵小仙女,人人都是产品经理专栏作家。文艺女青年一枚,白天工作,晚上码字,爱美、爱跑步、爱旅行,愿我手写我心,余生不将就。
本文原创发布于人人都是产品经理,未经许可,禁止转载。
题图来自 Pixabay,基于 CC0 协议
该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。
写的很不错,多来点。
这篇很棒,有逻辑,有图表,说明也很清晰。
老板写的棒棒哒。这是第三方支付的场景,能分享下第三方支付平台与银行的实现,包括对账之类的
(二)咋找不到
看你作者几篇文章,感觉思维都很连贯
写的很棒,感谢
你好,能和你学习下B端支付产品的设计么 wx:zzw19930428
请教下,企业在平台注册成商家后,我们平台自动分配商家一个虚拟的资金账户(用于入金出金转账),资金账户的支付密码,是每个员工都可设自己的支付密码吗?还是一个资金账户只有一个支付密码?
肯定是一个子账户(商家的后台)唯一的支付密码。。熊dei
入行支付行业没多久,有好多坑还等着我填呢,表示想加你某个联系方式,请教问题
赞
好像没有系列2哦
太棒了,给小白普及了一大波知识。