收單網(wǎng)關(guān)的設(shè)計要素包含：業(yè)務(wù)方、用戶、業(yè)務(wù)系統(tǒng)、支付系統(tǒng)。

收單網(wǎng)關(guān)

收單網(wǎng)關(guān)是平臺方支付系統(tǒng)和用戶/商戶的PC、移動APP所使用的外部網(wǎng)絡(luò)之間的接口，為支付系統(tǒng)操作將外網(wǎng)傳輸?shù)臄?shù)據(jù)轉(zhuǎn)換為系統(tǒng)內(nèi)部數(shù)據(jù)，同時負(fù)責(zé)將平臺業(yè)務(wù)系統(tǒng)的內(nèi)部請求轉(zhuǎn)化為支付系統(tǒng)的內(nèi)部數(shù)據(jù)。

收單網(wǎng)關(guān)的職責(zé)為支付平臺化后，系統(tǒng)內(nèi)部接口不可對外，因此所有外部系統(tǒng)需要通過統(tǒng)一的網(wǎng)關(guān)接口調(diào)用支付平臺；由網(wǎng)關(guān)進行一系列格式校驗、參數(shù)校驗、業(yè)務(wù)調(diào)用權(quán)限檢查后再向支付進行轉(zhuǎn)發(fā)。

收單網(wǎng)關(guān)設(shè)計要素包含：

業(yè)務(wù)方：指業(yè)務(wù)平臺?？筛鶕?jù)公司業(yè)務(wù)規(guī)模大小、業(yè)務(wù)領(lǐng)域或公司主體等維度，對對接的業(yè)務(wù)方進行區(qū)分，接入后這些業(yè)務(wù)方即成為支付平臺的收單商戶，使用平臺支付產(chǎn)品實現(xiàn)其收付費功能需求；

用戶：業(yè)務(wù)平臺 C 端用戶，可根據(jù)業(yè)務(wù)方進行劃分；

業(yè)務(wù)系統(tǒng)：業(yè)務(wù)端的業(yè)務(wù)系統(tǒng)；

支付系統(tǒng)：支付清結(jié)算平臺。

收單網(wǎng)關(guān)流程

• 構(gòu)造請求信息：業(yè)務(wù)系統(tǒng)根據(jù)支付系統(tǒng)提供的接口規(guī)則構(gòu)造請求信息，例如支付下單、取消訂單、退款等等；
• 發(fā)送請求信息：把構(gòu)造好的信息發(fā)送到指定的地址；
• 處理請求信息：支付系統(tǒng)會得到請求的數(shù)據(jù)信息，按照預(yù)定的驗簽，業(yè)務(wù)參數(shù)校驗等一系列驗證通過后，將請求的數(shù)據(jù)信息對業(yè)務(wù)（對應(yīng)支付、取消、充值等等）進行處理；
• 返回響應(yīng)信息：支付系統(tǒng)會以同步和異步兩種處理方式，返回業(yè)務(wù)數(shù)據(jù)處理結(jié)果；一般情況下，同步通知僅代表請求處理成功，業(yè)務(wù)訂單處理狀態(tài)會以異步通知的形式主動回調(diào)用戶在下單的時候設(shè)置的異步回調(diào)地址，通知業(yè)務(wù)方時若得不到業(yè)務(wù)方的響應(yīng)信息值「success」，支付系統(tǒng)會重復(fù)若干次（按照一定的頻次配置），以防止掉單現(xiàn)象；若業(yè)務(wù)方戶不設(shè)置，則不會通知；

業(yè)務(wù)系統(tǒng)收到異步通知后，結(jié)合自身的業(yè)務(wù)規(guī)則改變支付單狀態(tài)，進行如訂單狀態(tài)更新等業(yè)務(wù)處理。

接口定義

• 業(yè)務(wù)系統(tǒng)和支付系統(tǒng)之間通過 https 協(xié)議來進行通信，接口以 URL 的形式提供并以 post 的請求方式進行處理；
• 文檔的接口包括兩種：服務(wù)接口和通知接口；
• 服務(wù)接口由支付系統(tǒng)提供，供業(yè)務(wù)方調(diào)用；
• 通知接口由業(yè)務(wù)方提供，供支付系統(tǒng)調(diào)用；
• 雖然通知接口由業(yè)務(wù)方提供，但是仍由支付系統(tǒng)制定接口規(guī)范；
• 服務(wù)接口包括接口說明中的所有接口信息，通知接口目前僅包括交易狀態(tài)和退款狀態(tài)的通知等。

接口設(shè)計說明

