本文介紹支付產品模塊的設計。

支付產品模塊是按照支付場景來為業務方提供支付服務。這個模塊一般位于支付網關之后，支付渠道之前。 它根據支付能力將不同的支付渠道封裝成統一的接口，通過支付網關來對外提供服務。所以，從微服務的角度，支付產品本身也是一個代理模式的微服務，它透過支付網關響應業務方請求， 進行一些統一處理后，分發到不同的支付渠道去執行，最后將執行結果做處理后，通過支付網關再回傳給業務方。

支付產品在支付系統參考架構圖中的位置如下圖所示：

產品分類

在不同的公司由于接入渠道和應用的差異，對支付產品分類略有不同。綜合支付場景和流程，支付產品可以分為如下幾類：

支付產品是由支付系統對支付渠道進行封裝而對業務方提供的支付能力。整體上來說，可以提供如下支付產品：

1. 快捷支付

用戶在完成綁卡之后，在支付的時候，不需要再輸入卡或者身份信息，僅需要輸入支付密碼就可以完成支付。對于小額度的支付，甚至可以開通小額免密，直接完成支付。 這種支付方式不會打斷用戶的體驗，是目前主要的在線支付方式。一般快捷支付產品是通過封裝銀行或者第三方支付平臺提供的快捷支付接口或者代付接口來實現的。

2. 網銀支付

用戶在支付的時候，需要跳轉到銀行網銀頁面來完成支付。在網銀頁面，需要輸入用戶的卡號和身份信息。這種支付方式會中斷用戶當前的體驗，一般僅用于PC Web上的支付。 網銀支付是封裝銀行提供的網銀支付來實現。

3. 協議支付

協議支付也稱代收或者代扣，代收指渠道授權商戶可以從用戶的銀行賬戶中扣款，一般用于定期扣款，不用于日常消費。比如水電煤氣、有線電視費。協議支付是通過封裝銀行、第三方支付提供的代扣或者快捷接口來實現。

4. 平臺支付

使用微信、支付寶等第三方支付平臺來完成支付。使用時，一般需要用戶預先安裝支付平臺系統（手機上），注冊并登錄到第三方支付平臺，并且已經在該平臺上完成綁卡等操作。 由于微信、支付寶已經被大量使用，用戶也產生對這些平臺的信任，平臺支付往往是電商公司的主要支付方式。

5. 外卡支付

對于由海外支付的需求，還需要提供外卡支付支持。 國內不少支付渠道都能支持外卡支付，如支付寶全球購等。直接對接Paypal，也是目前用的最多的外卡支付渠道。 關于外卡支付，以后會有專文介紹。

6. 話費支付

對于有包月小額類型的支付，手機話費也是一個不錯的選擇。目前也有一些平臺可以支持話費支付，比如虹軟、聯動優勢等。

7. 虛幣支付

不少公司會有自己的虛擬幣，比如京豆、Q幣等。這些虛幣也可以作為一種支付方式。

8. 賬戶支付

也成為余額支付、零錢支付等。 指為用戶建立本地賬戶， 支持充值，之后可以使用這個賬戶來完成支付。

9. 信用支付

如京東的白條，螞蟻花唄等，指使用信用賬戶進行透支，類似信用卡支付。

10. 代付

和代扣相反，代付是平臺將錢打給用戶。

每一種支付方式的詳細功能將在后續的各個章節中介紹。 這里先簡要介紹支付產品模塊的通用功能。

模塊功能

支出產品根據其支付能力，對外提供不同的功能。整體上來說，一般支付產品需要提供如下接口：1. 簽約和解約

在快捷支付、代扣等產品中，用戶在使用前，需要先完成簽約。簽約可以在渠道側進行，一般第三方支付采用這種方式，當電商需要接入時，讓第三方給授權。 銀行和銀聯的簽約一般是在電商側進行， 電商側負責收集用戶的信息，調用銀行和銀聯的接口進行簽約。簽約后，后續的支付行為就使用簽約號來進行，無需再輸入個人信息。 和簽約相對應，解約則是取消簽約關系。

2. 支付

支付是少不了的操作。 不同產品中支付行為不一樣?？旖葜Ц妒窃陔娚谭掌魃习l起，請求渠道進行支付；網銀支付則是跳轉到銀行支付網關上進行; 而賬戶支付、虛幣支付，則是在本地進行的。

3. 撤銷和退款

有些渠道區分撤銷和退款，比如銀聯、農行等，撤銷指取消當天在渠道側未結算的交易； 而退款僅針對已經結算的交易。有些渠道則不作區分。

4. 查詢簽約狀態

對于需要簽約的交易，可以通過這個接口來查詢簽約狀態。

5. 查詢訂單狀態

通過這個接口來查詢支付清單狀態以及退款的訂單狀態。

6. 預授權

