支付系统概述（六）：收银台

前面两张章介绍了支付系统中和商户对接的收单和支付系统，接下来会用两章的篇幅简要的介绍一下和用户支付行为相关的收银台以及资产交换系统。

收银台可以说是整个支付系统中最为特殊的一个系统：这个是支付系统中唯一一个给用户提供 UI 交互的系统。收银台主要完成的职责就是引导用户完成支付的交互：完成对用户身份的确定、完成对用户支付信息的收集、完成支付的推进、完成支付信息和支付结果的展示。

在应用架构上，收银台不一定需要有订单模型，最简单的收银台台可以完全通过编排上下游系统完成和用户的交互：

• 根据支付策略的不同，分期支付或者合并支付，在资产交换系统中创建相应的支付单，并建立商品订单和支付单的关联关系。

• 唤起收银台后，页面上显示商品订单的相关信息。

• 支付方式一部分从资产系统中获取（已存资产）、一部分由用户自行输入（新增资产）。

• 资产输入资产信息后，调用资产管理系统完成对于资产的保存或者缓存，返回资产 ID。

• 用户确定支付后，将支付信息保存进支付单中。

• 在唤起收银台、处理支付资产、确定支付等步骤中，和风控系统进行交互，接受并执行风控的要求，引导用户完成风控挑战。

• 最后触发支付单据的推进。由于支付单据的推进很大概率上是一个异步的过程，收银台还需要进行轮训操作更新支付状态，并显示支付结果给到用户。

在技术架构上，由于收银台和用户进行交互。首先需要考虑收银页面支持多端的能力。一般需要支持如下用户交互方式：

• 网页收银台：最常见的用 js 集成到商家的支付页面中，例如 STRIP 的“六行”js 收银台。

• API 方式即成：如果上游商家平台比较强势，页面心智完全在电商侧，那需要提供 API 的能力完成支付下单、支付资产管理、支付推进、状态通知、风控挑战等交互。

• App 收银台：对于有独立 App 的支付系统（一般是钱包），可以通过 App 间相互唤起的方式，唤起收银页面完成支付。

其次，对于卡支付的场景，需要考虑到 PCI 的要求：

• 支付系统自身完成了 PCI 的认证，提供一个信用卡信息管理的页面，通过网页嵌入、跳转的方式，引导用户输入卡号等。

• 如果支付系统没有 PCI 的认证，那就需要委托一家有 PCI 资质的支付机构完成对于用户卡资产的管理。

• 卡信息的展示和处理，需要注意脱敏的要求：在支付单据中不保存信用卡明文，用 ID 或者 token 代替；在页面回显卡信息的时候，使用前六后六或者其他的方式进行脱敏展示。

最后，收银页面需要支持集成一些第三方的 SDK。比如钱包支付的时候，需要集成数字钱包的 SDK，完成页面的唤起或者服务的调用。在集成 SDK 的过程中，如何做到隔离，也是收银台的技术架构需要重点考虑的地方。