本文主要以2B2B平臺為例對嘗試著對支付綁定、支付解綁、在線支付、退款等業(yè)務流程及設計方式進行說明、梳理。

背景

在線支付業(yè)務是所有電商平臺的核心業(yè)務，我在人人都是產(chǎn)品經(jīng)理的網(wǎng)站上使用關(guān)鍵字“支付”檢索了下，發(fā)現(xiàn)關(guān)于支付業(yè)務的設計少之又少，不光是支付，關(guān)于商品、產(chǎn)品、購物車等等領域模型的設計也很少，大家都集中討論在產(chǎn)品外在設計上，告訴你這個事情是怎么回事，但是沒有告訴設計應該如何落地，個人認為一個合格的產(chǎn)品經(jīng)理是一個既能進行需求分析、業(yè)務設計、同時也能做數(shù)據(jù)設計、分析的。

本文主要以2B2B平臺為例對嘗試著對支付綁定、支付解綁、在線支付、退款等業(yè)務流程及設計方式進行說明、梳理。如果您覺得有些幫助或者覺得哪里不對，希望小伙伴留言進行交流或者點個贊。

設計策略

在做支付業(yè)務設計的時候，產(chǎn)品經(jīng)理不光要分析業(yè)務流程還要考慮設計策略，關(guān)于支付業(yè)務的設計策略主要體現(xiàn)在數(shù)據(jù)安全性和擴展性。

1、數(shù)據(jù)安全性

采用銀聯(lián)簽名機制、加密機制確保支付過程中支付的安全性。

報文簽名與驗簽機制的共同點：首先都需要對報文中出現(xiàn)簽名域（signature）之外的所有數(shù)據(jù)元采用key=value的形式按照名稱排序，然后以&作為連接符拼接成待簽名串。其次，對待簽名串使用SHA-1算法做摘要。

報文簽名機制與驗簽機制不同點：

• 報文的簽名處理機制如下：使用銀聯(lián)頒發(fā)給商戶的商戶RSA私鑰證書對摘要做簽名。最后，對簽名做Base64編碼，將編碼后的簽名串放在簽名（signature）表單域里和其他表單域一起通過HTTP Post的方式傳輸給銀聯(lián)在線支付平臺。
• 報文的驗簽處理機制如下：使用商戶入網(wǎng)時銀聯(lián)提供的銀聯(lián)在線支付通訊RSA公鑰證書對摘要做簽名。最后，對簽名做Base64編碼，與返回報文表單中的簽名（signature）域簽名串做比較，如一致則驗簽成功，否則驗簽失敗。

加密機制：對于持卡人密碼銀聯(lián)在線支付平臺使用RSA公鑰證書對ANSI X9.8帶主帳號格式的PIN加密并做Base64編碼后傳輸，以保障密碼的安全性。依據(jù)商戶可選配置，對于CVN2、有效期、卡號使用RSA公鑰證書分別做加密并Base64處理。對于敏感信息銀行卡驗證信息及身份信息部分內(nèi)容，采用Base64編碼后傳輸，以做數(shù)據(jù)屏蔽。對于文件內(nèi)容，使用DEFLATE壓縮算法壓縮后，Base64編碼的方式傳輸，壓縮編碼后的內(nèi)容參與簽名摘要運算。

2、程序擴展性

在支付業(yè)務分析設計后，其相關(guān)數(shù)據(jù)庫表包括支付記錄表 支付記錄表支付銀行表 支付綁定表 支付異常表、支付訂單表；以后再有類似的在線銀聯(lián)支付業(yè)務可以直接進行復用，不用新建表。此外以下業(yè)務流程設計也可以進行擴展使用。

支付業(yè)務流程設計

首先介紹整個業(yè)務的整體業(yè)務流程、資金流業(yè)務流程。其次分別介紹支付綁定、解綁、支付、退款等業(yè)務流程的設計。

1、支付業(yè)務整體流程圖

2、支付業(yè)務資金流順序圖

3、銀行卡綁定業(yè)務順序圖

綁定業(yè)務：首先要建立綁定關(guān)系

