各位小伙伴,大家好!

每天我们都会通过形形色色的收银台完成与各种买卖交易,顺畅的体验可能会让你觉得到支付只是一个收银台。
然而好的产品千篇一律,烂的产品千奇百怪,很多体验很差的收银台让你以为“怎么连一个页面都做不好”。
本日我就来给大家先容一个标准版的收银台产品,通过标准形态的理解,让你能够举一反三在不同场景下都能设计出体验良好的收银台。

收银台高低折叠门_万字长文四段式收银台设计 实木门

【老规矩,以为大略或者啰嗦的同学,直接翻到末了看总结】

一、支付收银台先容1. 收银台的终端

图1:支付终端类型

支付终真个目的是通过场景适配为用户供应体验良好的操作体验,并且也是为了担保用户的支付安全。

1)场景适配

现在手机、柜面、自助设备、网站等交易场景很多,因此就要给出适配各种场景的收银台供应给客户去利用。

2)操作体验

原始的支付办法都是一些须要技能开拓的接口,因此须要通过各种终端页面来担保用户操作的体验流畅,这样才能给商家带来更好的支付转化率。

3)支付安全

支付安全紧张是两方面,一方面是通过增加“密码、刷脸、指纹、安全证书”等办法担保用户支付的安全。
另一方面是通过“终端与渠道”绑定,减少中间机构和做事商进行路由套利的机会。

2. 收银支付办法

图2:支付办法变迁

一个大略好用的收银台背后是“支付办法”,而支付办法背后则是对于出渠道供应的支付产品的包装。
支付办法的浸染一方面是向用户展示他可利用支付渠道有哪些,另一方面通过钱包、二维码、刷脸等办法包装提升用户支付效率和体验。

支付办法从现金到二维码经历了一个比较长的发展过程,所有的支付办法都是从早期柜面上现金交易的卡、折、电汇、信汇发展而来的。
而能够进行网络和移动支付的紧张分为“卡基、账基、条码”三类。

1. 卡基支付

图3:卡基支付

卡基支付是指以银行卡为介质进行支付的形式。
这也是最根本的一种支付办法,只要你拥有一张储蓄卡或者信用卡就能进行支付。

1)POS刷卡

这是最早的一种电子支付办法,也是一种线下的支付办法。
通过POS机具让你在线下门店、商超刷卡支付。
后来又演化脱手刷、智能POS支付等产品。

2)快捷支付

这是最早的一种移动支付办法,通过线上绑卡就能进行网上的支付和消费。
也是移动支付最盛行的支付产品,由于他可以摆脱实体卡的束缚通过手机方便的支付。

3)网银支付

早期的网银支付是须要通过PC电脑跳转到银行的网银上进行大额的支付,现在网银支付也逐步开始移动化方向发展了。
而传统的PC端操作的网银更多的运用在大额支付、企业支付的场景中。

卡基支付虽然在早期移动支付中起到推动浸染,但是其利用起来并不是很方便,POS刷卡你就须要携带银行卡在身边,快捷支付你须要在不同的平台绑卡,网银支付你要安装加密插件或者携带U盾。
因此账基支付应运而生。

2. 账基支付

图4:账基支付

基于账户的支付办法,他紧张是在银行账户、支付账户、数币账户上包装出来的钱包账户。
这种支付办法依托于互联网支付平台大量的实名认证的用户体系,通过他们的供应的账户体系,商家接入后用户不须要再进行繁琐的实名认证,直接就能进行消费。

比如电商类平台就普遍接入了微信、支付宝、云闪付的支付产品,由于用户已经完成实名,交易转化率非常的高。

3. 条码支付

图5:条码支付

这里紧张是指面向各种二维码进行线上订单码,线下机具、码牌等一体化的支付办法,当然他实质上是对银行卡、账户的一种深度聚合包装。
这里二维码又按照“商户”和“用户”维度分为三种形式。

商家静态码:这因此收款商家的商户号天生的二维码,紧张做出静态码牌,云喇叭等形式用户扫码后输入金额付款,这种二维码适宜做出聚合码支持多种APP来支付。
商家订单码:这种是根据商家吸收到的商品订单来天生的二维码,用户无需输入金额直接按照订单支付即可。
这类紧张用在自助设备和网站上供用户支付。
用户付款码:他是根据用户的收款账号天生的付款码,商家通过扫码枪或者盒子扫描用户APP展示的付款码完成收款。

