电商系统中，支付中心作为交易的重要支撑体系，是整个系统的重中之重。那它的架构有哪些关键部分？底层设计又要注意什么呢？本文将为大家解答这一系列问题。

一、开篇

上一篇文章《B2C电商系统产品架构：全局分析系统定义与职责》中，我们主要描述下B2C电商系统整体产品架构图，里面各个模块系统每一个展开其实就是一个庞大的产品体系，而这个也正是后续该系列文章的大纲。

本篇文章，我们主要来拆解下一般电商公司【支付中心】的产品架构图。

在我们开始正式讲解之前，大家先描述下自己对支付中心的认知。我想可能对于大部分普通用户，对支付中心的理解可能更多就是付款页面了，即收银台，用户选择不同支付方式进行付款。甚至连订单申请的退款到账，用户也基本不会联想到支付中心身上。

支付中心作为交易三流向中的资金流支持体系，是最为重要核心的部分，搞不好对公司就会产生不可估量的损失。接下来，我们就来系统性地了解下经典B2C电商的【支付中心】究竟有哪些模块，每个模块又有什么职能？各模块之间又是如何联动的。

二、正文

说到底，支付中心的原子能力就是收、退、打，其他所有的一切，几乎都是围绕这几个基础能力搭建出来的应用产品。

支付中心对内的上游主要是业务订单系统（本文主要描述经典场景），订单会传入支付结算所需要的核心信息，支付中心接收后转化为系统内的收退打相关指令，并进行信息的回执；

支付中心对外是跟三方支付公司/银行系统进行互动，支付中心将平台的收退打指令转为三方真实资金的收退打指令，三方产生信息回执；

而支付中心内部，主要包含收单系统与清结算系统。前者主要负责收款，后者主要负责退款与打款。

一图一文，以下这张图片就是本篇文章描述的核心：

简单描述此图的结构：

 最上边的订单系统，就是触发指令给支付中心的上游，一般就是公司的各个业务订单系统；

 橙色背景区域内，就是支付中心的内部系统模块组成；

 左侧的模块，是三方支付机构内部的大概逻辑（不再引入银行，主要为了描述支付中心对外的资金信息交互）；

 粗的线条，表示比较大的系统模块或实体之间的交互逻辑；

 细的线条，表示系统模块内的指令与模块之间的交互逻辑；

 箭头指向只是表明大逻辑上有关联或顺序，但仅限于宏观层面，不开展到非常细节的产品设计层次；

接下来，我们从【收单】【清结算】【账户】【对账】【交易安全】5个部分来展开：

1. 收单系统

收单系统的主要职责就是收款，对业务要保证下单支付转化率，对系统要保证安全稳定、精准无误；

我们用大概的时间顺序来串联描述各个环节：

1）订单调用支付中心：

上游创建订单后，会发起付款请求，比较常见的就是：

普通支付（原子层：父订单：支付单=1：1，子订单逻辑订单体系内处理）

合单支付（原子层，订单：支付单=N：N，支付中心还有一个父支付单与N支付单进行同步）

补差支付（原子层，订单：支付单=N：N，支付中心根据N个原始支付单合并一个总支付单与订单进行同步）

我们就拿比较经典的普通支付来说明，订单创建后，获取到业务、用户和商品相关信息，然后创建支付单实体，支付单包含了支付收单所必须的上游信息。

2）支付单与收银台

支付单创建之后，上游订单维持“待支付”状态，用户可以在限定时间内发起支付行为，即吊起收银台。

这里注意，收银台本质上就是收款通道的整体逻辑控制，不同终端、不同业务可选择支付通道的不同，例如：微信内是不可能用竞品支付方式的、有的业务坏账率高无法使用分期产品、信用卡手续费谁承担、哪个收款通道默认选中/展示排序等等。这些本质上就是结合业务不同情况，为支付转化率和交易安全作保障。

收银台支付通道也分以下几种常见类型：

当前主流电商基本都是三方支付，如微信、支付宝、京东支付，也有部分银行支付，还有花呗、白条等消费分期通道

另外，部分平台也提供平台账户余额支付，即钱包业务

还有一些会把不同支付通道进行组合，如分期与非分期支付组合，方便额度不够或想减少消费分期额的用户。

3）收银台调用三方支付系统