建立綁定關(guān)系，指商戶/收單機構(gòu)的用戶號（即報文中的綁定標識號）與用戶的銀聯(lián)卡信息進行關(guān)聯(lián)，關(guān)聯(lián)信息留存在銀聯(lián)系統(tǒng)中。建立綁定關(guān)系可分為前臺模式和后臺模式，前臺模式時，用戶在銀聯(lián)頁面輸入相關(guān)銀行卡信息；后臺模式由商戶采集銀行卡信息發(fā)送至銀聯(lián)進行綁定。下面以前臺模式為例進行說明，業(yè)務流程圖如下所示：

流程說明：

• 如果采購方?jīng)]有綁定過銀行卡，會提示“請先綁定銀行開再支付”；如果綁定過銀行卡，會跳轉(zhuǎn)至支付頁面；
• 在綁定銀行卡頁面，如果第一次綁定銀行卡，綁定信息中會進行“交易平臺支付密碼”新增操作，否則無此操作，一個采購方只能有一個“交易平臺支付密碼”，可在會員中心修改此支付密碼；
• 在銀聯(lián)綁定卡頁面，可選擇儲蓄卡和信用卡，點擊“綁定”，跳轉(zhuǎn)至銀聯(lián)綁定頁面，輸入卡號等綁定信息，綁定成功后會跳轉(zhuǎn)到平臺頁面，綁定成功的卡可進行解綁。
• 綁定卡以后，可進行支付，在支付頁面，選擇一張綁定銀行卡，輸入手機驗證碼和“交易平臺支付密碼”，支付點擊“支付”，支付成功會跳轉(zhuǎn)至支付成功頁面，訂單列表中可看到支付成功后訂單信息。
• 在已付款訂單列表頁，可對當天清算前訂單進行退款，點擊“退款”，會返回退款結(jié)果；如果訂單支付成功，配送商（銷售）可進行接單；采購方在配送商（銷售）接單后可進行“確認收貨”操作；

確認收貨后，在第二天配送商（銷售）可收到相應款項，如果訂單開具發(fā)票，則款項打至對公賬號，如果不開具發(fā)票，則款項打至對私賬號

4、銀行卡解綁業(yè)務流程圖

銀行卡解綁業(yè)務實際上是與銀行卡綁定業(yè)務相對的業(yè)務，其業(yè)務流程非常相似。

5、銀行卡在線支付業(yè)務流程圖

一般交易平臺支付有四個觸發(fā)場景：購物車支付、直接購買支付、快速購買支付、訂單列表支付。

觸發(fā)支付操作后，根據(jù)是否開具發(fā)票來判斷調(diào)用哪種類型的支付接口，如果開具發(fā)票且是增值稅發(fā)票，調(diào)用B2B支付接口（前臺交易），如果未開具發(fā)票或開具普通發(fā)票，調(diào)用綁定支付接口，支付之前必須先綁定銀行卡，如果是借記卡，調(diào)用借記卡綁定接口，之后調(diào)用綁定代收接口，如果是貸記卡，則調(diào)用貸記卡綁定接口，之后調(diào)用綁定消費接口。

從技術(shù)實現(xiàn)方式上交易大致可劃分為前臺類交易、后臺類交易

前臺類交易是指交易請求方（如商戶、收單機構(gòu)）與銀聯(lián)在線支付系統(tǒng)之間的交易信息通過用戶瀏覽器進行傳遞的交易，是一種異步的、需要持卡人參與完成的交易類型。對于涉及金額的前臺類交易（即交易請求中有金額字段）銀聯(lián)在線支付系統(tǒng)系統(tǒng)均會給請求方后臺通知(后臺通知報文要素同前臺應答的要素)，請求方也必須實現(xiàn)接收后臺通知。對于交易狀態(tài)未知的交易請求方必須發(fā)起交易狀態(tài)查詢交易。

后臺類交易是指交易請求方（如商戶、收單機構(gòu)）將交易信息直接通過請求方服務器發(fā)送至銀聯(lián)在線支付系統(tǒng)服務器的交易方式。后臺交易均為同步短連接方式，不需要持卡人參與完成的交易類型。對于涉及金額的后臺類交易，若通訊超時，則交易請求方必須發(fā)起交易狀態(tài)查詢交易。

6、銀行卡退款業(yè)務流程圖

銀行在線退款業(yè)務根據(jù)業(yè)務需求設計如下業(yè)務規(guī)則：

