20180113-聚合支付通道接入流程

主流支付渠道都推出了諸多支付產品，面對消費者支付選擇多樣化的需求，商戶需要接入不同渠道、不同支付產品。面對不同的渠道、不同的產品產品，需要商戶逐個去申請簽約、等待審核、開發聯調……費盡心力接通後，還要在各渠道、各產品不同清結算方式下，根據正負向訂單、結算周期、手續費，歷經漫長的對賬折磨；遇到通道不穩定產生的各種異常，漫長、低效的溝通也會讓商戶欲哭無淚。

在此基礎上，聚合支付業務通過整合各渠道的不同支付產品：

1. 協根據商戶的實際需要，幫助商戶選擇合理的支付產品以及相應的營銷工具；

2. 幫助商戶極速入網，提交一次資料，即可在各通道完成簽約；

3. 幫助商戶極速對接，在技術支持的協助下，使用聚合介面，快速對接、聯調下單、查詢、退款、撤銷、對賬單下載等開發環節；

4. 7×24小時的客服服務，商務經理、技術支持等隨時處理商戶疑問。

二、 聚合方式

1. isv直連模式：

申請成為支付寶、微信的官方服務商，按照螞蟻金服服務商平台、微信服務商平台的指導說明，逐步完成資質審核、介面開發等環節，官方文檔有詳細的介紹說明：https://docs.open.alipay.com/399/106917/

https://pay.weixin.qq.com/wiki/doc/api/sl.html

2. 間連銀行模式

通過合作銀行通道（或第三方）介面，為商戶提供進件、交易、結算、對賬、退款、撤銷等服務；

3. 主要涉及介面

……

4. 核心系統構成

三、盈利模式

1. isv直連模式：主要通過返佣、獎勵金，或者報名支付寶、微信官方針對服務商推出的營銷活動

2. 間連銀行模式：通過手續費差額，賺取分潤

Q：請問對接過京東嗎？和銀聯是不是兼容的？A1：不同的通道，對接肯定是不一樣的，所以才有我們聚合存在的價值 A2：京東用的是銀聯的二維碼標準

在規範、安全的大前提下不斷創新是京東支付一直以來的發展原則，今年以來，京東支付通過採用銀聯統一標準，實現二維碼業務的互聯互通。京東金融作為銀聯戰略合作夥伴首批加入了銀聯二維碼支付體系，與銀行業一起全面支持銀聯二維碼聯網通用。之前看京東是這麼宣傳的

Q：銀聯二維碼接入是介面還是插件？

A：這主要是在說2017年出來的一個新產品：銀聯二維碼。主要是為了統一支付二維碼標準。我們也接了，目前來看，參與的三方公司不多，而且實際效果不理想，還是缺少場景支持。

Q：銀聯二維碼好像都是插件放進付款端，主推是銀行付款端，收單端具體是怎麼接入？

A：是介面，但是介面可能會被通道包成插件。所以商戶端還是要看上游通道制定的接入形式。我們是直接給商戶介面的

Q：銀聯應該是從掃二維碼開始都在銀聯端完成吧？有個跳轉的過程？

A1：感覺講的有點泛，能否深入說下一碼付，還有固碼跟活碼還有公眾號支付，h5支付之間互相包裝的細節，還有小商戶批量進件後的交易輪詢機制，微信支付寶對不同銀行渠道的額度分配和風控策略，以及投訴處理機制和申訴機制

A2：1、包裝其實就是渠道的介面，包裝秤統一下單介面，根據商戶請求，再去調用具體的渠道下單介面，這裡面並沒有多少可以講的，因為底層都是一樣的，具體怎麼包裝，需要結合每個公司具體的系統、業務。 2、小商戶批量進件，是指我們將通道的進件介面也包裝成聚合進件介面。不過風險比較大，無法直接控制風險商戶。 3、額度分配：這個需要看你接入的通道情況，一般都是手動切量，因為隨時會面臨銀行通道談判； 4、風控策略：實名認證、白名單、限額……，具體不便展開； 5、投訴：會有專門的部門來承接商戶的申訴，負責跟通道房溝通

Q：關於一碼付的說明

A：關於一碼付：或者叫做卡牌、新立碼，我們是通過公眾號服務窗的介面包裝的，一個二維碼包含了支付參數、H5包裝頁面，並通過掃碼瀏覽器判斷渠道、然後去渠道層獲取支付參數，並通過交易層去渠道下單。

