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

收單網關的設計要素包含：業務方、用戶、業務系統、支付系統。

收單網關

收單網關是平臺方支付系統和用戶/商戶的PC、移動APP所使用的外部網絡之間的接口，為支付系統操作將外網傳輸的數據轉換為系統內部數據，同時負責將平臺業務系統的內部請求轉化為支付系統的內部數據。

收單網關的職責為支付平臺化后，系統內部接口不可對外，因此所有外部系統需要通過統一的網關接口調用支付平臺；由網關進行一系列格式校驗、參數校驗、業務調用權限檢查后再向支付進行轉發。

收單網關設計要素包含：

業務方：指業務平臺?？筛鶕緲I務規模大小、業務領域或公司主體等維度，對對接的業務方進行區分，接入后這些業務方即成為支付平臺的收單商戶，使用平臺支付產品實現其收付費功能需求；

用戶：業務平臺 C 端用戶，可根據業務方進行劃分；

業務系統：業務端的業務系統；

支付系統：支付清結算平臺。

收單網關流程

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

業務系統收到異步通知后，結合自身的業務規則改變支付單狀態，進行如訂單狀態更新等業務處理。

接口定義

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

接口設計說明

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

①交易狀態變更通知：通知業務方時，接口信息里面會傳遞業務訂單號、交易訂單號、狀態、金額、時間等相關信息，以便業務方能更好的做業務處理；

a.交易狀態：交易訂單的狀態；

1. 等待買家付款
2. 付款成功
3. 交易成功
4. 交易結束
5. 交易關閉

②退款狀態變更通知：通知業務方時，接口信息里面會傳遞原始業務訂單號、退款業務訂單號、退款交易訂單號、狀態、金額、時間等相關信息，以便業務方能更好的做業務處理；

a.退款狀態：退款訂單的狀態；

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

交易服務

交易服務的作用

• 將支付系統的支付能力抽象出來，提供各類交易方式，例如下單、支付、修改金額、確認結算、退款、關閉交易、查詢等標準接口，對外輸出收單網關；
• 基于收付款方的交易鏈業務路抽象交易類型、交易產品以滿足不同業務方各類交易場景的需求；
• 鑒權校驗、交易結果通知；
• 對接業務方。

擔保收單交易

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

③擔保交易設計

定義擔保交易產品代碼，標識此類交易訂單的類型。擔保交易分為下單支付和結算兩個環節：

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

即時到賬交易

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

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

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

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

①流程

②即時到賬的設計要點：

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

充值交易

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

• 業務平臺充值
• 支付平臺充值

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

①流程

②充值交易的設計要點：

• 首先定義充值產品的產品代碼；
• 業務端充值（虛擬幣）：此類產品虛幣賬戶體系獨立于支付系統；

1. 充值和虛擬幣的消費業務端完全閉環，由支付系統內部針對該充值業務開設一個統一的收款賬戶，結算時通過支付系統提供的入賬記資金分潤，適用于直播、視頻等純互聯網虛擬業務；
2. 接口定義：下單支付接口；
3. 優勢：開發成本低，實現起來相對簡單、可快速實現業務；
4. 劣勢：賬務不清晰，流程不統一、有一定資金風險。

• 支付系統充值：通過支付系統賬戶體系實現，所有充值資金通過錢包收銀臺或支付系統的充值網關接口實現；

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

出款交易

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

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

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

《支付系統設計白皮書》由 PingPlusPlus支付學院（ID：pingxxpi）出品。

本文由 @支付學院 原創發布于人人都是產品經理，未經允許，禁止轉載。

題圖來自 Unsplash，基于CC0協議。