• 整單整退（子訂單不能單獨退款，只能大訂單進行退款）
• 當天晚上11點前的訂單，在11點后不可以進行線上退款。其他情況請撥打400-0116-666人工處理退款）

已發(fā)貨訂單和交易完成訂單不能線上退款，只能線下退款

7、整體接口設計

8、支付開發(fā)設計

8.1前臺交易開發(fā)步驟

• 以表單的方式組裝要發(fā)送給銀聯(lián)在線支付的數(shù)據(jù)對象（包括訂單號、商戶號、交易類型、交易金額、交易時間等各域）。每個域填寫方法可參考文檔《中國銀聯(lián)在線支付平臺-商戶接入接口規(guī)范》。
• 將組裝好的數(shù)據(jù)排序好并用&連接后簽名，生成signature字段，可使用插件包提供的方法“sign(未簽名報文, 報文字符集);”?？赏ㄟ^調(diào)用插件包提供的簽名方法來完成簽名。
• 把所有要發(fā)送給銀聯(lián)在線支付的域包括signature和signMethod，組成表單以POST方式送給銀聯(lián)在線支付前臺交易的地址。
• 交易完成后，銀聯(lián)在線支付系統(tǒng)將把交易結(jié)果分別返回通知到商戶通的前臺應答地址和后臺應答地址上，商戶接收到交易通知后可分別調(diào)用“coverResultString2Map(應答報文);”方法進行應答報文解析，和“MpiUtil.validate(應答報文, 報文字符集)”方法進行簽名驗證。

8.2后臺類交易接口開發(fā)步驟

• 商戶按照不同的交易組裝報文，交易報文請參考《中國銀聯(lián)在線支付平臺-商戶接入接口規(guī)范》把組裝好的數(shù)據(jù)排序好并用&連接后簽名，生成signature字段，可使用插件包提供的方法“sign(未簽名報文, 報文字符集);”。
• 把所有數(shù)據(jù)，包括signature和signMethod用key=value并用&符號鏈接的方式組裝成字符串，通過插件包提供的方法進行發(fā)送。接收到返回報文后，通過插件包提供的方法進行驗證簽名，調(diào)用“coverResultString2Map(應答報文);”方法進行應答報文解析，和“MpiUtil.validate(應答報文, 報文字符集)”方法進行簽名驗證。

8.3合并付款交易接口

1. 功能說明:合并付款是指當支付訂單中包含多個商戶的商品信息的時候，能一次進行合并付款，避免一單一付的情況。
2. 報文傳送格式:報文信息采用JSON格式進行http傳輸，將會提供實體與JSON的相互轉(zhuǎn)換方法。
3. 請求報文:

合并訂單報文：

合并訂單包含一個或多個子訂單，一個子訂單包含一個或多個商品。

子訂單報文：

商品報文：

應答報文：

8.4退款交易

• 合并退款交易是指付款人在付款后因為某些原因想退回已付款項而觸發(fā)的操作，銀聯(lián)交易完成后，需要向銀聯(lián)商務發(fā)送合并退款報文。
• 報文傳送格式：報文信息采用JSON格式進行http傳輸，將會提供實體與JSON的相互轉(zhuǎn)換方法。
• 請求報文

合并訂單報文：合并訂單包含一個或多個子訂單，一個子訂單包含一個或多個商品。

子訂單報文：

商品報文：

應答報文：

8.5當日確認收貨及需要劃付

當日2B2B平臺收到的確認收貨或已經(jīng)超過確認收貨時間節(jié)點的待劃付訂單。銀商根據(jù)收到的報文數(shù)據(jù)，按子訂單中的商戶編號，對此商戶做資金劃付； 報文傳送格式：報文信息采用txt文件形式上傳至FTP，文件中數(shù)據(jù)結(jié)構(gòu)是一行一個大訂單具體信息(包含小訂單)。此外請求報文：該報文包含多個合并訂單實體。 ??? 合并訂單報文：合并訂單包含一個或多個子訂單，一個子訂單包含一個或多個商品。

子訂單報文：

商品報文：

關(guān)于數(shù)據(jù)設計有需要的朋友，可以留言私信，我在分享給大家，有一點需要特別強調(diào)！因為每個平臺可能都有自己特定的業(yè)務，所以上述只是希望給大家點設計思路。希望大家能了解下支付業(yè)務設計到底是怎么回事。

本文由 @洲伯通 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。