• 基本請求接口：所有請求接口都要加上基本請求參數(shù)，例如接口名稱、版本、App ID、簽名、簽名方式、同步跳轉(zhuǎn)地址等關(guān)鍵信息，當(dāng)發(fā)起調(diào)用時，所有業(yè)務(wù)接口都會加上該接口參數(shù)，可參考支付寶和微信等第三方支付公司的接口參數(shù)定義。
• 服務(wù)請求接口：根據(jù)支付系統(tǒng)本身的能力抽象出的業(yè)務(wù)接口，給到外部業(yè)務(wù)方進行調(diào)用。
• 即時到賬交易網(wǎng)關(guān)接口：買家在業(yè)務(wù)系統(tǒng)中選擇購買商品下單，付款成功后金額直接入賣家賬戶。
• 擔(dān)保交易網(wǎng)關(guān)接口：買家在業(yè)務(wù)系統(tǒng)中選擇購買商品下單，有部分金額為擔(dān)保金額，買家付款成功后，擔(dān)保部分進入平臺方賬戶，未擔(dān)保金額直接入賣家賬戶。
• 結(jié)算（分賬）網(wǎng)關(guān)接口：買家使用擔(dān)保交易下單付款完成，在收到貨物后，將擔(dān)保金額結(jié)算給賣家。
• 繼續(xù)支付網(wǎng)關(guān)接口：買家在支付頁面未成功支付，需要在業(yè)務(wù)系統(tǒng)中繼續(xù)支付時，調(diào)用該接口。
• 退款網(wǎng)關(guān)接口：買賣雙方在達成退款協(xié)議后，可針對及時到賬交易，訂金下定等已支付交易 由業(yè)務(wù)系統(tǒng)發(fā)起退款請求。
• 交易查詢網(wǎng)關(guān)接口：因為某一方原因， 可能導(dǎo)致業(yè)務(wù)方在預(yù)期時間內(nèi)都收不到最終支付通知， 此時業(yè)務(wù)方可以通過該接口來查詢訂單的詳細(xì)支付狀態(tài)。
• 通知接口：根據(jù)業(yè)務(wù)方提供的通知地址，將支付結(jié)果等信息返回給業(yè)務(wù)方

①交易狀態(tài)變更通知：通知業(yè)務(wù)方時，接口信息里面會傳遞業(yè)務(wù)訂單號、交易訂單號、狀態(tài)、金額、時間等相關(guān)信息，以便業(yè)務(wù)方能更好的做業(yè)務(wù)處理；

a.交易狀態(tài)：交易訂單的狀態(tài)；

1. 等待買家付款
2. 付款成功
3. 交易成功
4. 交易結(jié)束
5. 交易關(guān)閉

②退款狀態(tài)變更通知：通知業(yè)務(wù)方時，接口信息里面會傳遞原始業(yè)務(wù)訂單號、退款業(yè)務(wù)訂單號、退款交易訂單號、狀態(tài)、金額、時間等相關(guān)信息，以便業(yè)務(wù)方能更好的做業(yè)務(wù)處理；

a.退款狀態(tài)：退款訂單的狀態(tài)；

1. 退款成功
2. 退款失敗

交易服務(wù)

交易服務(wù)的作用

• 將支付系統(tǒng)的支付能力抽象出來，提供各類交易方式，例如下單、支付、修改金額、確認(rèn)結(jié)算、退款、關(guān)閉交易、查詢等標(biāo)準(zhǔn)接口，對外輸出收單網(wǎng)關(guān)；
• 基于收付款方的交易鏈業(yè)務(wù)路抽象交易類型、交易產(chǎn)品以滿足不同業(yè)務(wù)方各類交易場景的需求；
• 鑒權(quán)校驗、交易結(jié)果通知；
• 對接業(yè)務(wù)方。

擔(dān)保收單交易

①擔(dān)保交易：用戶在業(yè)務(wù)平臺中選擇某商家的商品進行購買，支付完成后該筆訂單資金進入平臺的擔(dān)保賬戶，等到用戶確認(rèn)收貨后，將該筆訂單的資金結(jié)算給對應(yīng)商家賬戶；此交易類型也可以適用于一些具備結(jié)算周期等時間屬性的業(yè)務(wù)當(dāng)中，通過網(wǎng)關(guān)的擔(dān)保收單接口和結(jié)算接口做到由業(yè)務(wù)方靈活控制結(jié)算賬期。
②流程

③擔(dān)保交易設(shè)計

定義擔(dān)保交易產(chǎn)品代碼，標(biāo)識此類交易訂單的類型。擔(dān)保交易分為下單支付和結(jié)算兩個環(huán)節(jié)：

