深入浅出支付业务设计二三事

zjxp

本文主要以2B2B平台为例对尝试着对支付绑定、支付解绑、在线支付、退款等业务流程及设计方式进行说明、梳理。

背景

在线支付业务是所有电商平台的核心业务，我在人人都是产品经理的网站上使用关键字“支付”检索了下，发现关于支付业务的设计少之又少，不光是支付，关于商品、产品、购物车等等领域模型的设计也很少，大家都集中讨论在产品外在设计上，告诉你这个事情是怎么回事，但是没有告诉设计应该如何落地，个人认为一个合格的产品经理是一个既能进行需求分析、业务设计、同时也能做数据设计、分析的。
本文主要以2B2B平台为例对尝试着对支付绑定、支付解绑、在线支付、退款等业务流程及设计方式进行说明、梳理。如果您觉得有些帮助或者觉得哪里不对，希望小伙伴留言进行交流或者点个赞。
设计策略

在做支付业务设计的时候，产品经理不光要分析业务流程还要考虑设计策略，关于支付业务的设计策略主要体现在数据安全性和扩展性。
1、数据安全性

采用银联签名机制、加密机制确保支付过程中支付的安全性。
报文签名与验签机制的共同点：首先都需要对报文中出现签名域(signature)之外的所有数据元采用key=value的形式按照名称排序，然后以&作为连接符拼接成待签名串。其次，对待签名串使用SHA- 1 算法做摘要。
报文签名机制与验签机制不同点：

• 报文的签名处理机制如下：使用银联颁发给商户的商户RSA私钥证书对摘要做签名。最后，对签名做Base64 编码，将编码后的签名串放在签名(signature)表单域里和其他表单域一起通过HTTP Post的方式传输给银联在线支付平台。
  
• 报文的验签处理机制如下：使用商户入网时银联提供的银联在线支付通讯RSA公钥证书对摘要做签名。最后，对签名做Base64 编码，与返回报文表单中的签名(signature)域签名串做比较，如一致则验签成功，否则验签失败。
  

加密机制：对于持卡人密码银联在线支付平台使用RSA公钥证书对ANSI X9. 8 带主帐号格式的PIN加密并做Base64 编码后传输，以保障密码的安全性。依据商户可选配置，对于CVN2、有效期、卡号使用RSA公钥证书分别做加密并Base64 处理。对于敏感信息银行卡验证信息及身份信息部分内容，采用Base64 编码后传输，以做数据屏蔽。对于文件内容，使用DEFLATE压缩算法压缩后，Base64 编码的方式传输，压缩编码后的内容参与签名摘要运算。
2、程序扩展性

在支付业务分析设计后，其相关数据库表包括支付记录表 支付记录表支付银行表 支付绑定表 支付异常表、支付订单表;以后再有类似的在线银联支付业务可以直接进行复用，不用新建表。此外以下业务流程设计也可以进行扩展使用。
支付业务流程设计

首先介绍整个业务的整体业务流程、资金流业务流程。其次分别介绍支付绑定、解绑、支付、退款等业务流程的设计。
1、支付业务整体流程图

2、支付业务资金流顺序图

3、银行卡绑定业务顺序图

绑定业务：首先要建立绑定关系
建立绑定关系，指商户/收单机构的用户号(即报文中的绑定标识号)与用户的银联卡信息进行关联，关联信息留存在银联系统中。建立绑定关系可分为前台模式和后台模式，前台模式时，用户在银联页面输入相关银行卡信息;后台模式由商户采集银行卡信息发送至银联进行绑定。下面以前台模式为例进行说明，业务流程图如下所示：

流程说明：

• 如果采购方没有绑定过银行卡，会提示“请先绑定银行开再支付”;如果绑定过银行卡，会跳转至支付页面;
  
• 在绑定银行卡页面，如果第一次绑定银行卡，绑定信息中会进行“交易平台支付密码”新增操作，否则无此操作，一个采购方只能有一个“交易平台支付密码”，可在会员中心修改此支付密码;
  
• 在银联绑定卡页面，可选择储蓄卡和信用卡，点击“绑定”，跳转至银联绑定页面，输入卡号等绑定信息，绑定成功后会跳转到平台页面，绑定成功的卡可进行解绑。
  
• 绑定卡以后，可进行支付，在支付页面，选择一张绑定银行卡，输入手机验证码和“交易平台支付密码”，支付点击“支付”，支付成功会跳转至支付成功页面，订单列表中可看到支付成功后订单信息。
  
• 在已付款订单列表页，可对当天清算前订单进行退款，点击“退款”，会返回退款结果;如果订单支付成功，配送商(销售)可进行接单;采购方在配送商(销售)接单后可进行“确认收货”操作;
  

确认收货后，在第二天配送商(销售)可收到相应款项，如果订单开具发票，则款项打至对公账号，如果不开具发票，则款项打至对私账号
4、银行卡解绑业务流程图

银行卡解绑业务实际上是与银行卡绑定业务相对的业务，其业务流程非常相似。
5、银行卡在线支付业务流程图