預授權交易用于受理方向持卡人的發卡方確認交易許可。受理方將預估的消費金額作為預授權金額，發送給持卡人的發卡方。

7. 預授權撤銷

對已成功的預授權交易，在結算前使用預授權撤銷交易，通知發卡方取消付款承諾。預授權撤銷交易必須是對原始預授權交易或追加預授權交易最終承兌金額的全額撤銷。

8. 預授權完成交易

對已批準的預授權交易，用預授權完成做支付結算。

9. 預授權完成撤銷

預授權完成撤銷交易必須是對原始預授權完成交易的全額撤銷。預授權完成撤銷后的預授權仍然有效。

10. 對賬

通過FTP或者HTTP方式提供對賬文件供商戶側對賬。

11. 余額查詢

查詢商戶的交易賬戶的余額，避免由于余額不足導致交易失敗。 注意，不是客戶的余額。 當然，不是所有的銀行或者第三方支付都提供這個接口。

業務流程

上述操作，除了對賬、查單外，每個操作實現的主流程，一般會包括參數校驗，支付路由，生成訂單，風險評估，調用渠道服務，更新訂單和發送消息這7步，對于一些比較復雜的服務，還會涉及到異步同通知處理的步驟。

1. 執行參數校驗

所有的支付操作，都需要對輸入執行參數校驗，避免接口受到攻擊。

• 驗證輸入參數中各字段的有效性驗證，比如用戶ID,商戶ID,價格，返回地址等參數。
• 驗證賬戶狀態。交易主體、交易對手等賬戶的狀態是處于可交易的狀態。
• 驗證訂單：如果涉及到預單，還需要驗證訂單號的有效性，訂單狀態是未支付。為了避免用戶緩存某個URL地址，還需要校驗下單時間和支付時間是否超過預定的間隔。
• 驗證簽名。簽名也是為了防止支付接口被偽造。 一般簽名是使用分發給商戶的key來對輸入參數拼接成的字符串做MD5 Hash或者RSA加密，然后作為一個參數隨其他參數一起提交到服務器端。如支付網關設計所介紹，簽名驗證也可以在網關中統一完成。

2. 根據支付路由尋找合適的支付服務

根據用戶選擇的支付方式確定用來完成該操作的合適的支付渠道。用戶指定的支付方式不一定是最終的執行支付的渠道。比如用戶選擇通過工行信用卡來執行支付，但是我們沒有實現和工行的對接，而是可以通過第三方支付，比如支付寶、微信支付、易寶支付，或者銀聯來完成。那如何選擇合適的支付渠道，就通過支付路由來實現。支付路由會綜合考慮收費、渠道的可用性等因素來選擇最優方案。

3. 評估交易風險

檢查本次交易是否有風險。風控接口返回三種結果：阻斷交易、增強驗證和放行交易。

1. 阻斷交易，說明該交易是高風險的，需要終止，不執行第5個步驟；
2. 增強驗證，說明該交易有一定的風險，需要確認下是不是用戶本人在操作。這可以通過發送短信驗證碼或者其他可以驗證用戶身份的方式來做校驗，驗證通過后，可以繼續執行該交易。
3. 放行交易，即本次交易是安全的，可以繼續往下走。

4. 生成交易訂單

將訂單信息持久化到數據庫中。當訪問壓力大的時候，數據庫寫入會成為一個瓶頸。

5. 調用支付渠道提供的服務

所有的支付服務都需要第三方通道來完成執行。一般銀行渠道的調用比較簡單，可以直接返回結果。一些第三方支付，支付寶，微信支付等，會通過異步接口來告知支付結果。

6. 更新訂單

對于同步返回的結果，需要在主線程中更新訂單的狀態，標記是支付成功還是失敗。對于異步返回的渠道，需要在異步程序中處理。

7. 發送消息

通過消息來通知相關系統關于訂單的變更。風控，信用BI等，都需要依賴這數據做準實時計算。

8. 異步通知

如上述流程，其中涉及到調用遠程接口，其延遲不可控。如果調用方一直阻塞等待，很容易超時。引入異步通知機制，可以讓調用方在主線程中盡快返回，通過異步線程來得到支付結果。對于通過異步來獲取支付結果的渠道接口，也需要對應的在異步通知中將結果返回給調用方。 異步通知需要調用方提供一個回調地址，一般以http或者https的方式。這就有技術風險，如果調用失敗，還需要重試。而重試不能過于頻繁，需要逐步拉大每一次重試的時間間隔。 在異步處理程序中，訂單根據處理結果變更狀態后，也要發消息通知相關系統。

以上是關于支付產品設計的主流程。 后續分享將詳細介紹每個支付產品的設計。

#專欄作家#

鳳凰牌老熊，微信公眾號：鳳凰牌老熊，人人都是產品經理專欄作家，10多年企業應用和互聯網軟件架構設計經驗，關注互聯網金融和大數據領域。

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