3. 收银交互体验

图6:支付三步式体验

“你为什么一个页面要做这么久”,实在这是对收银台的误解。
如果你利用过开户、绑卡和实名认证,该当知道在未实名的情形下收银台的支付办法开通还是比较繁芜而繁琐的,只是在微信、支付宝的大量实名用户支撑下让你以为大略而已。

收银台除了支付办法包装外,他的用户流程经由微信、支付宝的市场教诲之后也是基本上是一套标准的流程。
我们可以把它分为支付前、支付中、支付后三个阶段。

1)支付前

这便是用户看到第一个支付页面,他分为订单和支付办法两部分。

订单信息:是给用户展示“商品订单”、“交易金额”、“商家名称”等大略的支付信息,让用户确认是否要进一步支付。
支付办法:是供应用户选择通过什么账户来进行付款。
这里支付办法就须要尽可能的丰富了,由于用户都下单了,如果由于没有得当的支付办法而放弃支付,那就太可惜了。
因此这里除了银行卡、账户以外,还有货币基金、授信额度等多种支付办法供你选择,总有一款适宜你付钱。

2)支付中

用户选择了支付办法点击确认后,就要进入支付页面了让用户完成支付了。
如果用户选择的是银行卡、账户支付,收银台会跳转到本地的支付页面;如果是微信、支付宝、银行APP、数字公民币等外部供应的支付页面,须要跳转到渠道的供应的收银台完成支付。

用户支付成功后须要跳转回来连续下一步操作,这时候由于两边系统短缺交互,因此分四个步骤来进行,页面跳转、支付回调、结果查询和用户关照。
以确保“页面、账务系统、接入商家、用户”四方都能同步到支付结果。

3)支付后

跳转回来后,给用户展示的页面紧张分为“支付结果”和“营销活动”两部分。

支付结果:便是用户支付这笔订单的终极结果,结果页面的正常展示解释渠道、本地都已经同步结果了,如果没能正常展示则须要提示用户去主动查询订单结果。
营销活动:营销活动是个可选项,并不是每个收银台必须的。
可以配置内部的推举产品和活动,也可以配置外部的营销活动(例如微信点金操持)等。

二、收银台业务架构

收银台由于涉及用户支付操作的全流程,因此他的“战线”拉得也比较长。
它与“终端,网关、收银做事、支付做事”紧密协作,为用户供应良好的支付体验。

1. 业务架构先容

图7:收银台业务架构

终端:它是用来适配各种支付场景,例如“h5支付”页面要供应定制化的勾引页面,支付后的活动页面。
“APP支付”要供应可以给商户APP集成的SDK,收银设备要供应不同设备环境内的“运用APP”等。
同时收银终端也要为客户供应“安全证书、密钥”等安全加密机制,以确保终端和网关之间的交互安全。
网关:网关是对外供应各种的做事接口给商家平台和终端设备进行调用,并且卖力根据要求处理对后端调用。
对吸收银台的网关紧张分为“收单网关”和“会员网关”两类。
收单网关卖力“收款、分账”等支付要求的处理;“会员网关”卖力“充值、付款、开户、绑卡等”账户要求的处理。
收银做事:收银台做事紧张用来卖力“收银台访问”,“收银台展示”,“交易过程处理”。
它向前端供应收银台做事的接口,收银台展示和交易处理的流程,以及对后台支付做事调用。
支付做事:他为收银台供应后台支撑做事,内容包括“商户系统”、“支付渠道”、“账户系统”、“交易系统”、“实时风控”等多个别系。

2. 收银台用例先容

图8:收银台用例

1)收银台业务边界

网关访问:收银台对外供应“收银台做事接口”,吸收来自收单网关、会员网关的支付要求。
客户系统:收银台对“客户系统”紧张是访问“会员认证”和“商户产品”配置。
个中“会员认证”用于对用户支付办法对应的“银行卡”和“账户”进行信息验证,同时也可以扩展“绑卡/开户”的操作。
收银台本身是商户签约产品的一部分,因此收银台的配置是从商户签约产品中得到信息。
支付系统交易做事:为收银台供应收款、充值、付款,以及收款成功后交易分账处理。
支付渠道:如果渠道也有类似“小程序、APP、H5”的收银台,须要通过本地收银台与渠道进行“获取、拉起和回跳”等访问和处理。
实时风控:对交易限额、限次等实时风控规则对收银台交易检讨,即时拦截用户支付时监测到的风险。

