聚合支付的「過去、現在、將來」

04-23

在過去一段時間，我們的客戶，還有業內的朋友，會經常問我一個問題， Ping++ 作為聚合支付先行者之一，怎麼看待近期一些監管的動作對這個行業的影響，在目前監管形式下， Ping++ 有什麼樣的計劃和想法。我今天就以這個展開，來談談我自己的一些觀點。

如果要為 2017 年支付行業選一個年度辭彙，我相信「聚合支付」是當之無愧的。從去年年初到到年底，這個詞頻繁出現在監管里，包括人行二度發文，217，281，296 號文，監管對這個領域的關注從未放鬆過。而在過去的幾年中，這個行業也確實經歷了一些起起落落，從市場層面看，聚合支付的參與者從兩手就能數得過來，到 17 年中的遍地開花；從產品層面看，從早期的專註線上支付聚合的技術服務，到後來針對線下的聚合支付，針對銀行機構的系統服務等多樣化的商業/盈利模式。

過去

在 14 年我們開始進入這個領域的時候，當時的市場現狀是：移動支付爆髮式增長，支付習慣得到了極大的普及，移動互聯網領域新型模式百花齊放。但有一個無法迴避的現實：支付渠道和產品的碎片化。

所以我們當時的出發點很簡單，就是要解決眾多企業在接入移動支付或線上支付過程中的問題。當時和我們做類似事情的公司也有一些，大家的想法都比較一致，基本上擺脫不開這幾個詞：SaaS，技術服務，聚合。

這個模式和傳統的支付行業衍生業態有一定區別：傳統的支付服務商一般是通過對商戶、資金、交易通道這三個方面的把控，通過交易手續費或資金流轉的過程中產生的價格空間來實現盈利，所以收費模式大多是費率模式，目標客戶也相應的是具有高流水，高價格承受力的客戶；而定位為技術服務商的聚合支付，商戶對渠道是透明的，都是直連入網。資金是直接由支付機構完成清算，交易費率由商戶和支付機構之間直接確定。收費模式是免費或者按年收取技術服務費，目標客戶是一個中長尾的客群。

所以，這個階段，聚合支付還屬於 ToB 領域的一個新兵，除了在特定的創業圈和開發者圈子裡，外面的曝光度很低。

現在

從 16 年中開始，伴隨著 96 費改，微信和支付寶通過服務商模式進行線下掃碼市場的拓展，並且投入大量的營銷資源。之前傳統 POS 收單服務領域的一些參與方，迅速的進入了掃碼支付領域。而此時，無論是對於原來線下收單市場的商戶側，還是渠道側，大家的需求都是一樣的。商戶依然看重的是費率，申請門檻和流程複雜性，操作便捷性，清算周期等等。渠道端也一樣，依靠著通道資源，價格優勢，藉助機構來實現商戶的拓展，通過費率差來賺取收益。

既然兩頭都一樣，那中間的市場玩法勢必相同，所以聚合支付的行業劃分，從原來的單純線上聚合，又增加了線下的聚合服務商，他們根據線下場景商戶的需求特點，聚合微信和支付寶兩邊的服務商介面，通過 APP，智能硬體，固定碼（聚合碼）等前端產品來給線下商戶提供掃碼收款的服務。這個市場在 16，17 兩年可以說是迅速增長。

再後來，銀行服務商的角色出現了，由於銀行本身天然具備的收單屬性，可以快速有效的幫助微信和支付寶進行收單業務的拓展和推廣，並承擔包括商戶審核和資金清算的工作。無論是對前端商戶的體驗，還是微信和支付寶的投入，這個模式都比原來的普通服務商模式有了很大的提升，很多銀行也積極進行這樣的新業務的嘗試，但由於這個業務本身屬於一個新興業務體系，無論產品還是系統或者業務流程都需要全新設計。因此，面向銀行提供聚合收單系統的聚合支付服務商也隨之而生。有 SaaS 模式的，有私有化模式的，有純系統服務的，還有提供一攬子解決方案的。

至此，這些不同類型的聚合支付作為專業化的 ToB 技術產品服務商，其業務模式本身沒有任何問題。

由於線下掃碼收單模式本質上和銀行卡刷卡模式非常類似，但是因為其業務的創新性，相關的監管並沒有同步，因此傳統線下 POS 收單領域的一些支付亂象也隨即出現，二清、套現、風險交易等問題逐漸暴露。所以 17 年年初，人行針對聚合支付連發了兩個指導意見，在過去的 3 個月里，又連發三文：217、281、296，來對支付領域的一些業務規則、產品創新和業務規範進行強調，其目的就是希望在規範市場行為的同時，引導行業的健康發展。

在這裡普及一個基本的概念：什麼是銀行卡收單的四方結構。四方模式，是從傳統的銀行卡線下收單模式中產生出來的一個市場結構，它根據整個收單服務鏈條中的各參與方所提供的服務和承擔的職責不同，將他們分為四個角色，分別是：發卡行，卡組織，收單行，商戶。他們各自承擔的角色也比較明確。

這四方中的前三個：銀行、銀聯/網聯、收單機構。他們中無論哪一個的設立，都是需要通過層層主管機構的審查才能獲批相關資質的。主要目的就是金融風險的防範，這個防範意識要求覆蓋了一筆支付的完整流程。從商戶入網審核開始，到交易處理，到最後的資金結算，交易信息的保留等等。其中任何一個環節的業務流程規則都是具備相當專業的考慮的。

