今天要分享的內容，會以商家的視角去分析對接渠道過程中需要關注的問題。

一. 支付渠道業務規則

這部分內容主要介紹常見支付渠道的業務規則以及選擇渠道過程中需要關注哪些重點，主要面向商家的業務部門，方便根據自身業務模式匹配最合適的支付渠道。

1. 產品概述和應用場景

要想了解支付渠道的業務規則，首先需要知道目前主要的支付渠道、支付產品有哪些，是什么模式，然后商家根據自身產品及業務模式去匹配最優的支付方式。

一般情況下對接的支付渠道有兩類：

• 銀行：招行、建行、農行等
• 支付機構：微信、支付寶、京東等

每個渠道有自己的收款產品，對應在不同的支付終端上使用。這里講一下，「支付終端」換成「支付場景」也是合適的，不同公司團隊個人叫法可能有所不同，總之方便理解來看就是電腦網站、手機網站以及手機應用等等。

這里將各個渠道的收付款產品放到了對應的支付終端下，不同支付終端下支持的渠道支付產品也有所區別，且需要獨立申請開通權限。

微信在移動應用、手機網頁、pc 網頁、公眾號內、線下掃碼、微信小程序中的支付產品分別是：APP 支付、H5 支付、掃碼支付、公眾號支付（僅能在微信瀏覽器內支付）、刷卡支付（也包含掃碼支付 ）、小程序支付（ 其中小程序內不能使用其他渠道的支付產品）。掃碼支付和刷卡支付的區別是，前者是用戶掃商家碼，后者是用戶的支付碼被商家掃。其中需要注意的是，APP 支付和公眾號支付需要分別在開放平臺和公眾平臺進行申請開通。開通公眾號支付后，默認會開通掃碼支付和刷卡支付的產品權限。H5 ?支付功能是在微信商戶平臺上開通的支付產品權限，前提是至少開通APP支付、小程序支付、公眾號支付的其中一種支付權限。

分期產品：目前比較常見的花唄分期和京東白條，這兩家的分期產品早期都是放在收銀臺的一種支付方式，C 端用戶在選擇支付寶或者京東支付之前并不能直觀的了解到該商家是否支持分期，所以后期兩家也推出了分期前置的模式，即支持分期支付方式直接在商家收銀臺進行展示（對于 C 端用戶來講，更加直觀，體驗更好，能夠有效降低消費者心里門檻），與支付寶、微信、QQ 錢包支付可做平級展示。

簡單介紹了商家收款，我們也來看看商家付款的產品功能：

• 代付：代付，我們通常稱「代付」主要指的是商家充值到在支付機構開通的備付金賬戶，然后直接調用代付接口下發給 C 端用戶或者 B 端商家銀行賬戶。
• 轉代付（這個叫法可能不同公司有所不同，轉代付比較容易理解）：轉代付，這里指的是先通過支付渠道的支付產品收款至企業賬戶，然后直接通過出款接口進行下發?，F在的微信新資金流的企業付款就是轉代付的模式。
• 分賬（嚴格意義來講不能稱之為商家出款行為）：指的是商家在發起收款訂單時即指定了相關的分賬信息，用戶支付成功時，直接將資金分賬到對應的 B 端商家企業賬戶。

下面一張圖看看轉代付和分賬的區別：

B 商家發起收款?100 元，后續可以給?C 端商家或者?B 端商家進行打款。這里需要注明的是，給商家或者用戶打款的?X 和?Y 元，跟?100元沒有必然聯系，只要確保出款賬戶內資金足夠用于?B 商家打款即可。

這里需要提及下，微信的企業付款只能針對?C 端用戶，不能給?B 端商家打款。支付寶的單筆轉賬可以給?C 端用戶和?B 端商家的支付寶賬戶轉賬。

因為微信現在區分新舊資金流，所以現在企業付款到零錢資金根據商戶號的賬戶開通情況，實際出款賬戶有做區別：

• 默認情況下，企業付款到零錢使用商戶號基本戶（或余額賬戶）余額。如商戶號已開通運營賬戶，則企業付款到零錢使用運營賬戶內的資金。
• 基本戶（或上述其他出款賬戶）的資金來源，可能是交易結算款項（僅基本戶），或給賬戶充值的資金。當出款賬戶余額不足時，付款將因余額不足而付款失敗。

