收银台，字面意思是“收+银+台”，顾名思义就是收取银子的台子。本文作者对收银台的产品架构、业务架构、流程，以及常见的支付方式、支付场景等方面进行了分析，全面解析如何完整地设计一款收银台产品，一起来看一下吧。

收银台，从字面意思“收银台=收+银+台”，顾名思义就是收取银子的台子。本文主要是归纳抽象出收银台的通用设计方法，其中包含了收银台的产品架构、业务架构、流程，以及常见的支付方式分析、支付场景分析等，全面解析如何完整地去设计一款收银台产品。

(资料图片)

01 初识收银台

1. 传统收银台

在古代你去饭馆吃饭喝酒吃肉，酒足饭饱后到柜台掏出50两的大元宝拍在了“收银台”上：老板结账，不用找了；最原始的收银台就是那个柜台，柜台的特点就是结账的场所，你把钱放上去，有专门的人员核实账款与商品，无误以后，交易就完成了。结账场所最核心应该具备的内容应该包括以下点：

商品信息：消费了什么 价格信息：应该多少钱 支付方式：如何结算，现款还是赊账 核实人员：核对货款的一致 货款交割：付款结账，宣布完结

这些信息构成收银台应该具备的基本元素以及职能，而且这些职能是在实际执行过程中逐渐形成并固定下来。对于电子支付收银台的设计具有参考意义。

2. 线下收银台

近代在电子支付出现之前，我们去超市购买商品，挑好货品后拿到结账处进行清点，工作人员告诉你“一共10斤粮票” ，你掏出纸质的票子完成了付款，商品就是你的了；此时的工作人员叫收银员，他面前的台子就是收银台；这里收银台就是商品和现金的交换场所。形式跟传统收银台没有本质差别，但在技术和管理能力上有了很大的提升——货币形式变了，有了专业的收银人员，交易场所更加规模化，商品管理也更加标准化。

3. 线上收银台

电子支付出现以后，出现了新的货币形式“账户货币”支付方式产生了电子支付方式，从而产生了线上的支付场所——电子支付收银台；一个可以在线上通过各种电子支付手段完成账户货币转移的支付收银台形式。

PC收银台：在电脑上完成支付的收银台 H5收银台：手机内的H5网页上完成支付的收银台 API收银台：以接口形式提供的收银台服务 SDK收银台：提供SDK开发工具包的收银台服务 硬件收银台：pos机，mpos机等硬件设备，支付卡牌等

4. 移动端收银台

移动端收银台：填写订单、选择支付方式、支付流程、支付结果。

5. PC端收银台

如图中的结算页，主要“看元素、定布局、思缘由”：

结算进度条 地址信息 支付方式选择：货到付款、在线支付、对公转账 配送方式 商品信息 发票信息 计费信息 提交按钮

02 收银台的产品架构

我们重点关注收银台架构的三个方面：

公司所支持的收银台种类以未来拓展倾向 支付方式的枚举及根据业务发展预判拓展倾向 收银台服务端的能力建设规划和选择

03 收银台的业务架构

收银台，是支付的起点，所以无论是何种企业或者支付组织，收银台都是支付架构的最前位置，支付从“收银台”开始。

直面终端用户“消费者，B端商户，内部用户”。

消费者下单需要的用户收银台：

商家支付货款或充值的商家收银台：

04 收银台的支付流程

收银台是支付的起点，是交易环节和支付环节的衔接点，用户在交易环节完成了商品的选购以及订单的填写、合同签约以后，下一步就要进入支付环节完成支付，而支付的起点就是收银台。用户在收银台选择合适的支付方式进行支付。

05 从功能上理解收银台

收银台不只是用户看到的收银台页面那么简单，其除了在不同场所页面元素以及交互方式不同以外，与后台的数据交互以及子系统的划分也会存在差别。

例如普通的商户和三方支付机构对收银台的设计思路会存在差别，这些差别是由于：

这些差别可以从不同角度去分析，例如分析不同组织之间的收银台差别、同一个组织的收银台的前后端的差别。

从组织维度对比：

商户侧的收银台分：前台/后台，前台面向用户，后台面向渠道 支付公司的收银台：前台对应商户或者直接面对用户，后台面向渠道

从前后台对比：

收银台前台：面向用户的可视化收银台页面主要是提供给用户完成支付方式选择和支付请求的发起 收银台后台：主要是调用后端获取支付参数和支付通道，请求通道发起支付请求

06 收银台的关键指标

问自己一个问题：我的收银台好吗？

产品的一切目的都是以价值为导向，无论是用户价值还是企业价值，否则就失去的产品的方向和意义。

对收银台来说，我们如何定义其好坏，考量其“好坏”，所以需要建立几个核心指标用以考核收银台。