而過去的一系列監管發文都是針對銀行等金融機構和第三方支付公司等非金機構的，作為通過支付來切入企業服務領域的聚合支付服務商，如果它的業務模式中，一旦涉及到了商戶入網審核，涉及到資金清算或者向銀行或支付機構發起清算指令等行為的話，那麼在這幾個環節是有極大的概率引入支付風險的。

因此，如果問我，最近的業務監管動作對聚合支付是不是有影響，我個人認為無論是針對線上場景，還是線下場景的聚合支付，只要堅持在自己的產品服務領域內，明確與上下游的職責邊界，不越權、不越界，那應該就不會受到直接的影響。

而且，我們認為新的監管要求，一定會同步帶來新的市場機會。例如，按照新的監管對支付業務規則的要求，各支付機構或者銀行都需要按照新的規範對原有的一些產品進行改造，這個改變無論對於立足商戶側的技術服務商，還是定位於銀行側的金融系統服務商，都可能會是一個切入的機會。而對於需要支付服務的最終端企業用戶而言，市場上的支付產品趨於規範化、合規化對其自身業務的發展也是一個有利的因素。

同時按照新的監管內容中對資金安全的要求，解決現有市場中普遍存在的平台、共享等新型商業模式的資金安全合規的需求，也是銀行或支付機構設計新的資金及賬戶類產品的切入點。

所以，新的模式下，新的產品的支持，新監管要求下，新的業務模式的設計，合規解決方案的匹配這都是新形勢下市場的切實需求和痛點。這也正是我想談的第三點，接下來我們可以做些什麼。

將來

首先，我覺得，必須堅持技術服務這個基礎。現在大家都在講 fintech， fin 是領域，tech 是基礎。作為一個金融領域內的技術服務商，由於金融業的特殊性，我們必須做到堅持原則，把握好自己的定位。面向商戶的技術服務商，必須緊密地立足於商戶業務系統的範圍內，站在商戶的角度，去進行產品，業務的設計；面向機構的的技術服務商，也必須堅持技術服務的範疇，發揮自身在技術領域的優勢和靈活性，為傳統金融模式的效率優化，性能提升，場景創新起到推動作用。

其次，要加大產品與客戶場景的耦合度，只有你幫助客戶解決了他切實面對的問題，客戶才會願意付錢。所以如果一直停留在支付接入這個點上，無論是線上聚合，還是線下聚合，其產品生命力都是有限的。目前銀聯已經整合了微信和支付寶的線下掃碼介面，從轉接機構的層面就做到了聚合；再看線上，一方面微信和支付寶的產品接入體驗在不斷的提升，另一方面不排除是否會和線下有一樣的業務調整。

所以我們必須要繼續向商戶的業務系統進行深入。在支付之上，提供更多更有價值的服務，也正是基於這樣的考慮，我們在 17 年推出了會員賬戶系統和多級商戶系統的解決方案。很多線下的聚合支付機構也在聚合收款的基礎之上，提供會員卡券營銷，精準廣告推送，衍生金融服務等。這其實都在往客戶的業務系統內部進行深入，一方面可以增強與客戶的系統耦合性，另一方面，通過提供更多有價值的服務來獲取更大的收益。

這裡我也想給聚合支付正個名，並不是所有的聚合支付都是通道公司，或者說他們本來不應該是一個通道公司，他們提供的產品是專業化的服務，這個成本對標的是企業自身獨立承擔這部分工作的投入成本，而不是支付機構的交易費率。而這個服務也不是一個簡單的技術介面對接，他還包括了方案的設計，業務的後期運營，這些服務涵蓋了一個產品從設計到開發及最後的運營全過程。

現在的時代，支付這兩個字已經不是一個簡單的一手交錢一手交貨了，各種新型的業務模式和營銷手段都對支付提出了更高的要求，例如最近比較火的課程營銷。他們的本質是內容輸出，通過對營銷手段的創新，逐級推廣、逐層激勵，最終對產品的營收起到了極大的提升。這樣的一個場景下標準的支付接入模塊顯然是無法滿足的，他還包含了會員管理的功能，多級分潤的功能。這才是我們認為聚合支付應該給客戶提供的服務。定位為基礎服務，但又要可以靈活的支撐客戶業務場景的模式創新。

最後，還可以橫向聯合。目前企業服務市場已經初具規模，用戶習慣也有了一定的普及。但是由於我國大量的企業服務類產品都是近幾年才逐漸出現的，公司的體量規模都還未到達一個巨頭的地步，而且企業服務本身倡導的就是術業專攻的理念，因此大多數企業服務商提供的產品和服務都可以被看做一個個特定領域的特種兵，而在一些新的場景下，如面對大型企業客戶的整合性場景需求的時候，單兵種的戰鬥力肯定是有限的，我們需要的是集結多兵種優勢，集團作戰，這樣才能最大程度的保證最終的戰鬥勝利。

以當前比較火的新零售為例，它主要的目的是實現線上線下流量的打通，數據的打通，相應的就需要支付的打通，在這個點上，不排除線上和線下的聚合支付服務商之間是可以進行聯合作戰的。此外，針對其他的一些特定行業，聚合支付服務商也可以和上下游的企業服務商進行聯合，對上包括企業內部 OA 系統，財務系統，進銷存系統，對下包括一些新興的智能設備終端，可穿戴式設備等等。通過這樣的聯合，可以有效的提高場景服務的能力，進一步提高戰鬥力和盈利能力。

聚合支付，在路上。

作者 | Ping++ 趙宇
來源 | Ping++ 支付設計大會 ? 北京站現場演講整理