B?商家發起?100 元收款，含分賬指令給?C 商戶?20 元，那么最終用戶完成這筆訂單支付的時候，則商家?B 收款?80 元，商家?C 收款?20 元。分賬模式比較適用于平臺類型的商家或者集團類型的商家，目前所接觸到的微信分賬并沒有對外開放申請，最多關聯的分賬賬戶有 5 個的限制。支付寶的分賬目前看到的是在跨境上有用到，最多支持在?10 個以內。兩個分賬功能均需要單獨聯系?BD 進行申請。

2. 行業準入和區別

（1）商家收款類別

1）這里簡單列了下大的分類，主要有實物類、虛擬類和政府/事業單位（主要指的公立醫院和學校）走微信和支付寶的渠道申請所對應的費率和結算周期的區別。特殊行業對應所需要的資質也有所區別。

• 實物類：醫療類的會有資質文件才可以申請，比如醫療器械、身體康復用品的需要持有《醫療器械經營企業許可證》、經營內容包含美瞳或者隱形眼鏡，則需要提供《第三類醫療器械銷售資質》等等；
• 虛擬類：比如游戲道具購買，需要具備《網絡文化經營許可證》。

2）商家的行業可以直接參照騰訊或者支付寶的的商家類目、費率、資質的文檔，簡單粗暴，可以到官網上了解一下。

3）這里提及一下，前面的花唄分期和京東白條產品：使用的前提都是至少擁有支付寶或者京東對應的基礎支付功能，才能進一步申請分期的產品權限，目前兩家的分期產品的權限都是需要單獨聯系 BD ，走線下申請的流程，周期較長。

（2）商家付款類別

Tips：微信新資金流開通企業付款功能要求商戶號開通 90 天且持續 30 天以上有交易流水，才可以申請開通「企業付款」權限，且目前服務商模式不支持企業付款。

目前銀行卡代付的申請，看各家機構的要求，目前尚且沒有比較固定的行業分類?；旧?case by case 的去看。所以我們主要看看在使用商家付款產品的時候，需要關注哪些內容。

① 費用

看代付的費用從兩種情況來看，一個是付款到銀行卡，一個是付款到錢包賬戶。

前者的費用一般是按照單筆手續費計算，比如 1-2 元/筆。后者代付到錢包一般是免費，這個手續費商家不承擔，主要在用戶發起提現的時候會需要支付提現手續費。

② 限額

各家支付機構不一樣，但是主要需要與支付機構溝通的是單筆、單日、單月、以及每天的調用頻次等是否有限制，限制是多少。

避免業務部門已經申請完成了渠道，后面產品對接發現根本不能滿足業務應用場景，那就后使用起來就?GG 了。

③ 到賬時間

選擇商家付款渠道的時候也需要關注付款到賬時間，因為有些應用場景對于實時性要求比較高。

④ 支持的銀行

支持銀行列表也需要多加關注，尤其是 B2B 轉賬或者對于有特殊銀行需求的商家。

前面在商家付款中提到的代付和轉代付，對于微信的企業付款產品區分新舊資金流。

微信現在區分新舊資金流企業付款到零錢資金根據商戶號的賬戶開通情況，實際出款賬戶有做區別：

1. 默認情況下，企業付款到零錢使用商戶號基本戶（ 或余額賬戶 ）余額。如商戶號已開通運營賬戶，則企業付款到零錢使用運營賬戶內的資金。
2. 基本戶（或上述其他出款賬戶）的資金來源，可能是交易結算款項（僅基本戶），或給賬戶充值的資金。當出款賬戶余額不足時，付款將因余額不足而付款失敗。

3. 渠道合作模式和優惠政策

早期商家跟渠道的合作比較單一，但是近 2 年渠道也推出來比較多的合作模式來吸引商家以及合作伙伴。

簡單介紹下各種合作模式：

1. 直連
2. 直連（ 入駐 ）
3. 普通服務商
4. 銀行服務商

目前服務商模式做的比較好的是微信和支付寶，微信的營銷活動做的比較好，之前的智慧餐廳推廣疊加活動、隨機立減活動，以及最近的朋友圈廣告功能投放功能等等活動，無論是從商家成本還是用戶體驗上，都極大的調動符合條件客戶參與活動的積極性。