• 第一個環(huán)節(jié)為下單環(huán)節(jié)，交易參與雙方當(dāng)中付款人是用戶，收款人則是平臺在支付系統(tǒng)內(nèi)部開設(shè)的一個擔(dān)保賬戶，擔(dān)保賬戶屬于內(nèi)部的一個結(jié)算過渡戶，代表著這錢是要給出去的，時候時候給出去基于業(yè)務(wù)方的指令來決定。
• 第二個環(huán)節(jié)在發(fā)起結(jié)算的時候，確認(rèn)之前這筆擔(dān)保交易訂單需要和商戶進行最終結(jié)算，此時基于業(yè)務(wù)方調(diào)用結(jié)算接口，交易參與雙方當(dāng)中新增兩條收付款人記錄，付款人為擔(dān)保賬戶，收款人為該筆訂單的商戶；最終資金以內(nèi)部戶轉(zhuǎn)賬的形式將擔(dān)保賬戶中該筆訂單資金，轉(zhuǎn)給實際收款的商戶賬戶。

即時到賬交易

即時到賬交易即用戶在平臺上選擇商品購買并支付，付款的資金立馬結(jié)算到商家的收款賬戶中。

例如，早期支付寶 PC 端的即時到賬產(chǎn)品，用戶通過 PC 網(wǎng)銀即時到賬產(chǎn)品付款后，單筆交易即時結(jié)算到了商戶的平臺賬戶中，由此可得：

• 若支付寶不墊資，則即時到賬底層包裝接口的銀行為 T+0 給到支付寶；
• 若支付寶墊資，則銀行資金未結(jié)算前，支付寶將備付金賬戶中的存量資金為商戶的平臺賬戶進行結(jié)算。

即時到賬交易與業(yè)務(wù)場景息息相關(guān)，在某些非擔(dān)保流程中，若用戶付款后需要立馬進行履約的情況，則適合即時到賬產(chǎn)品，例如各平臺的會員產(chǎn)品購買場景。

①流程

②即時到賬的設(shè)計要點：

• 定義擔(dān)保交易產(chǎn)品代碼，標(biāo)識此類交易訂單的類型；
• 和擔(dān)保收單的區(qū)別，在于即時到賬產(chǎn)品沒有單獨的結(jié)算環(huán)節(jié)；在下單的時候，接口參數(shù)里包含分潤參數(shù)，當(dāng)交易發(fā)起時就需要業(yè)務(wù)方算出該筆訂單分潤收款主題數(shù)、確定好用戶的 UID（給誰充值）、賬戶類型（給什么賬戶充值）、金額等參數(shù)；
• 分潤原則：先收錢再分錢且收到金額 ≥ 分潤總金額，即先入后出、收大于等于付。

充值交易

充值交易即用戶對賬戶余額進行充值，一般運用于充值虛擬幣、錢包余額等產(chǎn)品。用戶對賬戶余額進行充值，一般運用于充值虛擬幣、錢包等產(chǎn)品，首先需要對充值的兩種做法做一個區(qū)分。

• 業(yè)務(wù)平臺充值
• 支付平臺充值

例如，在用戶感知層面，早期的支付寶與淘寶不分你我，支付寶像是為淘寶定制的專屬錢包，但實際上用戶在支付寶充值的余額與淘寶業(yè)務(wù)并無關(guān)聯(lián)；而騰訊的虛擬貨幣 Q 幣則是由業(yè)務(wù)端發(fā)起的交易，因此與業(yè)務(wù)平臺具有強關(guān)聯(lián)性。因此基于支付平臺的兩種做法，一種是基于支付平臺的賬戶做充值，另一種是基于業(yè)務(wù)平臺做充值。

①流程

②充值交易的設(shè)計要點：

• 首先定義充值產(chǎn)品的產(chǎn)品代碼；
• 業(yè)務(wù)端充值（虛擬幣）：此類產(chǎn)品虛幣賬戶體系獨立于支付系統(tǒng)；

1. 充值和虛擬幣的消費業(yè)務(wù)端完全閉環(huán)，由支付系統(tǒng)內(nèi)部針對該充值業(yè)務(wù)開設(shè)一個統(tǒng)一的收款賬戶，結(jié)算時通過支付系統(tǒng)提供的入賬記資金分潤，適用于直播、視頻等純互聯(lián)網(wǎng)虛擬業(yè)務(wù)；
2. 接口定義：下單支付接口；
3. 優(yōu)勢：開發(fā)成本低，實現(xiàn)起來相對簡單、可快速實現(xiàn)業(yè)務(wù)；
4. 劣勢：賬務(wù)不清晰，流程不統(tǒng)一、有一定資金風(fēng)險。