用户支付体验-NPS： 好不好用，用户用得爽不爽，界面舒服，操作流畅，支付方式丰富 支付时效： 最短的时间完成支付，简单的加载5s内可以反馈支付结果 支付成功率： 支付成功率越高意味着用户体验越好，同时也是支付转化率中最核心的一部分 支付转化率： 平台交易在“支付环节”的转化率高低，是整个交易转化率的一部分

07 设计收银台前的准备

在设计收银台之前要先做好下面几个方面的准备，才能确保设计的产品相对完整，能够达到预期的用户体验，完成相关的支付指标。

1）了解公司业务模型

做任何产品的前提就是先了解业务是怎么样的；例如售卖的是什么商品，业务模式是电商、游戏、课程售卖还是会员充值等等，其实就是搞清楚卖什么，怎么卖的问题；我们假设是电商平台，卖的是实物商品。

2）选择支付方式

想好要为用户提供什么支付方式，比如微信支付，支付宝支付，银行卡快捷支付，账户余额支付？一般场景中，选择微信支付宝就够了，但也难免有用户想直接绑定信用卡去支付，虽然通过微信支付宝也可以使用信用卡支付；这个要看平台的选择，如果有能力实现就尽可能给用户更多的选择，满足更多的用户需求，覆盖更多的支付场景。

3）签约支付通道

完成了（2）的分析，基本就可以确定要签约什么支付产品，也就知道该如何去设计收银台了。假设签约了微信支付，易宝的快捷支付，自建钱包；就可以拿到微信的文档，易宝支付的文档，钱包账户自己来设计；拿到文档后就知道了支付需要的参数，就能确定我们请求通道时需要哪些参数，哪些参数是用户提供的，哪些参数需要后台整理封装，当前系统是不是可以提供需要的参数，还需要做哪些改造。

4）确定收银台的支撑系统

分析清楚要完成支付至少需要哪些支撑系统，收银台还需要内线的订单账单、账务等，外线就需要收银台后台、路由、风控（非必须）、支付处理、渠道管理等。

08 收银台前台设计

收银台包含前端和后端，前端是用户可以看到的收银台页面，在订单填写页提交订单以后到达。对于前端页面比较容易调研，因为直面用户，所以到任何一个平台操作一下下单和支付就可以到达相应的收银台，看到收银台展示的内容元素以及交互。

1）收银台的关键信息

收银台页面内容主要包含以下几个元素：

商品信息（非必需展示） ：用户买的什么 收款方 （非必须展示） ：钱付给谁 支付有效时间：在规定时间内支付 支付方式列表：有什么支付方式可以选择 支付金额 ：付多少钱 支付操作：确认支付的按钮

2）收银台的关键流程

提交订单到达收银台页面 去支付进入支付流程，当前应用或者跳转到支付应用 支付成功或失败的支付结果落地页 支付落地页的后续流程，返回什么地方 支付结束

3）收银台的拓展

收银台随着业务的变化在不断发生变化，在更多的端上建设收银台，收银台支持更多的支付方式，相应也会出现支付方式推荐、支付补贴露出、活动优惠推送等更多内容。

同样收银台类型的拓展：逐渐发展出PC收银台、H5收银台、app收银台等更多的收银台形态。

支付方式的拓展：除了微信支付、绑卡支付、余额支付等方式以外，逐渐发展出数字人民币支付，线下支付等支持更多支付场景的支付方式。

4）银行卡快捷支付

银行卡快捷支付可以选择已经绑定的卡，也可以添加新卡；新卡的绑定一般按照绑卡鉴权的要求既可以设计出需要的要素，借记卡和贷记卡的要素不一样；个人户和对公户也不一样；随着电子支付的发展，方式也会变化，跟着接入方的要求走即可。

5）收银台的余额支付

既然是自己包装或者接入的钱包余额，算是一个新的支付方式，一个新的支付方式需要关注以下几个要素：

支付logo：就是展示给用户的icon图标 支付方式名称：起个名字，比如抖音支付，余额支付，钱包支付等 支付发起流程：选择这个支付方式以后，提交支付后的业务流程如何

09 常见支付场景及关系

收银台的设计离不开企业业务特点，而企业的业务特点又离不开交易场景，我们看下常见的支付场景有哪些，这些场景对收银台的诉求。

10 支付方式选择与分析

对于常见的支付方式选择，可以结合上面所述的支付场景，然后通过以下几个维度进行分析：

对于主流支付方式，目前国内成熟市场下，主要还是微信和支付宝以及银行卡这三种支付方式，大部分可以满足消费需求，但也有基于其他目的比如降低费率、覆盖低收入人群等等，可以选择外漏支付宝花呗等消费贷支付产品。

另外还要考虑的问题就是对用户的覆盖、支付体验、支付限额、用户类型等维度，以下是主要几个支付方式的维度分析。

1）余额支付方式

余额支付的最大特点就是“组织内闭环”，可以不依赖外界渠道，直接在内部完成账务处理。