一般交易平台支付有四个触发场景：购物车支付、直接购买支付、快速购买支付、订单列表支付。
触发支付操作后，根据是否开具发票来判断调用哪种类型的支付接口，如果开具发票且是增值税发票，调用B2B支付接口(前台交易)，如果未开具发票或开具普通发票，调用绑定支付接口，支付之前必须先绑定银行卡，如果是借记卡，调用借记卡绑定接口，之后调用绑定代收接口，如果是贷记卡，则调用贷记卡绑定接口，之后调用绑定消费接口。

从技术实现方式上交易大致可划分为前台类交易、后台类交易
前台类交易是指交易请求方(如商户、收单机构)与银联在线支付系统之间的交易信息通过用户浏览器进行传递的交易，是一种异步的、需要持卡人参与完成的交易类型。对于涉及金额的前台类交易(即交易请求中有金额字段)银联在线支付系统系统均会给请求方后台通知(后台通知报文要素同前台应答的要素)，请求方也必须实现接收后台通知。对于交易状态未知的交易请求方必须发起交易状态查询交易。

后台类交易是指交易请求方(如商户、收单机构)将交易信息直接通过请求方服务器发送至银联在线支付系统服务器的交易方式。后台交易均为同步短连接方式，不需要持卡人参与完成的交易类型。对于涉及金额的后台类交易，若通讯超时，则交易请求方必须发起交易状态查询交易。

6、银行卡退款业务流程图

银行在线退款业务根据业务需求设计如下业务规则：

• 整单整退(子订单不能单独退款，只能大订单进行退款)
  
• 当天晚上 11 点前的订单，在 11 点后不可以进行线上退款。其他情况请拨打400-0116- 666 人工处理退款)
  

已发货订单和交易完成订单不能线上退款，只能线下退款

7、整体接口设计

8、支付开发设计

8. 1 前台交易开发步骤

• 以表单的方式组装要发送给银联在线支付的数据对象(包括订单号、商户号、交易类型、交易金额、交易时间等各域)。每个域填写方法可参考文档《中国银联在线支付平台-商户接入接口规范》。
  
• 将组装好的数据排序好并用&连接后签名，生成signature字段，可使用插件包提供的方法“sign(未签名报文， 报文字符集);”。可通过调用插件包提供的签名方法来完成签名。
  
• 把所有要发送给银联在线支付的域包括signature和signMethod，组成表单以POST方式送给银联在线支付前台交易的地址。
  
• 交易完成后，银联在线支付系统将把交易结果分别返回通知到商户通的前台应答地址和后台应答地址上，商户接收到交易通知后可分别调用“coverResultString2Map(应答报文);”方法进行应答报文解析，和“MpiUtil.validate(应答报文， 报文字符集)”方法进行签名验证。
  

8. 2 后台类交易接口开发步骤

• 商户按照不同的交易组装报文，交易报文请参考《中国银联在线支付平台-商户接入接口规范》把组装好的数据排序好并用&连接后签名，生成signature字段，可使用插件包提供的方法“sign(未签名报文， 报文字符集);”。
  
• 把所有数据，包括signature和signMethod用key=value并用&符号链接的方式组装成字符串，通过插件包提供的方法进行发送。接收到返回报文后，通过插件包提供的方法进行验证签名，调用“coverResultString2Map(应答报文);”方法进行应答报文解析，和“MpiUtil.validate(应答报文， 报文字符集)”方法进行签名验证。
  

8. 3 合并付款交易接口

• 功能说明：合并付款是指当支付订单中包含多个商户的商品信息的时候，能一次进行合并付款，避免一单一付的情况。
  
• 报文传送格式：报文信息采用JSON格式进行http传输，将会提供实体与JSON的相互转换方法。
  
• 请求报文：
  

合并订单报文：

合并订单包含一个或多个子订单，一个子订单包含一个或多个商品。
子订单报文：

商品报文：

应答报文：

8. 4 退款交易

• 合并退款交易是指付款人在付款后因为某些原因想退回已付款项而触发的操作，银联交易完成后，需要向银联商务发送合并退款报文。
  
• 报文传送格式：报文信息采用JSON格式进行http传输，将会提供实体与JSON的相互转换方法。
  
• 请求报文
  

合并订单报文：合并订单包含一个或多个子订单，一个子订单包含一个或多个商品。

子订单报文：

商品报文：

应答报文：

8. 5 当日确认收货及需要划付
当日2B2B平台收到的确认收货或已经超过确认收货时间节点的待划付订单。银商根据收到的报文数据，按子订单中的商户编号，对此商户做资金划付; 报文传送格式：报文信息采用txt文件形式上传至FTP，文件中数据结构是一行一个大订单具体信息(包含小订单)。此外请求报文：该报文包含多个合并订单实体。     合并订单报文：合并订单包含一个或多个子订单，一个子订单包含一个或多个商品。

子订单报文：

商品报文：

关于数据设计有需要的朋友，可以留言私信，我在分享给大家，有一点需要特别强调!因为每个平台可能都有自己特定的业务，所以上述只是希望给大家点设计思路。希望大家能了解下支付业务设计到底是怎么回事。