中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

本文主要以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合并付款交易接口

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

合并訂單報文：

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

子訂單報文：

商品報文：

應答報文：

8.4退款交易

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

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

子訂單報文：

商品報文：

應答報文：

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

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

子訂單報文：

商品報文：

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

本文由 @洲伯通 原創發布于人人都是產品經理。未經許可，禁止轉載。