在业务中台解决方案的架构设计当中，经常会提及支付中心，有时也叫支付和结算中心，与订单中心、交易中心、财务中心等共同支持起中台系统核心的功能。今天介绍一下支付所涉及的一些核心概念、参考架构、核心场景和流程。大家多多交流。
电商系统中，信息流、资金流、物流是核心。信息流表示完整的交易流程，比如交易、支付、结算等一系列指令；资金流指资金的流动，比如授信、余额；物流代表交易商品的具体流动，比如具体的实物流、对应的服务流。以上“三流”贯穿企业系统的全过程，从采购、设计、生产、企划、渠道、物流、财务、营销。三流中，所有活动或多或少都会与支付系统打交道，支付系统对支付渠道进行封装而对业务方提供的支付能力，实现在线收付款交易以及管理交易资金等功能。支付系统一般与业务系统、银行、第三方支付以及其他支撑系统进行交互。
业界支付体系概览
我们先来看几个业界常用的支付系统。
支付宝
系统主要包括渠道、产品、公共服务、基础业务平台、管理平台等。支付宝的架构是其他支付平台的源头，其中有两个亮点：1）账务处理中，在兼顾准确性和性能前提下，内部系统采用双边记账（每一步都与链路前面走过的每一步进行校验），外部系统采用单边帐（每一步只与链路上一步进行校验）2）柔性事务。与传统的强一致性事务基于分布式锁，支付宝大量使用消息的柔性事务处理，实现跨系统的最终一致性事务处理，避免锁导致的性能问题美团
上图是美团比较早的一张支付系统架构图，2016年美团拿到支付牌照，提供了丰富的业态，包括工具、风控、结算、短信、金融、通道、信用等，并与数据平台、外部系统进行对接。
支付的核心概念
支付涉及的概念错综复杂，从个人理解主要有以下几个维度
支付单：支付的实体单据，与订单、物流单等相关
支付方式：支付消费的实体，伴随着授信模式
支付动作：支付的动作，正向、反向、查找
支付流程：支付的生命周期，不同的方式对应不同流程
支付渠道：支付的渠道，钱怎么来
支付网关：支付的控制，控制管道
支付账户：支付的账号，钱从哪来
支付管控：监控、运营、管控，偏后台运维
支付中心架构参考
业务中台的支付中心的顶层参考设计，这里主要强调一下支付有关的能力层次划分，具体的每一层每个公司根据自己的业务来构建
应用层：线下门店、微商城、第三方平台、新业务。应用层通过组合下层的能力，将服务进行组合，业务系统提供收付款的操作界面以及处理业务系统提交的交易请求，对最终用户、商户、运营管理人员提供具体的能力，
能力层：支付中心的核心模块，提供能力规划；实时处理完成资金的收付款、记录参与交易的账户间资金流转情况并按照预定规则对账户所属资金进行拆分与合并。一些核心的操作比如支付、渠道、资金、对账等。对外提供统一支付的API和配置界面能力。能力层是中心的核心通用沉淀，支付单据的常见和查询、支付账号的充值和提现、支付工具和渠道路由等
领域层：主要的核心业务逻辑层，比如包括领域模型实体和领域服务，是业务与技术同频的基础，也可以从顶层设计到组织/流程/操作等不同层级逐步细化
网关层：抽象和整合内部网关，第三方渠道；
系统层：提供系统层面的能力支撑，比如分布式服务框架，分布式消息，容器服务，运维监控、日志分析，安全机制，报表统计；也可以提供进一步的数据分析能力，比如全文检索、机器学习等。另外，系统层提供与其他内部系统对接的能力，比如订单中心（单据转换）、财务中心（结算、清算分润）等。
支付的核心流程
支付网关：首先对输入执行参数进行校验，比如有效性、账号状态、订单状态，签名状态，并选择相应的网关方式
支付路由：选择合适的支付渠道，比如支付宝、微信、银联等
风险评估：评估风险，可能有阻断交易、增强验证和放行交易。如果是风险很高，需要阻断交易；如果有一定风险，可能需要进一步验证，比如进一步验证操作用户是否是本人操作，通过手机验证码或人脸识别进行验证。如果交易风险可控，进行放行。
订单更新：支付最终体现在支付单据的变化上，比如相应的单据生成和更新，进而带来交易订单单据变化，以及相关的操作日志。业务订单的核心属性：业务订单编号、下单日期、订单金额、订单状态、折扣信息、商户信息、客户信息。支付订单的核心字段：支付订单编号、业务订单编号、支付时间、支付金额、商户信息、支付状态
第三方系统：通过支付渠道或其他途径，对其他系统通过消息进行通知。技术上可以通过同步或异步方式，性能考虑异步更优，不过需要考虑消息的事务一致性，涉及相关操作的超时/重试/补偿等；而有些银行类操作，则需要调用银行类同步接口。另外，其他系统也需要相应的对接，比如财务系统、信用BI等。
支付场景补充
对账
支付中心系统设计时，要考虑业务与数据不一致的问题，系统错综复杂时，如何保证支付系统的账务准确，对账的作用越来越明显。在一个完整的电商交易平台中，还会涉及折扣、积分兑换、满减、余额等支付场景，而且其中又夹杂多商户聚合支付。比如用户在双十一活动下了一单，付完款。过程中使用了某个优惠券（优惠10元），但由于系统Bug实际付款时并没有减少。正常逻辑，可能会出现用户投诉后，从客服或者工单情况才能反馈，可能几个小时以后才发现。如果有相应的对账能力，实时检测系统，在这个问题被用户发现之前就已经开始报警，提前发现并解决问题。为了解决这些问题，对账在支付系统中的位置越来越重要。
在阿里内部，为了解决业务与数据不一致的问题，内部有一个实时业务审计BCP（Business Check Platform），BCP平台并不仅限于交易类业务，也适合其他对业务稳定性要求比较高的领域，通过事件模式，把业务数据变化触发的消息转换为相应业务类型的事件，放入到事件执行队列进行规则检查。
这里列举一些对账的场景：
促销活动相应单据的一致性
主订单与子订单金额一致性
主订单与子订单状态匹配
逆向交易，如退款后，订单款型与退款金额匹配
下单后订单有超时信息
物流单据生成后，具体是否发货
订单历史快照是否完整
对账主要是保证三项数据的一致性：订单流水、支付流水、渠道流水。
第一阶段对账中会涉及会员积分的核销、运营折扣的匹配所以后期会专题分享；第二阶段与第三阶段很像，都是根据下游系统生产的对账文件和本地的订单或者流水核对。
对账系统的设计参考
数据接入：业务日志接入
数据转换：数据的转换、整合和统计，行程数据源
规则制定：规则的制定，对比和执行引擎
结果处理：存储、分析、展示、执行
对于差错处理，一般通知业务端进行人工处理，如果大量错误，根据实际情况把一些频繁出现的场景通过系统自动处理。举个例子，我们可以从格式化的对账文件中抽取流水号、类型、状态、金额、商户号等关键字段和本系统的订单匹配；一个简单的规则可以是“ID+金额+状态”，如果前后一致，则该笔订单直接核销，打上对账标记。对于不一致的场景又会有三种情况，差错处理手动排查方案可以有：
本地有ID，下游有ID，可以匹配但是状态不对：调用状态查询接口同步状态；
本地有ID，下游无ID：根据ID查下游订单，检查订单状态；
本地无ID，下游有ID：根据ID查本地订单，或查询日志。
对账系统具体执行时，需要考虑对业务系统的侵入，对账系统也可以做高并发高性能的架构优化，比如数据的采样率、规则分组、异步存储、延时保护，也可以采用大数据等实时或延时处理分析等。
要补充一点，对账系统设计不是支付中心的必须，而是一个补充。对账系统是一个stand by的方式，异步运行与支付中心，起到一个监控的作用，提供相应系统改进意见和临时补救。支付系统和相关应用设计本身的问题，还是需要自身进行修改。不能将对账系统作为所有问题的最终解释环节，而应该是一个监督和审计作用。
支付风控
核心是梳理业务风险，制定风险防范规则
数据来源：主要是相关的交易、订单、账户和信用相关内外部数据
事前：相关的信用签名验证、单笔/单日限额、频次的限流
事中：根据风险规则定义，进行通行/延迟/进一步验证/拒绝
事后：风险之后，进行复盘，降低级别、巡查警告和进一步数据分析
小结
支付系统对支付渠道进行封装而对业务方提供的支付能力，实现在线收付款交易以及管理交易资金等功能。
支付系统的核心：支付单、支付方式、支付动作、支付渠道、支付网关、支付账号、支付管控
支付中心参考架构：应用层、能力层、领域层、网关层、系统层
支付的核心流程：支付网关、支付路由、风险评估、订单更新
支付对账可以辅助系统检查业务与数据不一致的问题，提前发现问题起到监督和审计的作用。
参考
因微信外链限制，请点击“阅读原文”查看知乎同文。
浅析支付系统的整体架构
基础向：从 0 开始学习支付系统架构
电商系统：对账设计
王思轩，计算机博士，阿里云业务中台&云原生架构师
加拿大卡尔顿大学计算机博士学位，哈尔滨工业大学和法国波尔多大学双硕士，哈尔滨工业大学本科，发表过10余篇国际学术论文，7年海外学习工作经验。现主导新零售领域重点项目的中台架构咨询，和云原生技术的赋能工作。曾就职于华为，Qlik，Honeywell。
? end ?
作者 | 王思轩
架构思轩
架构师思考小屋
空·
