本文属于ping++《支付系统》白皮书读书笔记系列。
3. 1收单网关
收单网关主要负责吧业务系统的请求转化为支付系统的内部请求，主要是进行参数校验、权限检查等再对支付系统进行转发。
这里白皮书提到了通常是基于https和post提交的方式，但是实际可以根据公司的情况，我们就没有这一层。直接接口调用了RPC。
接口定义
列举下相关的接口
服务请求接口：封装支付系统本身的能力，给外部系统进行调用。之前说的下单，支付就属于这种。
即时到账交易接口：买家付款成功钱直接到卖家账户。
担保交易接口：买家付款成功钱进入平台方账户。
结算（分账）接口：用户再支付完成后，对服务完成（如收货或者上门服务），确认订单完成，将担保金额结算给卖家。
继续支付接口：用户未支付的情况，在业务系统需要继续发起支付时调用。
退款接口：已支付交易有业务系统发起退款申请。
交易查询接口：业务系统没收到交易系统回调情况，可以来查询交易系统。
交易状态变更通知接口：包含交易信息通知业务方，以便业务方及时处理。
交易状态：交易订单状态：待付款、已付款、交易成功、交易结束、交易关闭。
关于退款：通常由于三方超时限制，需要财务人员线下处理。所以 返回失败实际意义要根据情况来衡量。
3.2 交易服务
3.2.1 交易服务的作用
- 将支付系统的能力抽象出来，对外提供各类交易方式，如：下单、支付、修改金额、确认结算、退款、查询等标准接口。
- 基于收付款方的交易链路抽象交易类型，以满足不同业务方各类交易长期的需求。
- 鉴权交易、交易结果的通知。
- 对接业务方。
3.2.2 担保收单交易
担保交易： 用户在平台下单，支付完成后，再服务完成（收货或者提供服务）后，将该笔资金结算给对应商户账户。是英语具备一定结算周期的业务，通过上面的担保收单接口及结算接口有业务方灵活控制结算账期。
当然，实际项目落地可以做的更复杂，比如及时业务方推送结算也可以是再额外约定冻结期，冻结期到了才开始真正的结算给商家。
实际上分为两个环节，下单支付跟结算。
下单环节用户支付的钱只是到了平台账户（属于临时过渡保管），这笔钱要给出去的，具体时间有业务方决定。
结算：业务方发起结算，才给收款人账户增加一条记录，以内部转账的形式把担保账户的资金，转给实际收款的商户账户。
3.2.3 即时到账交易
即时到账与业务有关，常见的场景如会员产品购买。
合担保交易的区别，没有单独的结算环节，所以下单的时候，即明确相关的参数（分润参数），就是哪个用户uid,给个账户，交多少钱等。
3.2.4 充值交易
充值交易及用户对账户余额进行充值。一版用于虚拟币或者钱包等。
书上列举两种方式：基于支付平台的账户做充值跟基于业务平台做充值。
流程
业务平台充值：充值、消费完全业务端闭环，支付只提供一种手段。
这里只介绍下较普遍的支付系统充值。虚拟账户在支付平台体系内且独立于业务系统，业务入口在业务端。接入业务平台只需要一套用户体系识别用户id。
优势：资金账户清晰、流程标准化、所有账户资金有支付系统控制、资金安全性高。
劣势：开发成本高。
3.2.5 出款交易
出款也称为提现，平台的用户基于自己账户余额进行提现。是将资金从平台的虚拟资金账户转移到外部账户的过程。
流程：
出车款交易可以 分为出款到三方账户跟到卡。针对B端的商户的提现交易记录， 最好单独用表记录，最好余额的校验工作。
1. 出款到账户：需要做好账户信息的采集工作。主要是对接三方（微信、支付宝），优先实名认证。
2. 出款到卡：需要用户实名认证（认证四要素），还需要把支付系统存储的银行卡信息（卡bin,开户行信息、城市）做鉴权。将两者信息做校验，当然还需要三方渠道进行支持接入对应的银行卡出款渠道。
实际在项目运营中，多数反馈的是鉴权问题，如收不到银行绑定的短信验证码，交易未明等信息。大多数需要客户自行咨询发卡行去解决。