《支付系统白皮书》读书笔记

背景：

    上个月接受资金池系统，月底又要出财务报表，一个月没顾上看书，利用假期补上两篇读书笔记。也是对账ping++的《支付系统白皮书》来看，现在所负责的支付系统是什么状态，要往什么阶段去演进。

一 支付系统概述

1.1 什么是支付系统

在古代随着生产力的发展，有了剩余物品，有了货币，有了文字、数字，才有古老的会计（数量跟计量单位），反应了账单的内容。 现代支付系统伴随电子商务系统发展来生，提供了在线收付款交易以及管理交易资金的功能。

业务系统将用户购买行为通过各种订单的方式进行记录，有支付系统进行处理，最终有支付系统进行收款与付款。通常收法律规定，一般公司是没有持牌的第三方支付公司，所以需要跟银行及三方支付对接完成交易资金的处理。

支付系统的三个特征：

1.同一封装交易的接口，对接外部交易渠道，为业务系统实现交易订单的处理功能。

2.根据业务系统设置的资金配置规则，根据资金配置规则完成交易资金的自动化清分和结算，然后通过已对接的外部交易渠道完成划付。

3. 帐务数据的记录功能：上述的交易、清分、结算形成的资金变动信息，需要支付系统通过账务数据记录功能加以记录，对交易资金进行统计，并完成交易资金核对等财会工作。

***************************************

现有系统，对比下上面三个点：

1 业务系统进行订单的计价、下单、派单的逻辑，结算系统抽佣后，有交易系统进行支付。

2.交易推送订单的账务信息到资金池（会员账户系统），资金池再推送到清分，清分走光大银行的托管进行虚拟指令操作，资金池再进行结算，更新账户的可提现额度等，司机鉴权后发起提现申请。完成资金的划付。

3. 目前只有资金池的账户系统，缺乏对应会计账务数据，导致出财务报表异常困难，不能有效的支持，依赖BI的大数据平台，通过hive的形式，效率低下，每到月底都需要人肉支持，疼点之一。

1.2 支付系统架构

  支付系统主要职责是处理业务系统发起的交易请求，可以从各个组成模块的职责，来分为业务层、支付层两部分。

   

业务层：对接业务，提供支付的接口或者页面（实际落地可以灵活，比如收银台有的业务线就想自己做页面，那我们支付系统提供接口就好），处理业务系统提交的交易请求。

支付侧：负责通过支付渠道完成实时的资金的收付款、记录参与交易的账户间的流转情况，按照预定规则对账户资金进行拆分合并。

1.2.1 业务层

业务层包含：收银台、交易系统、及会员账户系统。

收银台

及用户常见的付款前选择支付渠道的页面，是支付平台对外提供的基本功能之一，职责是协助业务平台完成支付交易，想用户提供一致的交易体验。实际落地有提供页面（FE），或者提供支付接口（业务侧做页面），或者提供二码合一（微信、支付宝）的中转码等不同方式。

具体业务场景：包含支付与充值两种。目前来说都是即时到账的，（司机的实际到账不一定，收冻结期及鉴权等限制）

支付：多种支付方式（包含三方跟优惠券）

充值：对于余额充值常见。

服务模型：这里考虑的因素很多，对于常见的小公司，对接主流的第三方（微信、支付宝即可），看看及时到账或者担保交易是否满足业务需求。要不要对接网银、或者三方pos转账等？需要实际业务考虑。很可能线下POS转账，运营人员不规范，月底对账很麻烦，不如线上化方便。

交易系统

  交易系统本身是作为支付系统的外部处理业务逻辑的外围系统。支付系统本身相对稳定不是为了面向业务系统，为了满足业务系统的多变复杂，交易系统起了将外部业务系统转化为支付系统可识别的支付订单并导入。

从实际的下单支付场景为例：用户支付对应的交易状态为支付成功。司机确认后订单状态为交易的成功状态。在触发后续动作。

从支付跟确认两个环节来看，交易系统是把支付系统的基础支付能力包装后对外支持业务的一款产品。

交易系统的职责：

对接上层业务系统（）

抽象支付系统能力，对外提供接口：如下单、支付、修改金额、确认订单完成，退款以及查询能力。

定义各种交易类型，如担保交易，及时到账，充值、提现等。

交易系统的边界

下单：生成交易订单，确定交易参与。

 退款：已支付订单进行退款，退款金额不得大于原来支付金额，通常退回原账户（三方超时退款或者原账户注销等改为人工操作），关联入款订单。

修改金额：通常对于未支付订单，修改交易金额，去支付。

查询：查询交易结果，支付结果。

通知：通知上层业务系统交易状态。

算费：通过子系统计算每笔定单的手续费（我理解平台抽佣子系统的入口也在这里）

交易系统的交易类型：

及时到账交易：电商平台那种买家付款成功直接进入卖家账户。

担保收单交易：买家支付金额进入平台的担保账户，

收单退款交易：可对已支付交易发起退款，实际入口不一定在用户端。

合并支付交易： 多笔订单进行合并付款，购物车中多个不同商家生成订单。（复杂在于订单如何匹配营销进行拆分子订单）

充值：把用户的三方资金充值到用户的账户余额。

提现：用户账户余额提现到用户绑定的银行卡账户（需要做四要素的鉴权）

冻结解冻：除正常业务需求设置账期（T+N）外，还可以对涉及某些原因（违法），对账户进行冻结不可提现，保证资金安全。

业务类型：

收单交易：支付入款类型交易，付款人收款人两个角色。

充值交易：账户充值类交易，付款人收款人是同一个人，从外部账户到内部账户。

出款交易：基于账户做提现，付款人收款人是同一个人，从内部账户到外部账户。

退款交易：收单入款交易的反向流程。

 

会员系统（账户系统）

 非平台类只对接支付即可，平台类需要有账户系统，包含用户信息（可以在CRM），绑定银行卡信息，账户流水等。

1.2.2 业务层

业务层包含支付核心，账务核心，清算核心。

支付核心

支付核心的职责：通过后端的清结算、会计、账务等系统统一协作，让前端支付产品跟关注本身业务逻辑。同时通过标准化的支付指令定义，统一前端支付产品的支付请求入口，提供各类产品使用的基础支付服务。

支付系统的边界

支付服务：封装底层支付系统的接口，提供多个支付方式进行的组合支付。

支付服务流程：具体定义支付、充值、提现等原子类型，并对服务流程进行编排。

支付指令：通过支付协议加工得到支付指令，包含后续操作全部要素。

支付协议：包含产品支付流程、收付款信息，对应的支付渠道信息。

目前：欠缺的的是财务系统、会计系统、核算对账系统。靠月底手动导报表去跟财务对账。

图上的交易与支付拆分开，目的是为了体现出支付系统的核心支付能力，产品层管关注产品本身逻辑，将后端标准化的逻辑交由支付层跟结算层来处理。做到了标准与灵活的兼顾。

财务核心

 根据业务系统的要求设计相匹配的账户类型，管理各类账户，记录账户的资金变动，同时按照公司内部的财会规范提供反应各账户资金变化的会计数据，负责将自身记录账务流水与支付渠道结算资金和结算流水进行核对，并处理对账中的差错处理。

清算核心

 清算核心负责维护客户参与交易时的清分、结算规则，按照已配置的规则完成交易资金的清分、结算操作。