酷播亮新聞
本文主要是與大家分享一種支付寶渠道服務商的的業務模式，這種業務模式對沒能拿到支付牌照且有資源的公司或企業來說具有普適性；但前提是能夠獲得支付寶或者微信 的的渠道服務商資格（簡稱isv，本文以支付寶的isv為例子進行闡述），且能在各大銀行中混得開，以求得結算通道。
下圖為行文的順序：首先介紹有關支付寶渠道服務商的相關知識，譬如相關概念、接口等；其次會以一種集成了支付寶三個接口的綜合支付運營系統為例，具體闡述相關業務的始末 。 希望能給大家帶來些許不一樣的視角。
支付寶ISV
支付寶ISV（也稱系統開發商）可代支付寶完成商家簽約、當面付集成、優惠活動配置的主體，為商戶提供線下支付寶收款、入駐口碑、發布折扣和支付寶商家服務窗等服務。
就個人理解而言，支付寶isv渠道商一般都是具有獨立軟件研團隊的公司和企業。 說穿了，這種公司存在的理由無非是在支付寶有一定的資源，靠著關係拿到了支付寶的幾個接口，面向某一鄰域的商戶，為其提供商業變現的解決方案，並從中拿到 分潤。 具體業務模式如下：
1、首先，公司或者企業必須獲得支付寶的承認，與支付寶簽訂N年的渠道服務商，其中必須明確其後系統集成的支付接口的詳情；並同時設置支付的對應接口的費率，每個接口 都對應設置。 一般：支付寶app為1.0、支付寶wap1.0、支付寶即時到賬0.6。
2、然後，公司必須能夠與一家銀行合作，為商戶解決每日的結算款的處理問題，同時也避免了二清。 這其中，系統與銀行端的交互基本上是相關的接口請求與響應。
3、其次，如果公司的資源很多，能夠拓展數以千計甚至萬計的商戶，此時可以想“代理鏈條”模式。
此模式能夠在很大程度上將系統的交易額提升到一個客觀的高度，且能“借他人之手”來管理商戶，一舉兩得。
4、最後，也是最最關鍵的，任何商業活動最終都會與“錢”掛鉤，支付更不例外。 因此，在設定支付寶成本費率的同時，公司也會與代理商簽訂合同，合同中就包含對應的代理商對應三個接口的費率；而商戶則會與被其拓展的代理商進行合同 簽約，此時也會設定商戶費率。 而這三個費率必須滿足一下關係：支付寶成本費率 ≤ 代理商陳本費率 ≤ 商戶成本費率支。 （此外，商業銀行對每筆訂單也會收取對應的手續費）否則，系統結算就會行不通。 具體費率計算會在下一章節的結算中給出具體的計算公式。
5、支付上下游各方收取的手續費總和為商戶被扣的手續費。
（ps：商業的本質其實是錢與服務發生了關係的存在）
線上支付系統
該系統集成了支付寶線上三種接口：支付寶即時到賬、支付寶wap、支付寶app，其本身就是一個功能齊全、業務邏輯複雜的後台運營系統。 可以理解為一個CRM為過，因為該系統確實管理和運營者支付下游代理商、商戶的關係。 如下圖，為線上支付系統的元素介紹。 其中商戶平台通過代理商平台與運營平台發生簡介數據流關係。
系統操作權限解析
不管是怎樣的系統，都會設計到賬號登錄。 針對這種複雜的業務系統，登錄權限設計更是必不可少。 本系統主要採用“分而治之”的設計思想，大致思路如下：
- 從一個超級管理員賬號出發，在運營平台為代理商創建賬號；
- 然後，代理商用全局唯一的賬號登錄代理商平台，然後再為次代理商創建不同系統角色的用戶來管理用戶；
- 最終，商戶的登錄賬號由代理商平台商戶報件時自動生成。
整個支付運營系統的功能分為四個部分：（代理商開戶）商戶報件、支付（開發麵向下游商戶的三個支付接口）、渠道對賬、商戶結算。 如下具體的泳道圖。
代理商開戶
運營人員為代理商進行開戶操作流程如下：
- 代理商需要與企業簽訂相關協議，其中協議的主要內容包含所用支付接口的個數、接口費率等；
- 代理商簽訂合同後，會在相應時間裡將代理商公司的企業信息、綁卡信息、費率信息以文檔的形式提交給運營人員；然後由運營人員在系統進行錄入、審核；審核通過後會 為該代理商創建登錄賬號，方便代理商登錄代理商系統。
商戶報件
商戶報件也即商戶入駐：
- 商戶入駐平台類似大學生入學，你得提供相關個人信息（身份證、手機號等），由學校相關人員（運營人員）將你的信息錄入教務系統，然後審核通過後，為你生成全局唯一的學 號（商戶編號）。
- 商戶入駐平台時填報的信息包含：法人基本信息、費率信息、綁卡信息。
- 此操作需要代理商在代理商平台進行頁面表單填報操作。
- 因為對接的是支付寶的交易接口，因此商戶報件的基本信息要提交到支付寶後天進行審核。 在整個過程中會調用支付寶黑名單查詢接口和支付寶間連商戶入駐接口。
支付
提供給下游商戶的額接口包括支付寶即時到賬支付、支付寶WAP支付、支付寶APP支付。
描述：
- 用戶通過商戶平台下單，商戶系統確認訂單後對訂單信息進行MD5加密，然後通過網絡上傳至代理商系統；
- 代理商系統也採用類似的加密方法，對商戶訂單進行驗證，然後將加密的訂單信息向上游傳遞；
- 運營管理系統接收到下游訂單，也會採用加密機制進行驗證，確認後，系統向代理商系統返回支付頁面的URL;緊接代理商系統向商戶系統傳遞URL，最終由商戶系統向用戶展示URL對應 的支付界面；
- 商戶直接與支付寶收銀台交互：輸入支付密碼，提交支付申請後，支付寶系統確認支付成功。
- 支付寶確認支付成功後，首先會回調支付結果給企業運營平台，然後再由企業運營平台回調給代理商系統。 完成整個支付流程。
對賬
設計到該支付系統的對賬為渠道對賬。
- 本系統的渠道對賬是指在當天某個時間通過網絡協議從支付寶獲取前一天平台的交易訂單信息（支付寶商戶號、支付訂單號、商戶訂單號、交易金額、支付渠道、支付時間等）， 一般以excel的形式從服務器上獲取。
- 獲取渠道對賬文件後，將其與平台數據庫訂單表裡的前天交易流水進行一一比對，判斷訂單是否出現問題（包含：無誤、長款、短款、金額不一致）
- 長款指運營平台有此筆訂單而渠道對或者那個文件裡卻沒有。 造成的原因主要是發生日切的情況下（23：59：00），平台記錄了商戶提交了訂單，但由於用戶未能及時支付；等到支付後，時間可能來到了第二天00：10： 01。 此時，同一筆交易就跨越了兩個時間維度（今天和明天）。
- 對於長款的處理一般會將平台的長款訂單進行邏輯處理，使其在明天的對賬過程中再次舉行對賬。
- 一般短款、和金額不一致的情況幾乎不可能發生，平台可不做處理。
- 另外，當日對賬完成後，系統可以生成對應的報表，其中典型的是對賬差異報表。
結算
說到結算，可能很多小伙伴們會比較興奮；因為，經過前面的一些“播種”、“施肥”操作，終於到了豐收的時候。 其實，結算就是通過銀行通道將商戶每天的扣除手續費後的交易額打到商戶的結算卡上的一個過程。 如果細心的話，這裡的提到的“結算卡”就是商戶報件時提到的結算卡。
下面的費率計算公式完全可以為ni所用：
誠然，支付系統是一個以業務為主導的互聯網產品。 如上敘述的支付渠道“販子”（運營）系統，對接的外部系統多、業務模塊複雜；那麼相應的，具體涉及到某個業務的細節，也是能夠喝上一壺的。 因此，這裡由於篇幅的原因，就不具體詳述業務深處細節。 希望感興趣的pm們一起探討。
本文由 @阮籍猖狂 原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來源於網絡