收单网关的设计要素包含：业务方、用户、业务系统、支付系统。

收单网关

收单网关是平台方支付系统和用户/商户的PC、移动APP所使用的外部网络之间的接口，为支付系统操作将外网传输的数据转换为系统内部数据，同时负责将平台业务系统的内部请求转化为支付系统的内部数据。

收单网关的职责为支付平台化后，系统内部接口不可对外，因此所有外部系统需要通过统一的网关接口调用支付平台；由网关进行一系列格式校验、参数校验、业务调用权限检查后再向支付进行转发。

收单网关设计要素包含：

业务方：指业务平台。可根据公司业务规模大小、业务领域或公司主体等维度，对对接的业务方进行区分，接入后这些业务方即成为支付平台的收单商户，使用平台支付产品实现其收付费功能需求；

用户：业务平台 C 端用户，可根据业务方进行划分；

业务系统：业务端的业务系统；

支付系统：支付清结算平台。

收单网关流程

• 构造请求信息：业务系统根据支付系统提供的接口规则构造请求信息，例如支付下单、取消订单、退款等等；
• 发送请求信息：把构造好的信息发送到指定的地址；
• 处理请求信息：支付系统会得到请求的数据信息，按照预定的验签，业务参数校验等一系列验证通过后，将请求的数据信息对业务（对应支付、取消、充值等等）进行处理；
• 返回响应信息：支付系统会以同步和异步两种处理方式，返回业务数据处理结果；一般情况下，同步通知仅代表请求处理成功，业务订单处理状态会以异步通知的形式主动回调用户在下单的时候设置的异步回调地址，通知业务方时若得不到业务方的响应信息值「success」，支付系统会重复若干次（按照一定的频次配置），以防止掉单现象；若业务方户不设置，则不会通知；

业务系统收到异步通知后，结合自身的业务规则改变支付单状态，进行如订单状态更新等业务处理。

接口定义

• 业务系统和支付系统之间通过 https 协议来进行通信，接口以 URL 的形式提供并以 post 的请求方式进行处理；
• 文档的接口包括两种：服务接口和通知接口；
• 服务接口由支付系统提供，供业务方调用；
• 通知接口由业务方提供，供支付系统调用；
• 虽然通知接口由业务方提供，但是仍由支付系统制定接口规范；
• 服务接口包括接口说明中的所有接口信息，通知接口目前仅包括交易状态和退款状态的通知等。

接口设计说明

• 基本请求接口：所有请求接口都要加上基本请求参数，例如接口名称、版本、App ID、签名、签名方式、同步跳转地址等关键信息，当发起调用时，所有业务接口都会加上该接口参数，可参考支付宝和微信等第三方支付公司的接口参数定义。
• 服务请求接口：根据支付系统本身的能力抽象出的业务接口，给到外部业务方进行调用。
• 即时到账交易网关接口：买家在业务系统中选择购买商品下单，付款成功后金额直接入卖家账户。
• 担保交易网关接口：买家在业务系统中选择购买商品下单，有部分金额为担保金额，买家付款成功后，担保部分进入平台方账户，未担保金额直接入卖家账户。
• 结算（分账）网关接口：买家使用担保交易下单付款完成，在收到货物后，将担保金额结算给卖家。
• 继续支付网关接口：买家在支付页面未成功支付，需要在业务系统中继续支付时，调用该接口。
• 退款网关接口：买卖双方在达成退款协议后，可针对及时到账交易，订金下定等已支付交易 由业务系统发起退款请求。
• 交易查询网关接口：因为某一方原因， 可能导致业务方在预期时间内都收不到最终支付通知， 此时业务方可以通过该接口来查询订单的详细支付状态。
• 通知接口：根据业务方提供的通知地址，将支付结果等信息返回给业务方

①交易状态变更通知：通知业务方时，接口信息里面会传递业务订单号、交易订单号、状态、金额、时间等相关信息，以便业务方能更好的做业务处理；

a.交易状态：交易订单的状态；

1. 等待买家付款
2. 付款成功
3. 交易成功
4. 交易结束
5. 交易关闭

②退款状态变更通知：通知业务方时，接口信息里面会传递原始业务订单号、退款业务订单号、退款交易订单号、状态、金额、时间等相关信息，以便业务方能更好的做业务处理；

a.退款状态：退款订单的状态；

1. 退款成功
2. 退款失败

交易服务

交易服务的作用

• 将支付系统的支付能力抽象出来，提供各类交易方式，例如下单、支付、修改金额、确认结算、退款、关闭交易、查询等标准接口，对外输出收单网关；
• 基于收付款方的交易链业务路抽象交易类型、交易产品以满足不同业务方各类交易场景的需求；
• 鉴权校验、交易结果通知；
• 对接业务方。

担保收单交易

①担保交易：用户在业务平台中选择某商家的商品进行购买，支付完成后该笔订单资金进入平台的担保账户，等到用户确认收货后，将该笔订单的资金结算给对应商家账户；此交易类型也可以适用于一些具备结算周期等时间属性的业务当中，通过网关的担保收单接口和结算接口做到由业务方灵活控制结算账期。
②流程

③担保交易设计

定义担保交易产品代码，标识此类交易订单的类型。担保交易分为下单支付和结算两个环节：

• 第一个环节为下单环节，交易参与双方当中付款人是用户，收款人则是平台在支付系统内部开设的一个担保账户，担保账户属于内部的一个结算过渡户，代表着这钱是要给出去的，时候时候给出去基于业务方的指令来决定。
• 第二个环节在发起结算的时候，确认之前这笔担保交易订单需要和商户进行最终结算，此时基于业务方调用结算接口，交易参与双方当中新增两条收付款人记录，付款人为担保账户，收款人为该笔订单的商户；最终资金以内部户转账的形式将担保账户中该笔订单资金，转给实际收款的商户账户。