• 支付系統(tǒng)充值：通過支付系統(tǒng)賬戶體系實現(xiàn)，所有充值資金通過錢包收銀臺或支付系統(tǒng)的充值網(wǎng)關(guān)接口實現(xiàn)；

1. 錢包收銀臺：充值行為發(fā)生在支付系統(tǒng)體系內(nèi)（參考前文中講到的支付寶邏輯）且獨立于業(yè)務(wù)平臺。原則上當(dāng)公司業(yè)務(wù)規(guī)模擴大，不同的 App 統(tǒng)一接入支付系統(tǒng)時，獨立的錢包賬戶余額應(yīng)可同時支持不同業(yè)務(wù)的賬戶支付需求。例如，美團賬戶余額充值的資金同時適用于美團外賣、點評等，此時美團的錢包已經(jīng)是擁有獨立賬戶體系的產(chǎn)品，接入各業(yè)務(wù)平臺僅需不同業(yè)務(wù)端識別用戶的唯一標(biāo)識即可；
2. 充值網(wǎng)關(guān)接口：針對于業(yè)務(wù)方發(fā)起的充值行為，各個業(yè)務(wù)平臺自己本身具備充值業(yè)務(wù)需要支付體系的賬戶能力提供支持。通過網(wǎng)關(guān)充值（入口在業(yè)務(wù)端）且可以滿足各個業(yè)務(wù)方不同賬戶類型的訴求，需要每個業(yè)務(wù)方在用戶發(fā)起充值時，充值至用戶在此業(yè)務(wù)下開設(shè)的對應(yīng)虛擬賬戶，例如 B 站的 B 幣、金瓜子等，就來源于不同的業(yè)務(wù)方開設(shè)的不同虛幣賬戶；
3. 接口定義：充值接口（賬戶類型、uid、金額、支付方式等）；
4. 優(yōu)勢：資金賬戶清晰、流程標(biāo)準(zhǔn)化、所有支付、賬戶由支付系統(tǒng)控制，資金安全有一定保證；
5. 劣勢：開發(fā)成本高，實現(xiàn)起來相對復(fù)雜。

出款交易

出款也稱之為提現(xiàn)。用戶基于自己賬戶余額發(fā)起提現(xiàn)，一般電商平臺涉及到的場景為 C端用戶的錢包賬戶余額提現(xiàn)和B端用戶收益賬戶的余額提現(xiàn)，是將資金從平臺的虛幣賬戶轉(zhuǎn)移用戶外部賬戶的過程。具體分類可分為出款到卡及出款到賬戶。
①流程

②出款交易的設(shè)計要點：
定義產(chǎn)品碼，可以拆分為出款到卡和出款到賬戶等不同的產(chǎn)品，針對 B 端商戶的提現(xiàn)交易記錄，原則上最好單獨用表單顯示；按照流程圖所示，提現(xiàn)時首選要做好余額校驗動作；

1. 出款到賬戶：目前常見的場景為用戶發(fā)起提現(xiàn)到支付寶或者微信賬戶，接入支付寶微信等第三方支付公司的付款產(chǎn)品即可滿足此需求，業(yè)務(wù)端需做好用戶端的第三方賬號信息采集，用戶發(fā)起提現(xiàn)的時將賬戶等相關(guān)信息上傳至第三方等待出款結(jié)果即可；根據(jù)業(yè)務(wù)模式，針對 B 端商戶提現(xiàn)時，優(yōu)先做實名認(rèn)證再發(fā)起提現(xiàn)，且發(fā)起提現(xiàn)的賬戶信息和實名認(rèn)證信息一致為佳，再根據(jù)業(yè)務(wù)端需求判斷是否有針對 C 端用戶做實名認(rèn)證處理的必要；
2. 出款到卡：和付款到賬戶的主流程沒有太大區(qū)別，但一般情況下需要商戶端采集用戶銀行卡信息，因此需要將支付系統(tǒng)中存儲銀行卡相關(guān)的數(shù)據(jù)（卡 Bin 信息、城市、省份等），并對業(yè)務(wù)? 端提供綁定、查詢等接口為佳，這樣用戶前端綁卡時無論是卡 Bin 接口驗證，還是前端做選擇輸入銀行都能擁有較好的體驗。*提現(xiàn)到銀行卡需要接入對應(yīng)的銀行卡出款渠道。

《支付系統(tǒng)設(shè)計白皮書》由 PingPlusPlus支付學(xué)院（ID：pingxxpi）出品。

本文由 @支付學(xué)院 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)允許，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于CC0協(xié)議。