2)收银台用例解释

收银台接口:收银台供应给外部的做事接口,包括“地址获取、页面获取、回调处理、结果查询”等;收银台做事:收银台做事的主控做事,通过读取商家的收银台参数来掌握页面展示和交易处理流程。
支付办法:以接口或者页面的形式,供应收银台支付办法的信息的查询,以及在收银台上对付绑卡、开户操作的扩展。
支付页面:按支付前、支付中、支付后三个步骤来操为难刁难应的支付页面。

三、收银台事情事理

随着移动支付的推广,以及微信/支付宝的长期的市场教诲,他们四段式收银台交互标准,已经成为事实上的行业标准。
节制这个标准流程,做个收银台实在很大略。

图9:收银台“四段式”交互流程

1. 标准四段式交互

1)支付下单

这是支付的第一步,我们选择商品下单后就会进入“收银台页面”向你展示支付金额,商品择要信息,让你选择支付办法,你确认后就会向后台下单。

2)调用收银台

下单后做事端会返回一个收银台参数,得到这个参数后支付平台就能拉起收银台让用户跳转完成支付了。
如果用户选择的“快捷、余额支付”等本地支付办法,就会调用本地收银台,如果用户选择的是微信、支付宝这类外部的账户就会调用渠道的收银台。

3)回调关照

回调包括两部分,一部分是收银台返回,另一部分是支付结果关照。

收银台返回:用户在收银台上完成支付后,须要返回发起交易的平台连续完成后续的操作,支付结果关照:跳转收银台这种办法虽然很安全,但是用户的支付结果对付发起交易的“商家或支付平台”是无法节制的。
因此,须要通过回调的办法把结果推送给发起者所在的平台。

4)同步结果

商家结果查询:返回发起方的页面后会有一个短暂的白屏页面,这是本地的结果页面要查询订单结果给用户看。
如果回调结果已经到了支付系统,那本地查询下就可以了。
如果没有则须要到渠道把这个支付结果查回来然后记账并完成结果页面的推送。
用户结果关照:如果一贯查不回来,那岂不是用户和商家都不知道呢?这个设计者也想到了,渠道不仅会关照商家支付系统,也会发送短信或者APP奉告用户已经扣款。

以上便是一个行业内通用的收银台支付过程,在网络统统正常的情形下他险些是在一瞬间完成,让你对此浑然不知。
纵然涌现网络非常,他也能担保交易对手之间至少有一个人对付支付结果是明确的。

2. 收银台做事流程

理解了四段式的处理办法我们再来深入技能实现的细节,看下系统内部各个模块之间是如何去串联的和处理的。

图10:收银台时序图

1)收银台参数

我们看到下单过程创建订单前,首先跟进用户选择的支付办法在商户系统中读取收银台的配置信息,这样做的目的便是校验商家有权限利用哪些支付产品,收银台该当给他如何展现。

2)支付下单

支付下单过程中包含两个过程:

创建支付订单:首先是本地创建支付订单,如果涉及渠道收银台也要同步去创建。
获取收银台参数:其次便是要天生收银台参数,供应调用收银台做准备。
收银台参数一样平常是链接或者访问的令牌(这个在后面详细先容)。

3)收银台跳转

收银台跳转:得到收银台参数后,下一步便是让用户跳转到指定的收银台上进行支付。
这一步紧张是通过“收银台系统”与“渠道收银台”之间参数进行转换和收银台的跳转。
二次开拓:这里也是渠道收银台是否要二次包装的关键位置,比如我们做聚合二维码的时候,在此处就可以根据用户扫码的APP来决定是跳转“微信"大众年夜众号”还是“支付宝做事窗”,这样用户可以无感的完成跳转选择。

4)支付回调