即时到账交易

即时到账交易即用户在平台上选择商品购买并支付，付款的资金立马结算到商家的收款账户中。

例如，早期支付宝 PC 端的即时到账产品，用户通过 PC 网银即时到账产品付款后，单笔交易即时结算到了商户的平台账户中，由此可得：

• 若支付宝不垫资，则即时到账底层包装接口的银行为 T+0 给到支付宝；
• 若支付宝垫资，则银行资金未结算前，支付宝将备付金账户中的存量资金为商户的平台账户进行结算。

即时到账交易与业务场景息息相关，在某些非担保流程中，若用户付款后需要立马进行履约的情况，则适合即时到账产品，例如各平台的会员产品购买场景。

①流程

②即时到账的设计要点：

• 定义担保交易产品代码，标识此类交易订单的类型；
• 和担保收单的区别，在于即时到账产品没有单独的结算环节；在下单的时候，接口参数里包含分润参数，当交易发起时就需要业务方算出该笔订单分润收款主题数、确定好用户的 UID（给谁充值）、账户类型（给什么账户充值）、金额等参数；
• 分润原则：先收钱再分钱且收到金额 ≥ 分润总金额，即先入后出、收大于等于付。

充值交易

充值交易即用户对账户余额进行充值，一般运用于充值虚拟币、钱包余额等产品。用户对账户余额进行充值，一般运用于充值虚拟币、钱包等产品，首先需要对充值的两种做法做一个区分。

• 业务平台充值
• 支付平台充值

例如，在用户感知层面，早期的支付宝与淘宝不分你我，支付宝像是为淘宝定制的专属钱包，但实际上用户在支付宝充值的余额与淘宝业务并无关联；而腾讯的虚拟货币 Q 币则是由业务端发起的交易，因此与业务平台具有强关联性。因此基于支付平台的两种做法，一种是基于支付平台的账户做充值，另一种是基于业务平台做充值。

①流程

②充值交易的设计要点：

• 首先定义充值产品的产品代码；
• 业务端充值（虚拟币）：此类产品虚币账户体系独立于支付系统；

1. 充值和虚拟币的消费业务端完全闭环，由支付系统内部针对该充值业务开设一个统一的收款账户，结算时通过支付系统提供的入账记资金分润，适用于直播、视频等纯互联网虚拟业务；
2. 接口定义：下单支付接口；
3. 优势：开发成本低，实现起来相对简单、可快速实现业务；
4. 劣势：账务不清晰，流程不统一、有一定资金风险。

• 支付系统充值：通过支付系统账户体系实现，所有充值资金通过钱包收银台或支付系统的充值网关接口实现；

1. 钱包收银台：充值行为发生在支付系统体系内（参考前文中讲到的支付宝逻辑）且独立于业务平台。原则上当公司业务规模扩大，不同的 App 统一接入支付系统时，独立的钱包账户余额应可同时支持不同业务的账户支付需求。例如，美团账户余额充值的资金同时适用于美团外卖、点评等，此时美团的钱包已经是拥有独立账户体系的产品，接入各业务平台仅需不同业务端识别用户的唯一标识即可；
2. 充值网关接口：针对于业务方发起的充值行为，各个业务平台自己本身具备充值业务需要支付体系的账户能力提供支持。通过网关充值（入口在业务端）且可以满足各个业务方不同账户类型的诉求，需要每个业务方在用户发起充值时，充值至用户在此业务下开设的对应虚拟账户，例如 B 站的 B 币、金瓜子等，就来源于不同的业务方开设的不同虚币账户；
3. 接口定义：充值接口（账户类型、uid、金额、支付方式等）；
4. 优势：资金账户清晰、流程标准化、所有支付、账户由支付系统控制，资金安全有一定保证；
5. 劣势：开发成本高，实现起来相对复杂。

出款交易

出款也称之为提现。用户基于自己账户余额发起提现，一般电商平台涉及到的场景为 C端用户的钱包账户余额提现和B端用户收益账户的余额提现，是将资金从平台的虚币账户转移用户外部账户的过程。具体分类可分为出款到卡及出款到账户。
①流程

②出款交易的设计要点：
定义产品码，可以拆分为出款到卡和出款到账户等不同的产品，针对 B 端商户的提现交易记录，原则上最好单独用表单显示；按照流程图所示，提现时首选要做好余额校验动作；

1. 出款到账户：目前常见的场景为用户发起提现到支付宝或者微信账户，接入支付宝微信等第三方支付公司的付款产品即可满足此需求，业务端需做好用户端的第三方账号信息采集，用户发起提现的时将账户等相关信息上传至第三方等待出款结果即可；根据业务模式，针对 B 端商户提现时，优先做实名认证再发起提现，且发起提现的账户信息和实名认证信息一致为佳，再根据业务端需求判断是否有针对 C 端用户做实名认证处理的必要；
2. 出款到卡：和付款到账户的主流程没有太大区别，但一般情况下需要商户端采集用户银行卡信息，因此需要将支付系统中存储银行卡相关的数据（卡 Bin 信息、城市、省份等），并对业务  端提供绑定、查询等接口为佳，这样用户前端绑卡时无论是卡 Bin 接口验证，还是前端做选择输入银行都能拥有较好的体验。*提现到银行卡需要接入对应的银行卡出款渠道。

《支付系统设计白皮书》由 PingPlusPlus支付学院（ID：pingxxpi）出品。

本文由 @支付学院 原创发布于人人都是产品经理，未经允许，禁止转载。

题图来自 Unsplash，基于CC0协议。