好处就是可以有更好的支付体验和额度控制，劣势就是依赖前置的账户充值，依然依赖外界支付。

最典型的余额支付方式就是“微信零钱”。

余额支付的核心是：为支付系统模拟出一条“余额支付”通道。

2）代扣支付方式

常见的代扣场景有2个，一个是自动周期性扣费，如自动会员续费；另一个是先服务后支付，如乘车码，我们以微信代扣支付为例。

从协议中看代扣，有几个关键描述点：从哪里扣钱、代扣前的通知、订阅周期。

我们串起来看一下腾讯视频会员在苹果内签约的自动续费的扣款路径，以及扣款账单。

先服务后扣款的常见场景是打车以及乘坐地铁的乘车码，如我用滴滴打车，结束后微信自动支付成功，看下图微信内的支付通知和账单信息。

微信代扣产品叫“微信支付扣款服务（原委托代扣）”，是为微信支付为商户和用户提供的，可以在交易场景之外完成支付的能力，主要服务于三个场景：

免密支付：可以实现对存在签约协议的用户进行小额立即扣款的功能，扣费时间无延迟，无扣费前通知，商户只需调用【申请扣款】接口发起扣款即可。 自动续费：扣费时间有延迟，需有扣费前通知，具体参看【 周期扣费】说明文档，目前支持通知后【24小时自动扣费】或【预扣费通知】两种模式，商户只能选择申请其中一种模式实现扣费，一般申请后为【24小时自动扣费】模式，如需使用另种模式，请联系对接您的运营同学协助申请修改模式。 授权扣款：可以实现对存在签约协议的用户进行大额立即扣款的功能，扣费时间无延迟，无扣费前通知，商户只需调用【申请扣款】接口发起扣款即可。

3）小额免密支付

小额免密支付是在零售小额场景下，一定金额以下的小额支付时，无需用户进行支付密码确认，商户直接发起扣款指令完成扣款的支付方式。

4）消费分期支付方式

接入外部消费分期产品方式，以接入花呗为例，至于独立设计消费分期属于信贷范畴，体系庞大，后续会出单独的内容体系，这里站在大多数普通企业视角做分期支付场景。

花呗分期是蚂蚁集团推出的消费金融产品，用户在商家端网站或线下门店购物时使用花呗分期支付，订单全额实时支付到商家支付宝账户中，用户分期偿还花呗。

11 支付方式的展示策略

收银台的个性化展示：我们可以从以下几个方面去分析，当然还有很多种其他原因，归根结底都是因为多样化业务诉求的产生。

1）支付方式多样化

随着平台的发展，为了迎合更多场景及用户，会签约更多的支付渠道，从微信支付宝，到银行卡支付、苹果支付，再到银联闪付、数字人民币支付、余额支付等等，多样化的支付方式就必然对收银台的展示策略提出了更高的要求。

2）业务的多样化

有了丰富的支付渠道之后，其实业务多样化同样也会影响支付方式的展示，比如有些渠道拒绝某些品类的支付请求，所以如果用户选择了这种品类下的商品，那收银台就不应该展示不接收该类商品交易的渠道支付方式。

3）商户需求的多样化

随着商户数量的增加，种类的增加，合作模式的增加，对支付渠道的要求，甚至是收银台的要求也会相应增加，比如有些ka大商户因为跟某些渠道有合作，可能就会要求仅支持某几类支付方式，这样就需要根据大商户的特殊要求设定支付方式。

4）平台诉求的多样化

平台本身也会有营销等各种诉求，AB实验的诉求等，也会对收银台的个性化提出要求，比如某些用户优先推荐微信支付，某些已经绑了银行卡的用户优先推荐银行卡支付等。

5）渠道合作的多样化

有些渠道可能会提供一些合作模式，比如你把我放在第一位我就给你降费率，或者更有甚者，你把竞品折叠，我再给你降一些费率，而这种合作模式又可能不是全量用户，比如你要将50%的交易采用这种收银台模式。

6）用户习惯的多样化

用户体量足够大时，你就不得不考虑更好的用户习惯和体验的诉求，比如有些用户每次购物都是用微信支付，那么下次支付你要是推荐了支付宝而折叠了微信，那必然会让用户多操作几次去找到自己想要的支付方式；而如果有些用户上次使用了银行卡支付，那么下次推荐上次用的卡可能是一个不错的选择。

7）渠道营销合作

有些银行渠道可能会提供一些支付补贴，这也会成为支付方式个性化的需求来源，但是这种营销又可能不是全量用户，所以这里又需要策略问题。

所以说，收银台个性化展示的目的有时为了更高的成功率，有时为了提高用户体验，为了给某一个支付渠道引流等不同的诉求，但最终实现的业务效果就是不同的人可能看到的收银台页面的支付方式的种类和顺序会有差别。

专栏作家

陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。