支付系统设计：收银台设计一

---

前言

收银台即用户日常付款前选择支付方式的页面，是支付平台提供的基本功能之一，主要职责是协助业务平台完成支付交易，向用户提供一致的交易体验。一般情况下，根据不同终端类型定制标准化的收银台给到外部进行调用，保证各终端体验一致且针对各端特定需求、场景来展现不同的支付方式。

公司内部往往有多条业务线，凡是商业活动一定涉及收款，支付系统扮演平台的角色，为多条业务线提供收款能力，接入的业务线我们称之为商户。支付平台向商户提供C端支付产品和B端商户平台两种类型的支付产品。商户接入一种C端支付产品向用户提供支付服务，同时使用B端商户平台向C端支付产品进行功能配置，这样商户就具备了收款能力。

整体上可分三块：收银台前端页面、运营平台和看不见的支付系统，当然所涉及到的系统远远不止这些。

如下是收银台主干处理流程，不同公司也会有所不同：

本篇将讲解一种使用B端商户平台对C端支付产品进行功能配置的实现方（图：0/7/8/9/10/11步骤），也是最直观的一部分，当我们提交支付单跳转到收银台，页面展示的支付方式、支持的银行卡以及已经绑定的银行卡怎么来的。

---

1. 收银台前端页面

1. 1 收银台的业务场景

一般分为付款与充值两部分：

付款即通过各类支付方式针对业务订单发起付款，例如：用户在淘宝购买一部手机，确认订单后自动跳转至支付宝，引导用户选择对应的方式（余额、花呗、银行卡等）进行付款。

充值即用户对账户进行余额充值，例如：用户登录支付宝、微信或其他商户自有钱包系统对账户余额进行充值。

如下是我们在京东商城购买商品时候的支付流程，对于多数人是再也熟悉不过的操作流程了。

不管京东还是淘宝，收银台支持的支付方式类型都是比较丰富的，一般小网站只接入支付宝和微信支付基本就能满足需求了，但是大的电商平台面对的用户量很大，所以要提供多样的支付方式满足各种需求，复杂的东西也都是慢慢由简迭代过度过来的，本篇从简单的分析。

1. 2 同应用不同支付场景下的收银台

中大型公司，一般不止一个APP应用，并且同一个APP应用也不止一个支付场景，并且在不同的支付场景中所支持的支付方式也有所不同，如某个公司的收银台如下：

如上为一家公司的两个APP不同支付场景下的收银台，可以看到，在不同APP中的不同支付场景下收银台的支付方式也是有所不同的，这种不同是怎么实现的，

2. 商户平台配置管理

2.1 配置流程

运营人员（产品经理）开通产品收银台使用权限，配置流程如下：

2.2 支付工具列表配置

2.3 支付配置

将收银台支付工具列表进行组合为支付产品对外开放：

对于有快捷交易的支付工具需要配置所支持的银行列表信息：

2.3 支付银行配置

配置快捷支付支持的银行以及限额，看到限额是不是就和上面京东的收银台银行卡下显示的限额对应上了。

3. 系统处理流程

用户使用收银台时系统处理流程：

3.1 下单流程

业务系统在拉起收银台之前先请求CashierApi系统-->交易系统进行下单，下完单之后，会响应如下对象：

/**
 * @author  Kkk
 * @Describe: 主动支付下单响应VO
 */
public class AuthenResultVO{
    /** 用户唯一标识 */
    private String uniqueId;

    /** 准入令牌 */
    private String accessToken;

    /** 秘钥 */
    private String secretKey;

    /** 令牌剩余时间 */
    private Integer expireSeconds;
   //... ...
}

核心字段：accessToken，业务系统拉起收银台时候只需要在http请求的Header传这个准入令牌 就行了，如果是有参数的场景将使用secretKey加密后再传输。

3.1 拉起收银台流程

下单时CashierApi系统会将订单信息存入到Redis中，所以业务系统拉起收银台后收银台前端系统会传入accessToken到后端，后端会查询原订单信息，原定单信息有产品信息，以及用户信息，根据产品信息就能够查询出来支持的支付方式了，根据用户信息就能知道用户绑定的卡了。
然后过滤支付工具等，即接下来流程就走上图用户使用收银台时系统处理流程了。流程比较简单在此不再展开，后面会有专门博客来介绍这块具体代码落地，这块设计性还是比较强的，将介绍怎么构建Checker校验链以及Resolver来简化代码编写。

---

总结

拙技蒙斧正，不胜雀跃。