本文主要以2B2B平台为例，讲解和梳理支付绑定、支付解绑、在线支付、退款等业务流程和设计方法。

背景

在线支付是所有电商平台的核心业务，我在人人都是产品经理的网站上搜索了支付这个关键词，发现关于支付的设计非常少，不光是支付，还有商品、产品、购物车等字段模型的设计，大家都注重产品的外在设计，告诉你是怎么回事，却不告诉你这个设计应该如何实现。我个人认为一个合格的产品经理是会需求分析、会业务设计、会数据设计和分析的人。

本文主要以2B2B平台为例，讲解和梳理了支付绑定、支付解绑、在线支付、退款等业务流程和设计方法，如果大家觉得有帮助或者觉得哪里不对，希望大家留言交流或者点赞。

设计策略

产品经理在设计支付服务时，不仅要分析业务流程，还要考虑设计策略，支付服务的设计策略主要体现在数据安全性和可扩展性上。

1. 数据安全

支付过程中采用银联签名机制及加密机制，保证支付的安全。

消息签名与签名验证机制的共同点在于：首先需要将消息中签名字段（）之外的所有数据元素按照key=的形式按照名称进行排序，然后以&为连接符拼接成待签名的字符串；其次使用SHA-1算法对签名字符串进行汇总。

消息签名机制与签名验证机制的区别如下：

加密机制：对于持卡人密码，银联网上支付平台使用RSA公钥证书将PIN以ANSI X9.8格式与主账号加密后传输，保证密码安全。根据商户可选配置，CVN2、有效期、卡号等采用RSA公钥证书加密处理。对于银行卡验证信息、身份信息等敏感信息，采用编码后传输，进行数据屏蔽。对于文件内容，采用压缩算法压缩后以编码方式传输，压缩编码后的内容参与签名摘要操作。

2.程序可扩展性

经过支付业务分析设计，其相关的数据库表包括支付记录表、支付记录表、支付银行表、支付绑定表、支付异常表、支付订单表；以后类似的线上银联支付业务可以直接复用，无需新建表。另外，下面的业务流程设计也可以进行扩展使用。

支付业务流程设计

首先介绍整个业务的整体业务流程和资金流业务流程，然后分别介绍支付绑定、解绑、支付、退款等业务流程的设计。

1.支付业务总体流程图

2.支付业务资金流转时序图

3.银行卡绑定业务时序图

绑定业务：一、建立绑定关系

建立绑定关系就是将商户/收单机构的用户编号（即消息中的绑定标识号）与用户的银联卡信息进行关联，关联信息留存于银联系统中。建立绑定关系可分为前台模式和后台模式。前台模式下，用户在银联页面输入相关银行卡信息；后台模式下，商户采集银行卡信息并发送给银联进行绑定。下面以前台模式为例，业务流程图如下：

流程描述：

经销商（销售）确认收货后，次日即可收到相应货款，若订单有开具发票，货款将支付至对公账户，若无开具发票，货款将支付至私人账户。

4.银行卡解绑业务流程图

银行卡解绑服务其实和银行卡绑定服务是相反的，业务流程非常相似。

5.银行卡网上支付业务流程图

一般交易平台支付的触发场景有四种：购物车支付、直接购买支付、快捷购买支付、订单列表支付。

支付操作触发后，根据是否开具发票决定调用什么类型的支付接口。若开具发票且为增值税发票，则调用B2B支付接口（前台交易）。若不开具发票或开具普通发票，则调用绑定支付接口。支付前必须绑定银行卡，若为借记卡，则调用借记卡绑定接口，再调用绑定收款接口。若为信用卡，则调用信用卡绑定接口，再调用绑定消费接口。

从技术实现的角度来说，交易大致可以分为前端交易和后端交易。

前端交易是指交易请求方（如商户、收单机构）与银联网上支付系统之间通过用户浏览器传输交易信息的交易。属于异步交易类型，需要持卡人参与。对于涉及金额的前端交易（即交易请求中有金额字段），银联网上支付系统会在后台通知请求方（后台通知消息的要素与前端响应相同），请求方也必须收到后台通知。对于交易状态未知的交易，请求方必须发起交易状态查询交易。

后台交易是指交易请求方（如商户或收单机构）通过请求方服务器直接向银联网上支付系统服务器发送交易信息的交易。后台交易均为同步短连接交易，不需要持卡人参与完成交易。对于涉及金额的后台交易，如果通讯超时，交易请求方必须发起交易状态查询交易。

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

该银行网上退款业务根据业务需求设计了如下业务规则：

已发货订单和已完成订单均不支持线上退款，仅支持线下退款

7. 整体界面设计

8.支付开发与设计

8.1 前台交易开发步骤

8.2 后端交易接口开发步骤

8.3 合并支付交易接口

功能说明：组合支付是指当支付订单包含多个商户的产品信息时，可以一次性组合支付，避免每次只支付一个订单的情况。 消息传输格式：消息信息采用JSON格式进行http传输，会提供与JSON相互转换的方法。 请求消息：

合并订单信息：

一个组合订单包含一个或多个子订单，一个子订单包含一个或多个商品。

子订单留言：

商品讯息：

响应消息：

8.4 退款交易

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

子订单留言：

商品讯息：

响应消息：

8.5当天确认收货及付款

2B2B平台收到当天已经超过确认到账时间节点的已确认到账或待支付订单，银行商户根据收到的报文数据，按照子订单中的商户号对商户进行资金划转； 报文传输格式：报文信息以txt文件形式上传到FTP，文件中数据结构为一行大订单（包含小订单）的具体信息。 另外，请求报文：该报文中包含多个合并订单实体。 合并订单报文：一个合并订单中包含一个或多个子订单，一个子订单中包含一个或多个商品。

子订单留言：

商品讯息：

如果需要数据设计可以留言，我会分享给大家。有一点需要强调！因为每个平台可能都有自己具体的业务，以上只是给大家一些设计思路，希望大家能够明白支付业务设计到底是怎么回事。