各種合作模式的優缺點

4. 退款處理規則

接下來我們講講退款，原先「退款」這一塊的邏輯是放在后面渠道開發對接部分的。

但是因為近期日常渠道運營中遇見了一個關于手續費的問題，退款是否退回手續費的問題一定程度上決定了某些特定場景的商戶對于支付渠道的選擇，因此把它提到業務規則中來聊一聊。

為什么在業務對接的時候就需要關注上圖這三點呢？

1. 某些特定行業對于退款的周期有特殊要求，比如共享單車的押金、家具公司的較長退貨期等等，這一類允許較長周期退款的行業都需要關注各個渠道的退款周期。如果退款周期不滿足需求，最好在入網階段就能提出延長訂單可退款周期的需求，按照渠道要求提交業務說明并變更退款周期。避免到了后期渠道不好調整而導致用戶與商家的糾紛投訴。
2. 關于退款是否退回手續費的規則需要提前與渠道確認好，正常情況下當用戶產生退款，商家是會被渠道退回支付時收取的交易手續費的。但少部分支付渠道存在以下幾種情況：退款不退回手續費、部分退款不退回手續費、退款只退部分手續費（退動態手續費，不退固定手續費部分）

因此需要提前捋順幾個問題：

1. 退款功能是否需要提前額外申請
2. 退款周期是否需要延長
3. 退款資金是否需要額外充值：待結算賬戶、余額充值賬戶
4. 退款或者撤銷是否退回原訂單的支付手續費

以下是一張關于各渠道的退款周期，是否退回手續費以及退回手續費的邏輯說明：

5. 支付渠道對接及管理

（1）資金結算方式

手動提現還是自動結算，自動結算是否有資金門檻（因為在跨境微信支付寶的渠道資金結算，直連會有 5000 usd 結算資金門檻）

（2）獲取對賬單方式

業務需要提前確認獲取對賬單方式，是只能通過商戶平臺下載還是也能通過接口下載。

如果通過接口下載是否需要提前走申請流程，因為我們有遇見過一些支付渠道下載對賬單也需要提前走線下公司蓋章的申請流程，周期略長。前期若沒有確認好，會都后期項目開發周期造成影響。

（3）清分時間

這個跟獲取對賬單方式時候可以一并確認，一般渠道的清分時間都是 00-24 點之間的交易。

（4）區分不同交易對賬單

• 微信新資金流，因為沒有待結算和余額充值賬戶的概念，退款都是從基本戶中出去的，所以退款的訂單都會在 ALL 類型的對賬單中；
• 微信舊資金流，區分待結算賬戶和充值余額賬戶，即使針對 ALL 類型的對賬單，也不包含余額充值的退款對賬單。

二. 支付渠道對接及管理

這部分內容著重介紹在開發對接渠道過程中需要關注哪些問題，主要面向商家的產品部門。

第一部分主要講了商家的業務部門在前期申請渠道時候，場景適配以及需要提前跟渠道溝通了解的注意事項。

第二部分就涉及到產品技術對接階段的一些細節處理。

1. 渠道對接步驟和內容

公司內各個部門不同的產品，線上線下產品適用場景不同，費率會有所區分，注意事項在第一部分已經闡述。

1. 切記不要申請錯了權限，這個對于微信是比較常見的問題（ 服務號、訂閱號、APP ）
2. 配置并獲取參數，這一個步驟建議是產品與業務部門能一起操作、確認。另外如果有線下版本的協議，建議產品也可以看下，因為我們曾經遇見過一些渠道有業務處理時間的限制，但是沒有寫在線下開發文檔中，是單獨列在了協議中。在獲取參數時，部分渠道是一定要通過測試案例提交才能獲取正式參數，此處也需要留足項目時間。
3. 對接支付相關的 API ，按照自己內部支付模塊以及支付渠道的對接開發文檔對接開發即可。
4. 上線結果通知：這一步列在這里的原因是因為對外的技術服務商在日常工作中需要留足足夠的時間給協同模塊。
5. 關聯模塊功能更新：可以完成一筆成功的交易并不代表整個交易功能已經完善。比如對于交易明細的展示和管理、報表展示。后期商家內部渠道參數的更新、維護等配套模塊也需要做更新。

