b2c电商支付中心的产品架构包括「微信支付架构」

今天给大家普及一下b2c电商支付中心的产品架构包括「微信支付架构」相关知识，最近很多在问b2c电商支付中心的产品架构包括「微信支付架构」，希望能帮助到您。

一

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

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

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

二、正文

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

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

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

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

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

简单描述此图的结构：

最上边的订单系统，就是触发指令给支付中心的上游，一般就是公司的各个业务订单系统；橙色背景区域内，就是支付中心的内部系统模块组成；左侧的模块，是三方支付机构内部的大概逻辑（不再引入银行，主要为了描述支付中心对外的资金信息交互）；粗的线条，表示比较大的系统模块或实体之间的交互逻辑；细的线条，表示系统模块内的指令与模块之间的交互逻辑；箭头指向只是表明大逻辑上有关联或顺序，但仅限于宏观层面，不开展到非常细节的产品设计层次；

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

1. 收单系统

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

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

1）订单调用支付中心：

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

普通支付（原子层：父订单：支付单=1：1，子订单逻辑订单体系内处理）合单支付（原子层，订单：支付单=N：N，支付中心还有一个父支付单与N支付单进行同步）补差支付（原子层，订单：支付单=N：N，支付中心根据N个原始支付单合并一个总支付单与订单进行同步）

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

2）支付单与收银台

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

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

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

当前主流电商基本都是三方支付，如微信、支付宝、京东支付，也有部分银行支付，还有花呗、白条等消费分期通道另外，部分平台也提供平台账户余额支付，即钱包业务还有一些会把不同支付通道进行组合，如分期与非分期支付组合，方便额度不够或想减少消费分期额的用户。

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

当用户选择某种特定支付通道之后，收银台就会用sdk或内嵌M页吊起支付通道，用户放弃某个通道之后，大部分场景可以更换其他支付通道继续支付。

在三方支付的体系内，在使用余额或绑卡支付成功后，真实资金会从用户在三方的用户账户余额转往平台在三方的商户账户余额（有账期的暂不展开）；同时，三方告诉平台的支付中心用户已完成付款，平台的支付单可以变更已付款状态，并回执给订单变更订单状态。

2. 清结算系统

清结算系统分为清分系统、结算系统组成。

1）清分系统

清分系统职责：处理上游业务单的分账请求，并转换成为标准的清分记录，进而在业务结算时机调用结算系统产生结算记录；

一条清分记录，会被拆分为N条结算记录。清分记录可以理解为业务一笔订单的完整分账信息，可能包含很多目标账户，结算的时机也可能不同，经过清分系统之后，会转化为一条条格式化的结算原始记录，主要是出资账户和单个目标账户、结算金额、结算时间等核心信息；

2）结算系统

结算系统职责：将清分系统产生的结算记录，按照账期产生结算单，进而按照商户系统合同打款信息进行转账打款操作（包含欠款扣款逻辑）；

结算系统，将待结算的结算记录按照结算周期和结算对象，分别进行合并运算，生成结算单（如果是负值结算单可能涉及到滚动生成结算单）。结算记录：结算单=N：1。

结算单如果是正值，则生成打款单/提现单，然后将钱款进行打出，也有可能是多批次打出。结算单：打款单=1：N；

商户会按照结算单与自己在平台经营的订单信息进行对账，看是否有误差，以及关注结算单的打款进度。

3. 账户系统

账户基础原子能力有：充、提、冻、转（支付、转账、扣罚）。支付单、结算单/提现单、冻结/解冻、转账等都会产生账户流水。

账户分类一般分为3大类：平台类账户、用户类账户、映射账户。

平台类账户根据不同财务用途会划分很多种，例如代收代付、预收、应收、成本、资金等等。用户类账户，体现在用户端就是余额钱包的场景，可以充值、提现、冻结等操作。映射类账户，主要用来映射平台在三方的资金情况，便于平台实时了解平台的各渠道资金情况，便于调拨等用途；4. 对账系统

标准的对账系统，大概分为以下4种对账：

账证：业务层-账务层，即业务订单与支付中心账务进行对账；账账：账务层-会计层，总账与总账、明细账、日记账、明细账之间相互核对的过程；账实：内部-外部，即支付中心与三方及银行进行对账；账表：会计报表-会计科目，跟本系统层面关联较弱。5. 支付安全

支付中心的天职就是为平台交易安全提供保证。不仅要关注交易的双方角色，还要核心关注钱款的流向，尤其是收、打这2个节点。

第一方面，支付中心包保证合规、合法。首先支付中心设计要满足监管部门的要求，同时还要结合业务上游和支付中心联动，积极反诈骗、洗钱、信用卡套现等违规违法行为。第二方面，要做到系统健壮。从系统设计、系统实施、系统运营，都需要非常严谨，兜底也要建立完备的预警机制、熔断机制，为公司业务上游提供安全可信赖的支付服务。

三、结尾

本文聚焦在支付中心的框架内，比较宏观介绍了部分系统的定义和职责，另外有些模块也都还在探索摸索阶段，并非标准答案。

支付中心系统底层设计比较固定，最关键是能够结合企业自己的业务做好对应的架构设计和运行支撑。跟着业务变化而迭代系统，这样才能做出一个有灵魂的支付中心。

一图一文系列，第2篇，收~

作者：六小艺，转转交易中台产品负责人。