4個方面,拆解交易平臺
要想理解梳理清楚交易平臺的模塊與要點,我們需要從哪些方面入手呢?筆者結合業務、風控、支付、結算等方面進行了說明。
上文我們說了支付的一些模塊和名詞定義,這篇文章說下交易平臺。
我將交易平臺簡單地分為:
- 業務管理
- 風控管理
- 支付管理(收銀臺+渠道管理)
- 結算管理
先看下一筆訂單交易支付時,簡版的時序是什么樣的?
一、業務端
以電商類收銀臺舉例,支付的上游是購物車模塊,訂單的對應關系是n個商品組對應一個業務訂單號。
業務單號:支付流水號=1:n
這種對應關系代表同一個業務單號可以在收銀臺進行多次支付。
舉個例子:
小A買東西時用微信支付失敗了,此支付流水號和微信訂單號是失敗的并且是終態不可再改變,業務訂單號也是失敗的但不是終態;
當訂單再次用支付寶支付成功時,該業務訂單狀態改為成功且為終態。
業務單號:支付流水號:渠道訂單號=1:n:n
這樣不會重復付款嗎?
會。簡化來說當支付成功信息沒有及時回送到業務端,導致業務端再次發起支付時,這種情況下業務端僅收到一次成功結果就會成功,第二筆支付成功的結果無論是否送達都不會被記錄,就產生了重復付款,這也是為什么在結算版塊,業務端和支付端會記兩次帳的原因。
那為什么業務端要不改變單號進行支付呢?
這個也是根據場景來的,并且會搭配定支付時效來進行組合使用。例如像日常速達類的15min,火車票/機票30min等,都是會有占庫存的情況,像服裝類的就很少使用同一個單號支付。
我們還以電商舉例:當購物車的商品點擊結算后,實際上會占用對應商品的庫存。取消單號的意味著需要先釋放庫存再占用庫存。如果業務單號不變,一方面可以減少庫存占用和讀取的壓力,特別是商品sku多,時效快的公司;另一方面可以通過時效增加客戶緊迫性引導支付。
二、風控模塊
目前我接觸到的風控相對較少,有相關經驗的歡迎分享。
其中不是所有公司都設置風控版塊,一般互金公司和大公司會設置風控部門,小型的公司一般是并在it部門內。在交易的時候,如果公司沒有能力做風控,就可以將相關風控的職責轉嫁給支付渠道,風險控制也是三方渠道提供的服務之一,像支付寶和微信就是渠道自行承擔交易風險。
交易風控一般分為三個板塊:
1. 事前策略
按照 《中華人民共和國網絡安全法》發規定的要求,對用戶進行一些信息獲取,根據已有信息進行策略配置、標簽處理、黑白名單、規則路由等方式來阻擋風險用戶。
2. 事中監控
交易發生時,系統根據事前策略進行規則分析,對訂單信息、用戶信息分析來判斷用戶的風險系數。根據系數進行對應的拒絕、掛起、通過等操作。
3. 事后處理
事后案件最常見的有兩個來源
- 通常第一例風險用戶未被發現當后續該用戶再次交易時會把之前的用戶訂單拉出來比對。此時案件小組就需要進行參與人工處理,包括對應的原訂單止損、現有訂單攔截、案件分析結果及策略組完善規則等。
- 當被害用戶通過發卡行、媒體渠道、交易平臺進行投訴,也是事后風控的處理范疇。
三、支付渠道
一個交易平臺渠道的接入和使用的流程如下:
1. 支付渠道挑選
分析現有業務場景,再判斷需要的交易模式。不必擔心沒有相關支付產品,因為可以應勢而生。舉個例子,國家嚴查二清,渠道就推出了空中分賬產品。
根據自身的優先級挑選渠道,一般接入前能看到的有:渠道的背景、支持的產品、開出的限額、費率、支持對賬對款的模式、結算周期等。但近幾年 《銀行卡收單業務管理辦法》嚴格實施,讓各家支付公司從拼價格到拼服務,使得支付的服務向著標準化方向飛速發展。
2. 支付渠道的接入
渠道接入開發時,一般區分為以下兩個模塊:
- 交易模板:交易模塊一般指代收、代付等。
- 對賬模塊:對賬一般區分為對交易、對手續費、對資金(支持資金自動結算及賬戶余額查詢時系統可以自行核對)。
3. 支付渠道的使用
當渠道接入完成后,就需要切量了,此時需要根據渠道的限額、簽約產品、費用等情況先做備份處理,根據自家路由的規則配置放量。
一般試運營2周左右需要進行第一次渠道試運營報告,報告內容為:渠道成功率、結算情況、服務時效、報錯碼準確性等板塊進行打分,結合現有渠道的評分情況進行路由策略調整及優化。
四、結算管理
當交易支付完成后,實際上整個訂單在系統內并沒有結束,結算才剛剛開始。
結算簡單的說就是交易完成后進行的資金結算,結算常見詞匯如下:
1. 資金結算周期
實時結算:資金實時到賬,這種結算方式一般是支付渠道墊資行為,所以相對費率比較高。
D+1:自然日+1天結算,就是通常理解的第二天結算
T+1:工作日+1天結算,節假期、周末不結算
T+n:工作日+n天結算
2. 結算方式
全額結算:指資金結算的時候不扣除手續費,手續費從另外一個賬戶結算或者按照一定周期獨立扣除
軋差結算:指資金結算的時候先扣除手續費后進行剩余金額結算
3. 對賬管理
通常財務在進行結算的時候使用的是:賬實核對和賬賬核對。
賬實核對:渠道賬單+渠道資金核對,對賬時首先要確認對方入賬的資金和對方給到的賬單是一致的。
賬賬核對:業務系統賬單+交易系統(支付收銀臺)賬單+渠道賬單,此時有任何一個版塊的內容有錯誤都會影響對賬結果。
4. 對賬差異
將對賬異常訂單全部放入異常池中,根據以下兩種表現形式進行對應處理:
長款:
- 需要退還用戶,通過調用原渠道的退款或代發接口將資金退回。
- 需要補單,根據原訂單 號進行關聯單號補單處理。
短款:
秉承誰欠錢找誰要的原則。比如是渠道錯誤,那資損由渠道承擔。系統錯誤內部承擔進行攔截訂單止損等。
其實本篇文章中很多東西還可以更細,比如路由策略、報錯碼管理、對賬管理、對賬異常池,但我計劃是把自己的支付框架先搭起來后再寫細節各個功能設計,所以文章看起來框架感較強,我會在后續文章中繼續細化版塊內容。
從業三年半,面對人生第一個轉型及瓶頸,掙扎向前!
歡迎同行伙伴留言:你曾從事支付幾年了?現在在做什么?
本文由 @華山論踐 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議
分享很棒!學習了
從事支付4年,目前是渠道側的支付產品
關注了。。。希望更不要斷更