每天我们都会通过形形色色的收银台完成与各种买卖交易，顺畅的体验可能会让你感觉到支付只是一个收银台。想要在不同场景下都能设计出体验良好的收银台。我们可以一起来看一下这篇文章的介绍。

各位小伙伴，大家好！

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

【老规矩，觉得简单或者啰嗦的同学，直接翻到最后看总结】

一、支付收银台介绍

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. 支付结果：就是用户支付这笔订单的最终结果，结果页面的正常展示说明渠道、本地都已经同步结果了，如果没能正常展示则需要提示用户去主动查询订单结果。
2. 营销活动：营销活动是个可选项，并不是每个收银台必须的。可以配置内部的推荐产品和活动，也可以配置外部的营销活动（例如微信点金计划）等。

二、收银台业务架构

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

1. 业务架构介绍

图7：收银台业务架构

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

2. 收银台用例介绍

图8：收银台用例

1）收银台业务边界

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

2）收银台用例说明

• 收银台接口：收银台提供给外部的服务接口，包括“地址获取、页面获取、回调处理、结果查询”等；
• 收银台服务：收银台服务的主控服务，通过读取商家的收银台参数来控制页面展示和交易处理流程。
• 支付方式：以接口或者页面的形式，提供收银台支付方式的信息的查询，以及在收银台上对于绑卡、开户操作的扩展。
• 支付页面：按支付前、支付中、支付后三个步骤来操作对应的支付页面。

三、收银台工作原理

随着移动支付的推广，以及微信/支付宝的长期的市场教育，他们四段式收银台交互标准，已经成为事实上的行业标准。掌握这个标准流程，做个收银台其实很简单。

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

1. 标准四段式交互

1）支付下单

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

2）调用收银台

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

3）回调通知

回调包括两部分，一部分是收银台返回，另一部分是支付结果通知。

• 收银台返回：用户在收银台上完成支付后，需要返回发起交易的平台继续完成后续的操作，
• 支付结果通知：跳转收银台这种方式虽然很安全，但是用户的支付结果对于发起交易的“商家或支付平台”是无法掌握的。因此，需要通过回调的方式把结果推送给发起者所在的平台。

4）同步结果

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

以上就是一个行业内通用的收银台支付过程，在网络一切正常的情况下他几乎是在一瞬间完成，让你对此浑然不知。即使出现网络异常，他也能保证交易对手之间至少有一个人对于支付结果是明确的。

2. 收银台服务流程

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

图10：收银台时序图

1）收银台参数

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

2）支付下单

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

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）返回参数（三类收银参数）

下单后的返回收银台参数各有不同，主要分为以下三类

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

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. 多看微信、支付宝接口

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