支付是指为清偿商品交换和劳务活动所引起的债权债务，货币债权从付款人向收付人的转移的过程。支付能力是电商产品的核心能力之一，作为订单同学，有必要了解关联域支付的流程以及基本概念，同时支付领域的很多设计思路与资损防控经验对订单域的系统设计也很有借鉴意义。本文将从支付系统的历史、基本概念、系统设计、资损防控与订单与支付交互等方面予以介绍。
一、支付系统历史与演进
支付的历史演进可以追溯到现金交易的起源。随着时间的推移和科技的不断进步，支付系统经历了多个阶段和变革。
起源：票号与钱庄
票号是应埠际汇兑需求而开设的金融专营机构，主要经营存款、汇款、汇兑三大基本业务，是现代银行的雏形。客户在票号交了银子之后，票号就开出汇票给客户。客户可以随身携带汇票而不用携带大量的银子，只要凭票就可以到全国各地的分号兑出银子。分号给客户兑换之后先内部记账，各分号间定期会当面进行对账。镖局就专为票号来运送银子、为商人运送票据。在这种模式下，汇票+账本（手工记账）是票号在支付环节的信息载体，解决了信息流问题；镖局替票号运送资金，解决了资金流的问题。
第一阶段：手工联行（1989前）
早期，国内的金融环境没有达到让央行推行全国统一结算制度的客观条件。于是央行当时提出商业银行要“自成联行系统，跨行直接通汇，相互发报移卡，及时清算资金”。同一家银行的总行及分支机构称为“联行系统”。同一联行内的资金结算，由联行总行自己做。跨行业务可以由央行清算，也可以由商业银行自己清算。在这种模式下，各银行需要告知其他行的交易信息构成了特定的公文，加盖印鉴后在银行间传送。这种公文叫做联行信件，而当时的邮电局则承担了收发联行信件的重要业务。
联行信件整个过程基本都是手工处理，与明清时期的票号相比，并没有太大的改进。虽然运行成本较低，但容易出现差错，且资金汇划效率依旧不高，导致占压在途结算资金较多，如异地间资金的汇划，少则 10 多天、多则半年才能完成资金到账。
第二阶段：电子联行（1989~2005）
1990 年，中国人民银行清算中心建成，专门为金融机构提供支付清算服务。清算中心包括 NPC（National Process Center，国家金融清算总中心）和 CCPC（City Clearing Processing Center，城市处理中心）。1991 年 4 月 1 日，全国电子联行系统（EIS）开始试运行。EIS 是基于金融卫星通讯网的，它是人民银行专门用于处理异地（包括跨行和行内）资金清算和资金划拨的系统。它连接了商业银行、央行、NPC 和 CCPC。以一位上海招行银行卡的用户要给持有北京工行银行卡的朋友进行汇款，使用 EIS 完成一次支付清算的案例如下图所示：
图片
借助全国电子联行系统，传票和凭证已变为加密后的电文，与纸质联行相比，进步巨大。客户的资金在途时间缩短到了一两天，大大提高了资金清算的效率，可以说是一个重要的里程碑。
第三阶段：现代化支付系统（2005~至今）
中国人民银行支付清算系统（China National Automatic Payment System）是为我国金融机构之间以及金融机构与人民银行之间的支付业务提供最终资金清算的重要核心业务系统，整体架构如下图所示：
图片
简单介绍下该系统的几个核心子系统：
图片
在现代化支付系统投产之前，即使是电子联行系统也需要一到两天才能能够到账，而现代化支付系统将支付后实时到账变为可能，极大的提高了支付效率，提升了消费者的支付体验。技术变革往往会带来新的商业机会和变革，推动企业进行创新。国内的主流电子商务与电子支付平台起也从 2003 年开始兴起，这里现代化支付系统的投产时间（2002年、2005年）非常接近，很难说两者之间毫无联系。
二、支付系统基本概念
核心概念
支付系统一般指提供支付清算服务、实现支付指令传送及资金清算的系统，由有支付牌照的支付公司提供。支付系统是连接消费者、商户（或平台）和金融机构的桥梁，实现了支付、资金清算、查询统计等功能。这里系统的解释一下涉及到的相关名词，便于我们后文展开详细介绍。
图片
图片
常用支付形式
平台支付
用户提前注册并登录到第三方支付平台，并且已经在该平台上完成绑卡等操作后，通过第三方支付平台进行支付。
网银支付
用户在完成必要的银行网银开通手续后，可以通过银行的网银系统进行在线支付和转账。在进行网银支付时，用户需要登录银行网银系统，输入相应的支付信息并进行身份验证，然后可以完成在线支付交易，移动互联网时代较为少用。
快捷支付
一种简化了支付流程的支付方式。通常情况下，用户在首次支付时需要绑定银行卡或者进行一次认证，之后就可以使用该支付方式来完成交易，无需重复输入银行卡信息或进行繁琐的身份验证。在后续的支付过程中，用户只需进行简单的确认操作或者输入支付密码，就能够快速完成交易。
协议支付
协议支付也称代收或者代扣，代收指渠道授权商户可以从用户的银行账户中扣款，一般用于定期扣款，如水电煤气、有线电视费、包月/包年会员费等。
虚拟货币支付
不少公司会有自己的虚拟币，这些虚币也可以作为一种支付方式。一般会有一些金额、品类的限制，如虚拟支付不得超过每笔订单结算金额的 50%。
余额支付
为用户建立本地账户并使用账户来完成支付，账户支持充值、提现等操作。
信用支付
指使用信用账户进行透支，类似信用卡支付。需要较强的风控能力。
三、支付系统简介
整体架构
在了解了支付系统相关演进与基本概念后，我们再来看一下支付系统的整体架构。对于订单同学来说，在实际支付业务的接入过程中，可以接触到两类支付系统：
第三方支付系统：即订单同学理解里的“支付渠道”。比如我们作为商户直接对接到微信、支付宝的支付系统中，从而具备支付收款能力。整个系统中的“核心系统”功能往往是大家最为熟悉的部分，它概括了我们平时各种消费支付场景。我们平时进行的电商交易、红包转账等都是“支付应用”的体现形式。
图片
实践中，三方支付系统往往可以拆分为网关、金融交换、收单域、支付域以及账务域、会员域、营销域等多个领域。
- 聚合支付系统：即订单同学通常理解里的“支付”。主要功能为屏蔽各种第三方支付系统的差异性，提供统一的接入方式和支付产品，比如得物的汇金系统。
一个比较典型的电商平台的支付架构
支付流程
用户支付流程
从流量角度来看，对于一次用户发起的支付行为，请求首先达到支付网关，经过必要的安全验证和流量限制后，被转发给对应的支付服务模块。随后用户跳转收银台页面选择支付方式后确认支付，由支付系统对接银行/第三方支付机构的支付接口进行后续的支付。
图片
支付接口
以业内某支付产品为例，其提供了多种集成支付能力的方式，其中「手机网页支付」适用于商户无独立 App，通过移动端 H5 网站进行传播的方式。我们以一次手机网页支付为例，了解支付的核心接口。
图片
如上图所示，可以从交易支付的几个环节进行分析。
- 支付接口
在商户的 H5 网站下单并确认支付。
商户系统生成订单信息并构造支付请求发送到该支付产品系统。
系统校验通过后拼装本次支付所需参数返回给商户前端。
商户前端将页面跳转至该支付产品官方中间页，如果用户手机上安装了该支付产品 App，则自动唤起 App；如果未安装，则继续在当前页面进入官方 H5 收银台。
用户完成密码输入并支付。
系统内部完成本次支付单处理流程。
处理完成后，以异步消息形式通知商户后台 Notify_URL，确认此次交易成功。
处理完成后，从官方中间页跳转商户自定义支付结果页 Return_URL，展示支付结果。
完成本次支付。
- 交易关闭接口
针对需要的业务场景，支持主动取消订单（针对未支付订单，已支付单可走退款流程）。
用户发起/商户后台管理员发起订单取消申请。
商户系统向该支付产品系统发起关闭订单请求。
后台判断处理后返回取消结果。
- 交易查询接口
商户后台发起交易查询请求。
系统判断交易单存在，并返回交易结果。
- 退款接口
用户/商户发起退款请求
商户系统审核处理退款申请是否合法。
合法情况下，商户系统向该支付产品系统发起退款请求。
系统处理并返回结果。
相关渠道将资金返回（有一定时间延迟）。
- 退款查询接口
用户/商户发起退款查询请求。
系统处理后返回结果。
- 下载对账单接口
商户系统根据业务对账需要，发起对账申请，查询最新的对账单下载地址。
系统返回对账单下载地址。
商户系统根据对账单下载地址下载对账文件。
系统返回对账单文件。
资金流与信息流
央行在 2017 年 8 月发布《关于将非银行支付机构网络支付业务由直连模式迁移至网联平台处理的通知》，规定了非金融支付机构受理涉及银行账户的网络支付业务全部通过网联处理。目前业内采用的都是“间连”模式提供网络收单服务。这里以一次银行卡网络收单支付交易流程为例，整体资金流与信息流如下：
图片
- 【信息流】步骤 1 用户通过电商支付收银台下单并支付，电商支付处理支付业务数据，并将支付请求发到第三方支付渠道。
- 【信息流】步骤 2 第三方支付将请求转发至网联。
- 【信息流】步骤 3 网联将支付扣款请求转发到发卡行。
- 【资金流】步骤 4 发卡行从用户银行卡扣款，用户银行卡金额减少，返回支付成功给网联。
- 【信息流】步骤 5 网联记录支付成功数据，返回支付成功给三方支付。
- 【信息流】步骤 6 三方支付回调电商支付系统，更新支付状态和记录支付信息。电商支付回调订单系统，更新订单状态，给用户返回下单成功。
- 【资金流】步骤 7 网联周期性对三方支付业务做清结算，通过央行清算系统做资金清算划拨到三方支付机构备付金托管所在银行。
- 【信息流】步骤 8 三方清结算服务对货款商户支付交易记录做清算和结算，具体细节如下：
清算服务根据交易要素对商户主体交易按照约定的计费规则进行清算，记录商户主体因为商业交易而产生的债务债权，周期性生成对应的结算凭证。
结算服务按照约定结算周期和方式对商户主体产生的债权债务进行清偿,请求网联结算打款。
- 【资金流】步骤 9 网联通过周期性清结算方式形式做资金划拨到商户收款所在银行。
- 【信息流】步骤 10 商户结算收款银行账户显示货款到账。
从上图看，步骤 1 到步骤 6 体现了付款方付一笔钱的流程，表示了三方支付一笔收单业务的信息流和资金流，其中步骤 4 中付款方的银行卡余额会被实时扣减，发卡行侧记应付未付。步骤 5 网联记录支付交易相关数据作为跨行清结算业务的依据。步骤 6 三方支付侧更新支付交易结果并逐层通知至订单系统，同时把支付成功消息同步给三方的清结算，清结算依据交易支付的结算要素做清分分录，记录商户应结资金和应收手续费。步骤 7 属于资金流。由网联负责跨行周期清算，网联通过央行清算系统完成资金划拨后资金到了三方备付金账户。步骤 8 属于资金流。三方支付完成周期性结算凭证生成后通过网联发起结算打款，最终资金到账时间依赖于网联清算+资金划拨的时间。自此，一笔电商交易经过用户银行卡扣款、网联清结算、三方支付清结算，最终实现钱货两清。
资金结算
清结算是对交易支付数据进行全面整理、计算、汇总、检查核对和最终结算的过程，可拆分为清算和结算两个子域。清算域服务根据交易推送的信息，按照约定的计费规则进行清分、汇总，记录主体因商业交易而产生的债务债权，并定期生成相应的结算凭证。结算域根据约定的结算周期和方式，对商户主体产生的债权债务进行清偿。清结算确保了金融交易的安全性和准确性，保障各方权益。
抽象的来看，支付涉及业务主要可分为收、付、退、提、转、充等 6 大类（对于订单同学来说更关心的是收、付、退三大功能，对应订单的购买、履约、售后三个子域）。资金结算一般分实时结算与定期结算，我们以定期结算为例，分析整体资金结算的简版流程。
图片
计费
计费为通过对应的计费规则将业务流水消息转换为清结算的资金语言，生成对应的结算资金明细。
- 匹配 以交易业务的流水信息路由匹配到相应的计费规则。
- 清分 根据计费规则，将资金划分给交易中的不同角色，生成对应的计费结果与资金分摊明细。简单来说就是算清楚哪个费用项，多少钱，谁给谁。
- 分录 落地计费明细与结算明细变更。
汇总
根据清算明细，按照资金指令以及时间段进行汇总操作。
校验
主要是对整个结算的模型、指令以及单据、任务的完整性校验，以及账务资金核对检查等，确保最终结算前的数据无误。
结算
生成账单并执行相应的资金指令，完成最终的资金转移。
资金安全
支付业务的资金安全主要可以从准确、合规两个方面理解：
- 准确
信息准确：即信息不错不漏不重。应对思路为流程上的容错机制以及核对来实现。
时机准确：即不早不晚，应对思路为核对以及监控预警。
- 合规
- 二清合规
流程容错
单据关联
正如某些订单域内部的多种单据间存在关联关系一样，支付设计上也有单据间关联的设计。例如从流程上来说所有的逆向过程都必须持有正向的单据，因此退款必须要关联到原来的支付，退款支付单要关联到原支付单。单据之间的关联只要有以下用途：
- 状态一致性：正如订单域中的订单单据如果成功，则订单关联的营销单、支付单一定成功一样。支付场景的各个单据的状态也存在关联关系，例如创建退款支付单的前提是所关联的原支付单必须成功。
- 金额一致性：金额控制是退款的一个核心问题，控制不好很容易产生资损。由于支持多次部分退款，金额必须防止退超，这里包含两个维度，一个是总金额不能退超，一个是各个维度的资金组成组成不能退超。具体的做法是，每一笔退款的金额，都会在原单上累加记录到已退金额，记录已退款的总金额，校验不可超。
幂等
通过唯一键实现幂等是较为常见的实现方式。例如订单侧常见的重复支付退款是以订单号关联 PaymentNo 做重复支付校验的唯一键，支付侧交易单以外部单号 + 商户号为唯一键，支付单以交易单号 + 操作码作为唯一键。幂等可以有效的防止操作不重复，这里需要额外注意的是，幂等的可重入问题：例如对于一笔整单退的请求，上游请求退款 200 元，支付域已经处理成功，上游由于超时基于同一笔支付单号进行进行退款重试，此时应该返回成功而非业务校验异常。
重试
最大努力通知是支付领域常见的流程容错手段，分布式环境下，网络抖动、服务暂时不可用等都会造成业务流程处理异常，常见的策略为将请求放入 MQ 进行异步重试，重试间隔逐次拉长，重试如果成功，则回调交易，如果失败或者处理中，则继续重试（所以接口幂等支持可重入很重要，对重试更友好）。
- 例如订单收到支付成功回调后，开始处理订单流程。如果在下单阶段仅锁定库存、营销等资源，需要在支付回调流程真正扣减资源的话，这里需要对超时等场景进行重试（调用下游需要做好幂等），如资源扣减失败则关单退款
重试指定次数如业务单据仍未到达终态，则将订单信息持久到数据库中，通知人工进行处理。
- 例如用户卡注销，会员销户等问题导致退款退不出去，重试一定次数后支付单只能置为失败。等待产运联系用户后，在支付层重新生成退款支付单进行退款。
核对
核对是保障资金安全的重要机制。从时效角度来看，主要有（准）实时核对与离线核对（如 T+1 核对），实时核对的准确性不如离线核对，且需要相应的实时核对平台建设（例如得物的 DCheck 平台）。离线核对主要的问题是发现问题的时机较为后置，部分场景会影响系统的时效性。例如清结算与账务侧的每日资金核对失败会影响结算时效性。
从核对维度来看，主要可以有如下几种核对方式：
一致性核对：
资金在从业务端起点（数据由业务产生）到财务端终点（最终流入财务系统）中，在链路中的各个系统/表中都留有相应的凭证。例如交易一笔订单的实付金额对应着支付的一笔支付单的支付金额，商户一笔收单或支付退款会在对应的商户待结算户发生一笔动账，对应在清结算会做一笔有资金方向的清分分录。对这些金额我们可以建设相应的一致性核对任务进行核对验证。
图片
一致性核对包括双向一致性核对和单向一致性核对两种，单向一致性核对无法发现单边数据缺失问题。
业务正确性核对：
在特定的业务场景下，业务有自身的业务规则，可以针对这些业务规则进行校验。常见有以下四种方式：
一般正确性校验：例如某些支付业务只能用于特定的商品类型，则可以通过自定义SQL校验规则来进行校验。
总分校验：各个子金额汇总应当等于总金额。
顺序性核对：业务流程中有依次执行的处理流程，则可以校验是否有流程缺失。
幂等性核对：校验是否有业务被异常的重复处理，如重复退款等。
图片
时效性核对：
主要核对时效相关，如未支付的支付单在超时后是否及时关闭，结算时机是否满足时效要求等。
风险额度核对：
对一些可能有高风险的关键配置与金额相关额度进行校验，如分账比例
