各位同學好久不見，
開放課又為大家帶來了誠意滿滿的乾貨，
不知上一期有沒有你關注的問題被解答呢?
本期「錢方帳戶產品開放課」特別問答欄目，我們就聚焦一下知乎上關於企業支付方面的大熱話題，再邀支付專家梁川為大家解答，上期沒聽課的小夥伴歡迎去補課哦~
錢方帳戶產品開放課問答特別篇002
Q1:網關支付、銀聯代扣通道、快捷支付、銀行卡支付分別是怎麼樣進行支付的？
一、網關支付
這是在線支付的最普遍形式。大致支付過程：第三方支付公司作為代理（網關），接入一堆銀行。用戶在網關頁面（可以在商戶端，也可以第三方支付平臺端）選擇銀行，頁面跳轉到第三方支付平臺，然後重定向到對應的銀行，用戶在銀行電子銀行官網，採用網銀（個人網銀或企業網銀）完成支付。
網關支付分為：B2C、B2B兩類。
涉及的概念：網銀支付、銀行卡支付。
我們一般說的網關支付是指在PC上的在線支付，由於國內銀行基本上都要求安裝對應的安全控制項，且需要銀行的網銀客戶端，這也是大家經常抱怨網銀不支持MAC/Linux等作業系統、不支持除IE外的瀏覽器等兼容性問題。
在手機端也有類似網關支付的形態，但由於操作過程較為麻煩，體驗不好，一般都採用快捷支付等支付形式。
二、代扣
代扣一般指用戶通過線上或線下櫃檯方式籤署「用戶-商戶-銀行」的三方協議，授權商戶可以從其銀行帳戶中扣錢。典型應用場景是電視費、保險費定期的扣除。
題主提到的銀聯代扣通道是指使用了銀聯代扣服務及通道，代扣服務及通道的提供者可以是銀聯、銀行、結算中心、第三方支付等，銀聯只是其中之一玩家。
代扣服務分為：對公代扣、對私代扣兩類。銀聯通道只能是對私。對公代扣只能通過銀行銀企直連、各地結算中心。
涉及的概念：快捷支付。快捷支付一般都使用了銀行的代扣服務。代扣服務本身不一定拘泥於銀行卡，可以是銀行虛擬帳戶等。
三、快捷支付
快捷支付本質是代扣服務（對私）的產品包裝。傳統的代扣服務的授權過程較為麻煩，而且行業應用場景限制較多（例如只對實名行業開放）。快捷支付針對小額支付的需求場景，簡化了授權過程（例如只需要完成持卡人銀行卡、身份證、手機號的實名認證即可），同時通過下行簡訊驗證碼的形式來完成消費確認，很好平衡了安全性、便捷性。涉及的概念：代扣、銀行卡支付四、銀行卡支付
主要指以銀行卡帳戶為依託的支付形式，與此對應支付形式有銀行票據（本票、匯票、支票等）、銀行行內虛擬帳戶支付等形式。
銀行卡支付主要有線上支付和線下支付兩種形式。線下支付就是通常說的POS收單；而線上支付就是我們通常說的在線支付。
與銀行卡支付相關的經常提到的概念：無卡支付。
無卡支付分為：貸記卡無卡支付（業內的一些叫法：motopay、ePOS）、借記卡無卡支付。無卡支付形態（以銀聯為例）：認證支付、普通支付、快捷支付。銀行卡在線支付要求銀行卡必須開通在線支付功能，而無卡支付並不需要開通在線支付功能。主要利用支付驗證要素（卡號、密碼、手機號、CVN2、CVV2等），結合安全認證（例如簡訊驗證碼），讓持卡人完成網際網路支付。
五、網銀支付
指使用銀行的網銀客戶端完成支付，一般與PC端的在線支付相關。可以參考參見網關支付的解釋。
Q2:支付失敗，可以切換渠道重新發起嗎？
由於是代扣，商家要發起一筆代扣，必須具備如下幾個條件
1. 商戶籤約及接入
商家在提供支付通道的第三方支付服務商籤約並完成接入。
2. 用戶籤約
在商家籤約前提下，用戶通過商家平臺向第三方支付發起代扣籤約請求，授權必須針對指定的代扣通道（例如工行小額代扣通道、招行無磁無密代扣通道等）。
3、第三方支付與提供代扣通道的銀行等籤約
對第三方支付服務商，會按照商戶籤約協議id+用戶籤約協議id（隱含了特定的代扣通道、金額、頻次等）對一筆代扣請求鑑權。
對銀行等提供代扣通道服務的服務商，會按照支付服務商籤約id+商戶籤約id+用戶籤約id對一筆代扣請求鑑權（這幾要素根據代扣通道服務商與第三方支付的合作情況有所不同）。
以上說的標準意義上的代扣，快捷支付情況稍微有點差異，核心差異在於第三方支付是否在中間提供了單獨的錢包帳戶。但原理類似。
說起來太抽象，換成場景的實際例子就是：
假定同一個商家接入了三家第三方支付的代扣通道，則如果要實現在某一通道支付失敗後，切換到另外一個通道代扣，則需要用戶提前通過商家平臺先三家第三方支付分別發起代扣授權籤約請求。
1、那麼從用戶體驗角度，有沒有可能只需要用戶輸入一次資料，由系統自動完成各個通道的自動籤約？
市面上確實有一些支付公司的部分通道提供了自動籤約的功能，但由於風險過大，一般都不會直接對外開放，即便開放也有諸多限制。
因此可以說這條路行不通。對於代扣，必須有用戶明確授權協議，否則後期投訴、拒付之類問題出現頻率會大大增加。
2、假定用戶已經在多條通道已經授權，那麼系統能否自動發起代扣呢？
建議：儘量避免此類操作。
原因一：支付結果可能是非終態。
做支付的同學都遇到過，即便是上遊發卡行訂單結果通知支付失敗或成功的情況下，隔日對帳也會小概率出現訂單狀態反轉的情況，尤其是一些小銀行的支付通道。
代扣失敗的原因很多，例如餘額不足，金額超過限額等等，而大部分代扣通道提供的錯誤信息有限，很難作為代扣是否真正失敗的依據。
原因二：成本考慮。
有很多代扣通道是按照發起代扣，不論成功失敗就扣費的。
原因三：業務邏輯考慮。
由於基本上所有代扣通道都不會提供帳戶餘額查詢功能，只會對每一次代扣請求返回成功、失敗信息。那麼在發起代扣請求時，全額扣款失敗情況下，要不要按照更低金額扣款？按多少扣？
而以上幾個問題糾纏在一起，則會出現一堆問題。
Q3：第三方支付公司風控系統都有哪些？如何自建風控系統？
風控系統與所在行業、區域（國家）、業務模式、業務數據量積累、生產運營經驗等都有密切關係，目前目前現成的雲風控大致有如下幾類：
1、依託特定行業/領域長期歷史數據積累提供的服務
像外卡收單的Retail Decisions(ReD)針對盜卡之類的服務、Maxmind提供的針對GeoIP的IP黑名單庫、IP代理伺服器檢測等服務。
當然也包括諸如國政通、公安部身份證認證系統之類依靠壟斷提供的服務。
2、針對特定領域提供風控服務
目前雲風控都剛起步，指望大而全的服務基本上都不靠譜，目前市面上諸多雲風控廠商在特定行業的歷史數據積累和運營經驗沒有、業務風控規則的積累也沒有，單純有一套忽悠人用的方法論及所謂的健全的系統。
只不過市面上一些公司的服務在特定領域還是有價值（當然這些公司都希望轉型為提供大而全風控服務的廠商），像一些公司提供信用評級算法服務、基於設備指紋識別的反欺詐服務等。
3、徵信服務
除了央行的徵信系統、螞蟻金服的徵信系統外，個人認為短期內鼓吹徵信服務或提供全面風控體系解決方案的都是不合常規的。
關於自建風控系統，整體而言，我個人傾向於：
1、在特定領域使用專業廠商的風控服務，例如盜卡、IP庫、設備指紋識別等2、在風控系統IT規劃上，學習借鑑成熟廠商的系統架構、方法論3、在風控系統建設上，採用開源解決方案+自主研發的方式個人推薦方案：規則引擎（Drools）+ CEP（Drools Fusion、Esper或Spark）+機器學習算法（scikit-learn）