① 是否需要添加出口IP

部分渠道需要添加 IP 白名單才可以進行開發、測試調試，有些渠道較快的能添加完成，但是有些銀行類的可能要走比較漫長的線下申請。

② 對接的接口版本

不同支付渠道的接口版本對應的支付渠道的參數也不一樣，所以在商務確定產品合作后需要確認對應的業務申請參數和渠道開發的接口版本是否一致。

③ 訂單號長度和組合

支付機構遇到此類問題比較多。每個渠道的訂單規則其實略有不同，例如招行早期的訂單號只允許數字形式，不允許其他任何符號；微信、支付寶和銀聯對訂單號的長度要求不同，因此建議訂單號長度為 8~20 位，目前來看基本可以適配要求。

④ 交易金額單位

一般情況下單位都是以「分」為單位，但也遇到過以「元」為單位的情況。

⑤ 商品描述特殊字符，是否展示在用戶可見的渠道支付頁

部分渠道會因為在商品描述中加入了特殊字符而導致交易失敗，然后因為報錯提示信息不明顯，會導致開發定位較長時間，另外需要確認該信息是否會展示在用戶所見的渠道支付頁上，避免字段設置的信息給用戶產生疑惑。

⑥ 收款公司名稱展示

常規情況下，大部分支付渠道是可以在后臺進行設置或者在入網時有很清晰的提示，但是有些渠道是通過某個字段來進行填寫并上傳的，比如建行龍支付。

⑦ 訂單過期時間的模式確認

1. 絕對時間（ 某個固定的時間 ）
2. 相對時間（ 例如用戶在支付頁面密碼輸錯了扣款失敗，才開始計時 ）
3. 二維碼有效期
4. 過期時間單位

⑧分期支付是否支持前置展示

主要是用戶體驗的問題，假設不做前置展示可能會在最后一步支付時流失掉這個訂單。

⑨ 是否支持禁用信用卡

有些商家不希望用戶支付使用信用卡，部分渠道可以通過請求參數字段進行設置，也有渠道通過入網簽訂協議后臺配置。

⑩ 前端帶回的參數信息

大部分商家比較在意前端帶回的結果參數信息，例如訂單號、支付結果等等

① 可退款訂單周期、權限開通

之前在對接線下掃碼支付，走服務商模式，退款權限并不默認開通，需要走線下申請的流程后才可以開通?？赏丝钣唵沃芷谌缰疤峒?，需要提前申請確認。

② 單筆訂單退款次數、頻率限制

例如微信是有單筆訂單對多 50 次退款限制的，雖然實際場景中遇見單筆退款幾十次概率很小，但一旦出現這類情況就需要做好線下給用戶退款的準備。

③ 是否支持原單重試

這種場景微信比較多，微信現在文檔上備注的已經十分詳細了，尤其對于商家轉賬紅包這種類型的出款，一定需要提前確認是否支持原單重試，避免重復出款。

④ 是否支持部分退款& 是否退還手續費以及計算邏輯

對接的渠道大部分都支持部分退款，但是有些個別的渠道是支持退款不退手續費。因此商家遇到用戶退款的情況，就會在退款時損失手續費。同時對計算邏輯也要進一步確認，有些渠道的手續費分兩部分，一部分是固定手續費，一部分是動態手續費。在退款時也會有全退、只退動態手續費不退固定手續費以及手續費全部不退的情況。

⑤ 多選一單號請求，需要確認優先級

這個在退款時微信、QQ 錢包都有過類似的問題，例如早期 QQ 錢包超過 30 天的訂單如果不使用交易單號就會報錯。因此如果渠道的文檔表示兩個字段二選一都行，就要提前確認好優先級。

⑥ 退款描述特殊支付，是否展現在用戶可見的地方

這部分和前面是一樣的，就不細說了。

⑦ 是否支持退款的異步通知

最早期的時候微信退款無異步通知，我們自己做了個自動查詢模塊，定時（5s、10s、20s、1min 等等遞增）去調用退款查詢接口來獲取退款狀態，現在微信也支持了退款成功的異步通知，主要的支付渠道也都支持了該功能。

