今天旁聽銀聯的技術人員和客戶開會，商討對接方案。不妨結合個人工作經驗來談談銀聯遇到非標交易時，結算支付上的細節有多少難度。
首先可以肯定的是，對於任何沒有第三方支付牌照的交易性質信息平臺，想要使得自身建設的平臺能夠運行交易項目，類似於電商的運營等，普遍採用接入第三方支付平臺作爲整個類電商平臺的支付模塊。那麼電商所要做的就是建設好自身平臺的結算模塊（普遍是採用訂單模塊的建設方式），然後調用第三方支付平臺提供的支付接口引導用戶進行支付。小Z對接過的第三方支付平臺包括微信支付、支付寶、招商銀行、易寶支付、匯潮等等。而對於業務爲非標、大額、低頻的交易性平臺，以上第三方支付平臺都無法滿足支付額度限制（賣車、賣房、賣飛機、賣輪船，有啥賣啥，記住關鍵字：低頻、高額、非標）。所以剩下的選擇面很小，銀聯或者是各個銀行的銀企直連。
多支付渠道聚合
先說銀企直連的對接。必須一個個銀行進行對接，因爲買賣雙方來源不定，手上的銀行卡（無論toB、toC）綁定的銀行是不定的，多個銀行支付渠道的使用帶給客戶心理上的安全感的同時、也使得其進行大額支付轉賬具有一定的便利性，交易所的交易流程是需要在指定結算賬戶繳納保證金，參與競價，中標後再通過結算賬戶繳納價款，最後完成價款轉出，通過以上的結算支付流程，基本解決資金的轉移問題，可謂一手交錢，一手交貨。然而，正是由於沒有第三方支付牌照，採取銀企直連的方式，通過分配給買賣雙方預設的虛擬賬號作爲結算賬號，可以滿足在交易期間符合監管規範，避免構成資金池的風險。
銀企直連的對接方式的不足之處就是要對接多家銀行，各個銀行的對接接口不同，支付通道的構建風格和思想也不同，造成技術對接進度緩慢，同時對於技術架構上需要綜合考慮各個銀行具體技術對接上的差異性，即使是一個參數也要深入探討研究，考慮不周在所難免。
現在來談談銀聯接口。銀聯接口其實和支付寶、微信支付等模式是幾乎完全等同的，都是採取訂單生成與支付的方式，對於客戶的操作來說，就和平時在電商上支付體驗一樣，引導式、點擊鏈接、確認並完成支付。隨後在技術層面上，電商平臺的後端服務器獲取到銀聯的訂單支付成功的回調通知，電商平臺修改訂單狀態，那麼完成了這筆訂單的支付。
那麼不足之處在哪裏呢？
首先，訂單模式對於原路退還的處理是將之前完成的訂單進行退款處理，需要結算模塊進行改造，結算單據其實是有兩條的（如保證金入金、保證金退還，業務數據是兩條，如此就要構建出N對1的數據結構）。
第二，要符合監管，那麼價款在平臺中存放的時間是需要計算滋生的利息，在價款轉出成功後追加支付的。那麼這種業務場景下訂單如何生成？需要深入探討。
第三，當競價成功後的保證金轉價款，訂單模式是否支持數據的同步呢？又要打個問號。
第四，銀聯大額支付有時間限制，T+1後到賬，那麼意向買方的競價資格是需要通過到賬時間計算的，如果項目在下架等待掛牌，資金實際已經支付完成但由於對賬的時間限制不能及時傳輸到賬消息呢？競價資格無法及時獲取，影響業務的進行和用戶的體驗。
當然還有很多訂單模式無法解決先有項目運營的結算流程，細節以後再說。
當然訂單模式依舊是適合大多數互聯網電商的支付結算流程的，但是互聯網的支付模式遇到了傳統企業，看來還是有相當長的磨合與改造週期。
那麼，你在工作中是否也遇到了類似的場景問題呢？歡迎留言。