Q：被微信支付寶限額限制過么？公眾號支付費率千分之六點五，原生固碼千分之二點五，現在用原生固碼做不了一碼付了吧？

A：1、支付寶、微信都有強大的風控系統，發現異常交易會直接給商戶限額，或者關停交易，我們會根據渠道返回的報文來知曉，並協調商戶排查，或者想渠道方申訴； 2、費率的不同其實是以商戶的使用場景、業務類型來區分的，商戶進件、簽約的時候，都會上送相關的信息供通道審核。一般來說分兩檔，

官方：線上：1.2%左右；線下：0.6%左右；

銀行：線上：0.6%左右；線下：0.2%左右；

所以，這裡面就存在虛假包裝的問題，比如把線下的主掃介面，包裝成卡牌給商戶用於線上的交易。但是目前支付寶、微信的風控系統會馬上發現。輕則處罰商戶、重則影響整條通道的使用。所以我們的風控系統會商戶接入的時候申審核商戶的實際業務。 其實只要介面研究夠深入，可以玩出花來。

所以接通道之前有一件非常重要的事，就是介面評估

Q：對於近期出台的296號等文 對貴司業務模式影響如何呢？

A：我們去年玩折了二十多條聚合支付的銀行。 金融就是各種找到政策覆蓋不到的地方，發揮到淋漓盡致，直到被監管。

Q：你們支付對前端商戶放的快捷支付是用後台通道的代收介面封裝的還是直接用的後台通道的快捷？

A：不會用代付介面來包裝支付產品，我們還有一條聚合代付的業務線，跟聚合支付平行

Q：代收包裝快捷支付呢？不是代付

A： 不會的

Q：進件是什麼意思？

A1：進件就是錄入商戶

A2：進件就是把商戶信息上送通道，審核入網

Q：你們有給商戶提供快捷支付介面嗎？

A：有銀聯快捷介面， 不過對於聚合支付，主要還是微信、支付寶兩個渠道

Q：那你們的產品應該主要是聚合，有些商戶是需要快捷支付的

A：嗯，所以我也接了快捷，只是業務量很少

Q：我現在遇到一個問題，就是我們前端給商戶提供快捷支付，我們在中間，後台接通道的快捷支付，當有多個通道時，在綁卡簽約的時候遇到2個問題。1、要不要同時簽約後台所有通道 ？同時簽約的話用戶會收到多條簡訊很彆扭。2、如果不同時簽約，就起不到智能路由的作用，對前端商戶來說兩個通道就相當於是兩個介面，有點不友好吧。我感覺被這個問題搞暈了，我了解有些公司就是用代收介面包裝的

A：這是個通病，現在一般簽約是發送簡訊的，支付不需要發送。所以智能路由當切換通道的時候，支付發送簽約的簡訊，然後簽約成功直接調用支付介面。這樣來實現智能路由，相當於假如切換一個通道以後，新通道未簽約，先簽約，後直接支付。讓用戶無感知

Q：沒法做到無感知吧，簽約簡訊是發卡行發的？

A1：操作上是一步，簽約簡訊還是會有

A2：關於簽約需要發簡訊的問題，這個都可以找通道方放行的，我們目前的支付通道，都會取消簡訊驗證的環節。當然，還是得看跟通道方的關係。還包括一些紙質協議這些問題，都是可以跟通道房爭取的。

A3：有些通道後台接的銀行堅持要自己發，政策上對發卡行發簡訊也有要求

A4：一般提供的簽約介面有發簡訊和不發簡訊兩種，看通道要求啦

Q：簽約和支付放一起是吧

A：是這個意思，操作上，用戶交互就是一次了。對於已經做過快捷簽約的用戶，針對綁定的這個卡，也可以用代收包下

Q：是的，不過代收應該有政策風險，後面可以可能會關閉吧？

A：對，代收通道逐步收緊。對場景和限額要求越來越多。

本文檔來自「支付產品架構交流群」 的聊天記錄整理，由志願者整理並發布到本網站。如需要及時收到來自「支付產品架構交流群」的最新消息，請掃碼關注「鳳凰牌老熊」的微信公眾號。目前支付產品架構群還有不少空位。 本群面向支付行業的有經驗（2年以上）的產品經理、軟體工程師、架構師等，提供交流平台。如想加入本群，請在本文評論中留言（不公開），說明所在的公司、負責的工作、入群分享的主題和時間。

推薦閱讀：