支付结果登记:为了能够及时节制用户在渠道收银台上是否完成了支付,作为收银台供应者一方要给交易发起者一个支付结果关照,这样发起者就能进行账务登记。
及时相应结果:作为发起者也要完成账务登记后给支付渠道一个“成功”相应结果,见告渠道我记完账了。
如果不返回会怎么办呢?渠道为了担保你能成功就收,他会按照一定的韶光间隔不断的向你发送结果关照,直到你给回答,或者超出规定的次数或韶光。

5)收银台返回

页面返回:完成支付后须要返回商户结果页面,这个结果页面一样平常是通过在渠道的商户后台进行设置或者通过集成的SDK来得到返回地址。
结果查询:页面返回后本地的结果页面还不知道这笔订单记账成功没有,是否有折扣、是否扣收用户手续费等信息,因此要进行一次结果查询。
如果没有查回来则会让用户去主动确认订单结果,系统也会定时地去扫描结果,直至终极支付系统和渠道的结果同等。
用户关照:这个处理支付渠道和用户之间的交互,有APP内关照、短信关照等多种形式。
中间商户系统、支付系统本身不须要处理。
其目的便是确保用户理解支付结果,防止订单被修改。

四、收银台设计实战

理解了收银台四段式的事情事理之后,我们再通过一个实际案例来先容下详细的设计实现。
我们来设计一款“统一收银台”的收银台支付产品,他能以统一的办法完成市情上主流支付办法以收银台的形式完成支付。

1. 统一收银方案

1. 统一收银背景

我们希望先容一套统一的收银系统,支付平台只要发布一套标准做事,就能快速扩展主流的支付办法,包括“快捷支付、余额支付、小程序、"大众年夜众号、APP、H5、扫码支付(C扫B)、条码支付(B扫C)”等都能支持。

2. 产品实现方案

图11:统一收银台的核心能力

1)产品方案剖析

从上图中我们可以看到,微信、支付宝两套接口整体交互基本是同等的,唯一的差异就在调用的收银台由于适配的终端不同须要采取不同的调用办法。
以是我们就采取“微信、支付宝”接口标准作为我们收银台做事的标准(没错,便是抄)。

这里比较麻烦的是,快捷、账户两个支付办法,他们做事交互形式各有各的特色,并不是很好整合。
以是我们统一把这些个性化的支付办法按照“四段式交互标准”包装成“APP和H5”形式的“聚合收银台”,这样支付的整体交互就统一了。

2)统一下单方案

通过方案剖析,我们知道做一个收银台它的个性化部分紧张是不才单和调用收银台,我们就从这里下手来做统一收银台。
至于做事的交互标准我们就采取微信的交互办法稍加改造我们自己的统一收银就实现了(我们不是抄产品,我们只是行业标准的搬运工)。

图12:统一下单数据要素(赤色字体为通用报文头)

增加支付类型:要做统一收银台,并不是大略的照抄微信,由于微信虽然标准但它不是统一收银。
以是我们在统一下单的报文中增加一个“支付类型”,让商家要利用什么支付办法进行选择,这样就能无限扩展新增的收银台了。
定义公共要素:我们希望每个报文公共部分都是一样的,业务要素是可以根据详细场景再来补充。
以是我们须要仔细研读各种收银台的接口文档抽取出公共部分,当然这个过程还是挺费韶光和吃功夫的。
为了节约大家韶光我这里给大家一套标准的方案直接拿去改吧。
把图中标红的字段作为公共的报文要素,保持每个报文都按此办法统一处理。
其他信息按照详细业务场景进行增减和担保即可。
扩展业务信息:统一下单订单目的是创建一笔订单来记录交易过程,然后根据不同支付办法返回不同类型的收银台供应下一步操作。
因此我们给返回报定亲义完公共信息后,增加一个扩展参数支持各种收银台参数和交互业务信息的返回给交易发起方进行下一步操作。

3)收银调用方案

完成了订单创建后,我们就可以跳转收银台进行支付了。
这一步是否顺利完成,就不是接口层面的事情了。
它依赖的是你当初商户入网时候申请的支付产品了,毕竟支付是件合规性哀求很高的事情,什么样的场景适用于什么收银台都要根据本色业务场景来审核的。
下面我们来看下申请收银台须要哪些前期准备。
下面我们以微信支付为例来先容全体准备过程,支付宝和其他钱包APP基本类似,稍作转换和后台配置即可。