⑧ 是否區分退款資金來源

這塊主要是需要清楚地明白和業務的關聯點在哪里，一般在退款接口上會有區分字段提示。

⑨ 同步返回的狀態，是否可以作為最終結果

該種情況除了接口文檔上的描述外，建議與渠道再做二次確認。通常是根據異步通知或者查詢的退款結果進行更新，但是存在部分渠道建議直接根據創建退款同步返回結果直接判斷的情況，比如支付寶國際的退款，并不提供退款查詢接口。

① 支付和退款的查詢是否區分接口

有的渠道不作區分，但有的渠道例如單號是區分支付成功單號以及退款單號兩種不同的字段。

② 確認查詢接口展示的狀態參數

比如退款、用戶被掃等模式可能存在多個狀態，需要考慮多狀態之間的關系和更新邏輯。

③ 多選一單號查詢，需要確認優先級

與前文相同，不做贅述。

④ 區分通信結果、業務結果、交易結果

查詢一個交易結果之前需要判斷通信結果以及業務結果，最終展示的交易狀態要根據交交易結果來判斷。

⑤ 結算金額、優惠金額、退款渠道等信息是否返回

常規情況下渠道會通過支付成功之后的異步通知或者查詢返回對應的信息，但是也存在部分渠道是通過后臺配置的優惠信息，僅在支付成功頁面、對賬單中才有體現，并不會體現在交易返回參數中。

⑥ 查詢和異步通知返回的交易相關信息一致

例如支付寶國際支付，查詢與異步通知返回的信息不一致，是由于幣種的轉換造成的。存在部分返回信息需要提前郵件申請進行配置，雖然對外并沒有文檔指引和說明。

⑦ 查詢頻率是否限制，是否有建議的查詢間隔機制

不同的渠道略有不同，有的渠道對頻率有限制、間隔有限制。因此在前期需要確認。

① 各種交易是否有異步通知

產品與技術對接過程當中，需要稍微注意一下，因為渠道的文檔都放一起，按照慣例是都有的，但是背不住要踩坑，比如線下支付的用戶被掃模式。

② 異步通知地址是請求上送還是后臺固定配置

不同渠道不一樣，大部分是通過接口請求上送；小部分渠道通過后臺固定地址配置。

③ 何種狀態會觸發異步通知

需要校驗異步通知的狀態類型，比如支付成功、訂單支付中、訂單關閉等等，避免未區分異步通知類型導致錯誤更新訂單狀態。

④ 交易成功時間字段

有些渠道交易成功時間這個字段不正確，可能會導致對賬會出現一些問題，需要人工去處理。

⑤ 是否帶回交易請求上送的附加信息

在渠道提供的交易請求信息并不足以區分商家內部的業務訂單時，商家往往還會上送額外的字段信息，有些渠道有去無回，即異步通知不帶回該額外信息，導致商家業務更新異常。

⑥ 重試機制以及恢復信息

重試機制需要提前確認，如果渠道間隔時間比較長，就需要提前在訂單過期前之前加一些查詢機制，避免用戶體驗糟糕。

⑦ 簽名驗證或IP 白名單

異步通知的驗證真偽性一般可以通過簽名或者 IP 白名單，如果是 IP 白名單的話提現與渠道確認好出口 IP 。

2. 常見對接問題和解決方案

一般情況下上圖中的情況會導致交易異常，因此建議商家除了對接渠道異步通知也要對接查詢接口，可以設置查詢任務；同時不建議商家以業務查詢結果為參考，查詢服務端的訂單狀態，一旦不一致就調用接口去查詢一下，更保險。還有不要查詢頻率太高，可能造成渠道結果返回不了。

例如支付寶和微信使用線下渠道會有風控（ 一般線上套線下才會有 ），因此匹配自身場景去申請渠道是最安全的。渠道系統異常的情況，最好是多對接幾個渠道，萬一掛掉了一個另一個也不影響使用。渠道更新接口/ 規則沒有及時同步的情況，這就需要經常爬一下各渠道的公告平臺了。渠道數據狀態不同步的情況只能去咨詢渠道，根據渠道的建議去修改查詢模塊。

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

題圖來自 Pexels，基于 CC0 協議