支付系统概述（四）：收单系统

前面两个章节介绍了渠道网络。渠道网络主要负责和支付机构和网络进行交互，是支付系统和外部联结的一端。本章和下一章，我们来看一下支付系统的另一端：和商户联结的收单系统和结算系统。

在业务架构上，收单系统负责完成从商户侧接受商品订单，并管理订单的全生命周期。收单系统还需要和风控能力交互，完成对商户和商品的风控处理。

具体的，收单系统需要具备如下能力：

• 下单管理：通过 Open API 或者页面端，完成商户下单的过程。

• 订单支付推进：和下游支付系统进行协调，完成订单的支付过程。

• 退款管理：接受商户的退款诉求，进行退款处理，并通知下游的支付系统。

• 拒付管理：对于卡收单，卡组织有拒付的流程。拒付由用户发起，和退款不同。收单系统首选需要能管理拒付的全生命周期，并完成资金的处理。如果没有将拒付判责过程完全委托下游的支付机构，那还需要具备拒付运营的能力。

• 商户通知管理：对于订单的生命周期，需要通过 Notification callback、邮件、站内信等方式通知商户。

• 收单合约管理：不同的商户，在 MCC、支付方式、退款策略、结算策略等方面会有不同的诉求，收单系统需要能有能力管理这些差异。

在应用架构上，一般将收单系统和结算系统放开，结算系统我们下一章再介绍。同时如果拒付需要进行运营的话，一般也独立建设系统。

在服务上，一般提供给商户如下的 API：

• 下单。

• 退款。

• 订单查询。

• 商户通知 callback。

在模型上，收单系统的模型主要聚焦在对于商品订单的生命周期管理：

• 商品主单：主要记录商户每次下单的摘要信息，包括商户 ID、金额、摘要和相应的状态。

• 商品子单：针对每一件商品，进行明细的记录。

• 退款单：记录商户的退款请求。商品单和退款单之间是一个一对多的关系，支持部分退款。

• 支付单：记录商品订单的支付行为，和下游的支付系统进行关联。考虑到合并支付和分期等复杂情况，支付单和商品单之间是一个多对多的关系。

• 拒付单：记录拒付行为和拒付的判责过程（拒付发起、拒付翻转等）。

在技术架构上，收单系统是一个最普通的分布式架构。但是，考虑到商户这个外部节点，收单系统在和商户交互上需要注意如下技术架构设计：

• 和商户交互的幂等逻辑处理：外部通过商户号+商户订单号做幂等，内部通过商品订单号做幂等。退款、订单查询、callback 等，以内部订单号为准。

• 商户通知的隔离和重试：商户的系统很有可能是不甚稳定的，所以需要考虑到商户系统宕机的情况，对于 callback notification 要快速失败的能力，失败后可以通过定时任务捞起重试。

• 多地部署：如果对于全球收单的系统，需要就商户就近部署，提升商户的接入体验。如果做不到全球多机房，可以采用多域名+网络加速的方式。