图13:收银台利用的参数解释

1)申请参数(让你拥有身份)

首先你要在渠道上申请“运用编号”和“商户编号”,运用编号是支付渠道给你分配利用支付运用的一个统一编号。
大略来说有了他你就可以去申请各种收银台了。
“商户编号”便是你可以收钱的账户编号。

2)安全加密(让你安全支付)

支付说到底是个接口买卖,由于须要交易数据交互和多段式接口调用,因此须要安全证书和密钥,确保信息安全的加密传输,交易接口也不会被交易发起方随意的修改和套用。

3)运用配置(让收银台返回)

当你申请完成开通商户后,还不能立即进行开拓你要设置收银台结果页面返回地址,以便于用户操作完后返回你的平台。
这里的设置根据不同的收银台各有不同设置办法,其目的便是让用户返回更为顺畅。

4)下单接口(实现统一下单)

下单接口都是采取统一下单的办法。
个中付款码轻微分外些,他是一种用扫码枪或者扫码盒子主扫(B扫C)的形式,须要交易发起方上传读取的二维码给渠道方,渠道方校验通过后返回订单结果给交易发起方。

5)返回参数(三类收银参数)

下单后的返回收银台参数各有不同,紧张分为以下三类

交易编号:它返回的是创订单的“预支付编号”,适用于在渠道APP内部调用的收银台(例如小程序、公众年夜众号、APP等),渠道会根据预支付编号查询你原始的订单,并加载收银台给你利用。
收银台链接:适用于扫码、H5等通过支付链接来返回二维码和收银台的支付办法。
无收银台参数:当然也有像“付款码”这种收银台在用户一侧,无须任何收银台信息的交互形式。

6)收银调用(四种技能手段)

收银台调用是比较偏技能实现层面的,它分为“API调用、浏览器调用,集成sdk调用和链接访问”四种办法。
详细的我们在后面“产品须要知道的技能”文章中单独先容。

7)回调地址(关照支付结果)

回调地址便是支付结果的关照地址,这个地址是不才单时候交易发起方主动上传的,用来吸收用户在收银台上的支付结果。
至此我们全体收银台的实现方案已经明确好了,下面我们就可以开始实际的设计了。

2. 收银台交互

通过收银台完成支付主流移动支付形式有四类“银行卡支付、余额支付、APP支付、扫码支付”,这些支付办法都遵照了“四段式”的支付办法。
(须要解释的因此下收银台交互都因此一家为商户供应支付做事的三方支付机构视角供应页面)

1. 银行卡支付

图14:银行卡快捷支付

银行卡支付底层是基于快捷支付产品,快捷产品特点便是须要签约绑卡,支付的时候也一样平常须要短信验证码。
因此这里的选择支付办法之后是调用了本地快捷收银台,其后的回调结果由于是本地支付办法因此速率非常快就可以完成,随后将结果同步给商家。

2. 本地余额支付

图15:支付账户余额支付

本地余额支付紧张指通过本地支付账户进行支付(支付账户又叫会员账户、余额账户)。
用户选择支付办法后会跳转到余额账户的收银台确认订单与账户后输入密码完成支付。
由于账户是本地的因此回调结果非常快的返回给商家,同步也返回商家页面。

3. 渠道账户支付

图16:渠道账户支付

渠道账户支付紧张是指接入“微信、支付宝”或者“银行数字账户”等产品,这类也是采取了四段式交互,因此过程就相对繁芜了。
用户在收银台选择支付办法后,先要调用渠道收银台,让用户跳转后完成支付。
支付成功后须要吸收渠道的回调结果,然后将回调结果同步给商家。
末了渠道返回页面到支付平台,支付平台再返回到商家。

由此可见,这个过程每个节点都有商家、支付平台、渠道要进行转发和同步,因此比较随意马虎涌现结果不明的情形,因此这类产品须要合营定时任务来同步结果,保持“商家、支付平台、渠道”结果终极同等性。

4. 扫码支付

图17:扫码支付

