支付系统设计白皮书：契合业务形态的收银台设计思路 – 人人都是产品经理,
目前常见的收银台支付类型分为收单和充值两种，其业务流程和系统流程各不相同。
支付方式选择
在收银台设计前，根据业务类型要对支付方式进行选择，目前常见的收银台支付类型包含两种：
收单：通过各类支付方式针对业务订单发起付款。例如：C 端用户在天猫购买一件衣服，点击「提交订单」后，系统跳转至支付宝进行付款。这是标准的付款场景，也称之为收单。 充值：用户对账户进行余额充值。例如：C 端要用户登录支付宝等商户自有的钱包系统对账户进行余额充值。这是标准的充值场景。业务流程及系统流程
1. 充值业务
①业务流程
用户对钱包账户发起充值； 跳转至收银台，根据展现的支付方式用户选择充值渠道（若该充值业务允许提现，收银台应根据充值业务配置对应的借记渠道，从业务侧规避用户使用信用卡充值做信用卡套现）； 充值成功后返回。②系统流程
2. 收单业务
①业务流程
用户在业务端基于订单发起付款，跳转至收银台后选择支付渠道； 根据用户选择的支付方式决定后续流程：余额支付：首先校验余额是否充足，若充足则用户可选择余额进行全额付款；确认付款后输入支付密码并校验支付密码是否正确，若正确则扣减余额，完成支付；
网银或第三方支付：首先根据业务确定可使用的支付渠道列表，其次用户选择第三方支付后，调用第三方支付渠道发起付款，渠道限额校验由第三方完成，最后根据支付结果变更支付状态（正常情况下除了支付成功意外均以「处理中」做业务状态处理）。
②系统流程
组合支付
组合支付即通过一种以上支付渠道完成付款的支付形式。组合支付是交易系统中提供的一种交易服务类型，例如早期支付宝有组合支付功能，最常见的组合支付类型为「账户余额 + 快捷支付」模式，此种类型可在做支付系统设计时进行借鉴，可实现「账户余额 + 第三方支付」的模式。
组合支付的衍生需求很好理解，当用户在平台的钱包账户内进行充值后，若想购买的商品价格超出了账户余额的可支付范围，即可使用组合支付的方式进行付款；此处的账户余额可理解为「广义范围内，所有涉及到支付系统内部清结算能力的支付形式」，凡是需要与其他渠道进行组合付款的场景均可使用组合支付的逻辑，例如基于营销设计的红包、代金券、积分以及预付卡等。
组合支付的流程、设计
1. 组合支付的流程
①余额 + 第三方（支付成功）
②余额 + 第三方（支付失败）
③组合支付设计
组合支付本身对于交易系统来说差别不大，仅在订单发送至支付前置时，由于逻辑上来讲是两笔付款行为，因此会生成两条支付方式的请求：一条为余额支付请求，一条为第三方支付请求；转换到支付前置后，前置系统生成一笔组合支付的订单，且对应着两条支付指令（一条充值、一条转账），当充值的指令成功后去执行转账的指令，两笔都成功的情况下则通知上层系统变更业务状态。
定义支付业务类型：组合； 对应指令：根据外部加内部的组合，根据具体指令需执行的原子类型，生成对应指令订单，遵循外部成功后再执行内部的流程； 支付方式：以组合种类为准，对应种类在网关传递交易时进行拆分，例如代金券 + 余额 + 第三方支付则需要分别定义三条支付方式信息。优惠支付
优惠支付即基于支付系统的代金券、优惠券、红包等营销支付流程设计，本质上是基于账户做的营销支付体系，无论具体优惠形式，在支付系统内部都是以账户形式存在：例如代金券营销账户、优惠券营销账户等；根据具体的业务需求，支付系统对于此类营销支付在账户层面应设计两种方案：
平台侧营销账户：代金券营销账户、优惠券营销账户等，其营销成本应从这两个账户中进行扣减，账户需自行预先充值，用户支付时所需部分抵扣的金额从该账户进行获取； 用户侧营销账户：红包、消费积分等营销账户与各个用户一一对应，用户在领取时视为开通了红包等营销账户；每当领取红包或获取消费积分，视为账户金额增加（相当于给用户的账户进行充值入账）。此外，也可以通过业务端对明细账户加以控制，支付系统则去维护总账户即可。营销支付设计
营销支付的设计可分为基于业务端做营销和基于支付端做营销两个方向：
基于业务端做营销：在业务平台直接对优惠券金额进行扣除。
调用支付系统前，业务系统根据优惠方式（立减、折扣或优惠券等）对可优惠金额完成计算并直接扣减调； 调用支付系统，并将用户实际待支付金额转入支付系统并生成支付订单。此方法的弊端在于，若平台型电商对营销成本进行结算，仅可通过线下或其他方式完成与商户间的结算工作，会增加财务工作量并造成账务不清晰等结果。
基于支付端做营销：可分为平台侧与用户侧两部分。
（1）平台侧：
将平台的优惠补贴金额通过内部户等形式存储在账户系统当中，类似「营销补贴户」； 用户在前端发起支付时，使用优惠券、红包、消费积分等营销工具抵扣部分金额，业务平台调用支付系统下单并传入总金额、支付金额以及抵扣金额等相关信息，根据总金额生成交易订单后，根据总金额的构成生成对应的支付订单；实际支付金额与用户待付款的支付订单相对应，抵扣金额为平台内部账户单独的内部流转支付订单，通过用户实际成功支付的消息进行后续处理；此类方法的优势在于将每个用户的业务明细留存在业务平台系统处理，支付系统只需要记录金额；收银台调用支付平台下单相关参数：业务平台订单号、UID、总金额、抵扣金额、支付金额、支付方式。
（2）用户侧：
当前电商平台有部分营销产品拥有较强的用户属性，例如红包、消费积分等，此类自带货币属性的虚拟账户余额，根据其业务属性对支付系统中的每位用户单独开设补贴账户，支付时根据营销账户 + 其他支付方式进行组合，与组合支付的逻辑相类似，一笔付款付多个付款渠道。
《支付系统设计白皮书》由 PingPlusPlus支付学院（ID：pingxxpi）出品。
本文由 @支付学院 原创发布于人人都是产品经理，未经允许，禁止转载。
题图来自 Unsplash，基于CC0协议。
相关知识
情人节的5种营销思路 – 人人都是产品经理,
电商商城系统开发工作说明书 SOW – 人人都是产品经理,
商业化：程序化广告生态 – 人人都是产品经理,
某社区APP完整原型案例（附源文件下载） – 人人都是产品经理,
项目中如何争取资源 – 人人都是产品经理,
智能座舱智驾产品设计 – DMS 功能深度解析 – 人人都是产品经理,
换个角度，以用户的身份探寻会员体系 – 人人都是产品经理,
网约车的十年：纷争、整合、嬗变 – 人人都是产品经理
从产业互联网角度，分析「花点时间 」 产品 – 人人都是产品经理,
鲜花电商的春天来了吗？ – 人人都是产品经理,
网址: 支付系统设计白皮书：契合业务形态的收银台设计思路 – 人人都是产品经理, https://m.huajiangbk.com/newsview561542.html
| 上一篇: 智能收银台V3使用说明 |
下一篇: 金砖提到的跨境支付体系意味着什么 |