扫码支付紧张是指“静态码牌”或者“网站/自助设备商品码”,他们的特点便是可以低廉甜头一个二维码,在用户扫码下单后,判断扫码APP来跳转到不同的收银台(一样平常是"大众年夜众号或者做事窗)完成支付。
支付成功后通过用户在APP内点击确认返回结果页面,这里的结果页面如果是静态码牌由于商家未做定制因此直接返回支付的页面即可。

3. 收银台配置

有了收银台支付产品,就须要能够灵巧的配置出来供应给商户利用,并且收银台上的所展示的内容可以进行灵巧的配置,知足不同产品、不同客户的需求。
因此收银台采取了下的配置过程。

图18:收银台配置关系

商户入网申请通过后,会给商户配置所申请的“签约产品”,签约产品一样平常是提前设置好的,只要在“商户签约设置”中将签约产品关联上就可以了。

1. 签约产品配置

在供应商户配置之前,要先创建一个默认的支付办法配置。
像聚合收银台这样的产品,它可能是多组支付办法组成的,因此在这里我们把这一组的支付办法称为一个“签约产品”。

图19:签约产品设置

创建一个签约产品须要给他设置很多东西,包括利用什么网关接口,交易类型,收付款账户,默认分账方,以及为每个支付办法设置他们的交易属性。

从上图我们可以看到,支付办法可以进行多级分组,这样就能适应收银台多种支付办法分类展示,让用户利用更加一览无余。
同时每个支付办法还能设置它的排序、是否展开,logo,营销文案,绑定卡很多时默认展示几张卡等一系列细致入微的特性。

一样平常情形下签约产品是提前设置好的,商户签约的时候直接选择就可以了;如果商户有分外需求我们按照模板重新给他创建一个就能知足不同商户的需求。

须要再次解释的是,这里的签约产品配置因此“收单机构”场景下的产品设置,与普通非持牌机构设置不同之处在于账户部分的设置。
由于收单机构有清结算资质可以做渠道路由,以是不必每个支付办法绑定对应的渠道,只要设置商户结算账户就可以了。

如果是非持牌机构只要把“账户设置部分”改为“支付渠道”的设置就可以了。

2. 商户信息管理

图18:商户信息列表

一个商户签约入网完成实名认证和事前审核后,商户运营职员就会在此处给商户创建支付产品,点击创建会跳转到的“商户产品配置”页面进行产品设置,设置完成后签约产品会与商户进行关联这样商户就能接入利用了。
当然每次配置创建、修正都须要重新审核通过后才能生效,避免配置不当造成不当配置影响商户利用。

3. 商户产品配置

商户产品配置的目的便是把商户和签约产品关联起来,并对于出办法供应的默认参数进行修正以符合客户的利用需求。

图19:商户产品配置

从图中我们可以看到,一个商户可以添加多个签约产品,并且每种签约产品可以根据“原始签约产品”供应的参数进行设置,以知足不同商户交易、账户和优惠活动参与的需求。

五、总结:统一收银台设计1. 四段式收银台设计

统一收银台的精华就在于它“四段式”设计标准,他是所有做支付人的共同措辞,因此请大家牢记这四个交互过程,学会了他,再繁芜的收银台设计都能收得手到擒来

2. 收银台能力视图

收银台在方便了用户操作和提升支付安全的同时,也把各种不同的支付办法进行了统一,使得对接也变得非常规范和大略。
Ping++曾经提出来“7行代码完成支付开拓”便是识破了收银台设计的实质,支付的差异化就不才单和调用收银台两个过程,其他过程都是标准可复用。

3. 用例模型举一反三

节制收银台的标准用例模型,理解网关、接口、客户系统在,四段式设计,统一交互和产品配置方面如何实现整体闭环。
理解了这张图你任何收银台设计都能搪塞自若。

4. 多看微信、支付宝接口

我可以负任务的说,海内所有的移动端收银台产品都是参考这两家的标准来做的。
以是要多研究这两家的接口设计,特殊是“下单、调用收银台、结果关照和结果查询”这四个接口。
产品做的好不好全看对付这四个接口理解的深浅。

"大众年夜众号:刚说产品

本文由 @刚哥 原创发布于大家都是产品经理,未经授权,禁止转载

题图来自Unsplash,基于CC0协议

该文不雅观点仅代表作者本人,大家都是产品经理平台仅供应信息存储空间做事。