- 定義: 支付系統伴隨着電子商務的出現而發展,主要表現爲具有一定的業務獨立性,爲各類經營活動提供在線收付款交易以及資金管理的功能
- 基礎必備: 因爲央行媽媽的規定,人民幣交易僅限於銀行和持牌支付的第三方機構,所以支付系統需要具有:
- 統一封裝的交易接口
- 根據業務系統設置的資金分配規則;比如一筆訂單涉及到多個收款方或者付款方時,完成交易清算和渠道劃付
- 賬務數據記錄功能
- 支付系統架構設計
- 業務層:根據不同的場景提供收付款界面以及處理業務系統的交易請求
- 收銀臺
- 他這裏提到了————支付渠道的服務模型,進而引申除了服務模型
- 服務模型是指商戶可以使用的交易形式,支付產品(快捷,網銀,代扣,pos),簽約方式,階段周曦以及費率等核心問題的綜合體;
- 交易系統 交易系統本身是作爲支付系統外部處理業務邏輯的外圍系統
- 職責: 對接上層的業務系統,其次將支付系統的支付能力抽象出來,對外提供各類交易方式,例如下單,支付,修改金額,確認結算,退款,關閉以及查詢等能力,最後需要對各種交易類型進行定義,例如擔保交易,及時到賬,充值,提現等類型;
- 交易系統的場景
- 下單: 生成交易訂單,確定交易參與
- 退款: 針對已支付的訂單進行退款,退款金額不得大於實際支付金額,積分退回原賬戶,同時針對針對退款交易類型生成退款交易訂單號,關聯入款訂單
- 修改金額:
- 查詢
- 通知: 通知上層業務系統交易狀態
- 算費:手續費
- 交易系統的交易類型
- 即時到賬交易
- 擔保收單交易
- 收單退款交易
- 普通轉賬交易
- 合併支付交易
- 下定交易: 定金模式
- 提現交易
- 凍結解凍: 在交易前通過凍結能力對用戶部分資金凍結,保證交易正常進行,也可以針對某些原因保證用戶資金安全如 賬戶被盜 司法案件
- 充值
- 交易系統的支付形式
- 單筆支付交易
- 合併支付交易
- 業務類型
- 收單交易: 支付入款,收款和付款爲2個角色
- 充值交易:支付入款,收款和付款爲1個角色,由外部賬戶轉到內部賬戶
- 出款交易: 和充值交易相反
- 退款交易:收單交易的反向流程
- 會員系統: 是支付系統的賬戶體系;他保存了客戶在支付系統內部賬號的實體信息,爲客戶建立了統一且唯一的會員基本信息和關係信息視圖,會員可以配置一定的業務參數,如接口週期,接口權限,支付方式 但是大部分的互聯網公司一般都是直接對接第三方的渠道支付,沒有出現獨立的賬戶體系
- 收銀臺
- 支付層:通過支付渠道處理完成資金的收付款,記錄參與交易賬戶的資金流轉情況並按照預定規則信息賬戶所屬資金進行拆分和合並;
- 支付核心
- 職責:通過支付核心與後端清結算,灰機,賬戶等系統的統一協作,讓前端支付產品可以更關注產品本身的邏輯。通過標準化的支付指令定義,統一前端支付請求接口,提供各類產品使用的基礎支付服務;
- 場景
- 支付服務:負責對後端支付系統的接口進行業務包裝,同時實現使用多個支付方式進行組合支付的功能
- 支付服務流程:對各支付類型的支付服務流程進行定義,具體定義爲充值,提現,轉賬,退款等原子事務,並實現對基礎服務的流程編排;
- 支付指令:發起訂單後,通過協議和協議明細項加工得出的支付指令,需包含後續操作的全部信息
- 支付協議:將產品的各流程進行支付編碼的定義和字段規定,起規範作用
- 核心架構 【圖片】
- 賬務核心
- 根據業務系統的要求設計相匹配的賬戶類型,管理各類賬戶,記錄賬戶資金變動,同時按照公司的財會數據進行對賬比對
- 清算核心
- 負責維護客戶交易時的清分,結算規則,並按照已配置的規則完成交易資金的清分與結算操作;
- 支付核心
- 業務層:根據不同的場景提供收付款界面以及處理業務系統的交易請求
- 按機構分類: 按照交易主體來源機構的的不同
- 支付賬戶:由支付機構爲客戶開立,用戶電子商務交易的收付款結算;按照2015年的非銀行機構網絡支付業務管理辦法
- I類賬戶以非面對面方式,至少通過一個外部渠道驗證身份,爲其開立的支付賬戶,累計金額不得1000元,II類賬戶不得超過10萬元,III 類賬戶賬戶資不超過20萬元
- 銀行賬戶: 由銀行業金融機構爲客戶設計,除了用戶支付結算以外,還具有保值增值的目的。銀行賬戶的標誌是銀行卡,同業它也分成三類賬戶
- I類賬戶櫃檯現場覈驗,擁有最全面的賬戶功能,每個人在同一家商業銀行僅可開通一個I類賬戶,II類賬戶和III 類賬戶都可以通過在線身份校驗開通,不過權限有所不同;
- 目前支付系統對接的所有產品,都是基於銀行賬戶進行資金處理的;
- 支付賬戶:由支付機構爲客戶開立,用戶電子商務交易的收付款結算;按照2015年的非銀行機構網絡支付業務管理辦法
- 按產品分類
- 網銀/網關支付 : 分爲網銀支付和企業網銀支付
- 快捷支付: 依賴於支付賬戶的一種支付方式,通過綁定個人支付賬戶及銀行卡,每次支付時僅需校對支付密碼即可完成支付, 二維碼支付也是一種快捷支付
- 代扣: 在獲取用戶授信後,無需用戶確認,直接扣款。 如水電費代繳,房貸扣款,免密支付
- 代付
- 按場景分類
- 線上:支付寶 微信 銀聯
- 線下: 掃碼付 (微信,支付寶 支持掃碼的各大商業銀行)
- 跨境: 爲境外商戶提供人民幣收款能力,爲境內和境外的商戶提供外幣的收款能力;
- 收銀臺支付方式選擇
- 收單(付款):通過各類支付凡是針對業務訂單發起付款
- 業務流程:【流程圖】
- 充值:對賬戶進行餘額充值;
- 業務流程【流程圖】
- 收單(付款):通過各類支付凡是針對業務訂單發起付款
- 組合支付
- 優惠支付
- 即基於支付系統的代金券,優惠券,紅包等營銷支付流程設計,本質上是基於賬戶做的影響支付體系
- 平臺側營銷賬戶:如優惠券 代金券等優惠賬戶應在平臺建立營銷賬戶 使用時從2個賬戶中進行扣減,
- 用戶側營銷賬戶:綁定用戶,通過領用紅包,優惠券則視爲默認開通對應營銷賬戶,賬戶增加,使用時進行賬戶扣減
- 營銷支付設計
- 基於業務端做營銷 : 在業務平臺直接對優惠券金額進行扣除
- 調用支付系統前,對優惠部分進行計算完成直接扣減,在調用支付系統,根據用戶實際支付金額生成訂單
- 基於支付端做營銷
- 平臺側: 將平臺的優惠補貼金額通過內部戶形式存在賬戶系統中,等用戶發起支付時,平臺計算總金額,優惠金額,根據總金額生成交易訂單,根據總金額的構成生成支付訂單
- 用戶側:比較適用於部分營銷產品擁有較強的用戶屬性,如用戶積分,,需要根據其業務單獨開設補貼賬戶,支付時根據營銷賬戶+其他支付方式進行組合,一筆付款付多個付款渠道;
- 基於業務端做營銷 : 在業務平臺直接對優惠券金額進行扣除
- 即基於支付系統的代金券,優惠券,紅包等營銷支付流程設計,本質上是基於賬戶做的影響支付體系
- 收單網關:
- 定義:是平臺方支付系統和用戶的外部網絡之間的接口,爲支付系統操作將外網傳輸的數據轉化成系統內部數據,同時負責將平臺業務系統的內部請求轉化成支付系統的內部數據。在支付平臺化後,所有外部系統需要通過統一的網關接口調用支付平臺,由網關進行一系列格式校驗,參數校驗,業務調用權限檢查後再進行向支付系統轉發
- 收單網關流程 【流程圖】
- 1業務系統構造請求信息
- 2業務系統發送請求信息
- 3支付系統處理請求信息
- 4支付系統返回信息:支付系統一般會以同步和異步2種方式返回業務數據,同步通知代表請求處理成功,而通知訂單處理狀態會以異步通知的新式主動回調用戶;
- 5業務系統處理響應信息
- 接口定義: 業務系統和支付系統之間通過https協議來進行通信,接口以url的新式提供並使用post方式請求;
- 接口設計說明:
- 接口基本請求 需要定義接口的業務參數
- 服務請求接口 根據支付系統本身的能力抽象出的業務接口,給外部業務方進行調用
- 及時到賬交易網關接口
- 擔保交易網關接口
- 結算分賬網關接口
- 繼續支付網關接口
- 退款網關接口
- 交易查詢網關接口
- 通知接口
- 交易狀態變更通知
- 交易服務
- 交易服務的作用:將支付系統的支付能力抽象出來,提供各類交易服務;基於收款方的交易鏈業務路進行對接各類業務方的需求
- 擔保收單交易
- 第一個環節爲下單環節,參與交易雙方付款人是用戶,收款人是在支付系統內部開通的一個擔保賬戶,在發起結算時,參與交易雙方信息2條收付款人記錄,最終資金以內部轉賬新式轉給實際收款的商戶賬戶。
- 及時到賬交易 【流程圖】
- 充值交易: 用戶對賬戶餘額進行充值,一般運用於虛擬比,錢包餘額等產品
- 出款交易【流程圖】
- 出款到賬戶,目前市面常見用戶場景是提現到支付寶或者微信
- 出款到卡;和出款到賬戶差不多,不過一般出款到卡需要走對應銀行卡的出款渠道;
- 會員基本信息
- 會員開戶流程
- 支付前置
- 定義:是指包裝後端支付核心系統的接口,包裝後對外提供的服務包括餘額,現金,網銀,快捷支付,出款及相關訂單的退款和控制接口,另提供後臺系統調用的服務包括確定性入款,登賬,凍結解凍等,所有的支付行爲都會以業務員支付訂單的形式落地。 用戶在前端發起一次支付行爲後,交易系統基於原始的交易訂單,對應生產一條付款訂單,通過這筆付款訂單和支付核心進行交互;
- 業務產品碼: 對應各類支付請求到達支付前置系統後,前置系統根據業務產品碼和本身的支付業務配置關係,生產對應的業務支付訂單。
- 支付產品碼: 由於即時到賬擔保交易在業務規則上不同,但是支付渠道都會判斷爲支付,這種情況下都是支付,但是業務產品碼不同,因此支付產品碼 一個支付產品編碼代表一個支付協議
- 支付引擎
- 類別: 充值 提現 轉賬 退款
- 指令:指令即支付核心的工單號,前置的每筆支付訂單對應着一筆甚至躲避指令;
- 舉例:用戶在電商網站購買一般價格100元,通過支付寶付款,訂單類型爲擔保交易,在交易核心生產一筆擔保支付的訂單,調用支付核心系統支付時,支付系統判斷業務調研方已經配置了 [收單支付協議],且根據對應協議生產一筆業務類型爲第三方支付的支付訂單。基於此訂單生成了第一條充值的支付指令; 該指令在根據支付類型去調用服務流程時,先通過流程編排先執行外部支付渠道,確認充值的錢收進平臺了,然後生成 清算指令,給用戶發出付款成功指令,最後生成賬務指令並調用賬務核心,執行內部財務入賬;
- 支付服務流程
- 定義支付指定的執行流程,將支付拆分成原子級的支付類型,並對支付類型的流程進行編排。一般來說充值 提現 轉賬 退款能夠通過自定義組合實現所有的支付行爲;
- 風控 : 風險交易防範與控制的簡稱
- 是否設置風控模塊,需要評價投入產出比。只有當系統內積累了一定量的風險交易數據,並且已經產品實際經濟損失情況下,則考慮在支付系統內設置風控模塊
- 業務規則:
- 餘額賬戶首次充值時,需進行賬戶實名認證,設置支付密碼
- 變更餘額賬戶和提現銀行卡時,必須進行已綁定銀行卡校驗和新綁定銀行卡校驗
- 風控模型: 是指依賴可獲取的交易信息和客戶信息,抽象出風險交易特徵,可用於抽象風險交易特徵的主要有三類:
- 交易信息: 交易類型,交易金額,交易時間,支付賬戶等信息
- 客戶信息:設備類型 設備編號 用戶定位信息,用戶手機號 手機號歸屬地;
- 歷史數據: 在平臺發生的歷史交易及其交易信息和用戶信息
- 風控運營
- 對於風控模塊識別出的風險交易,根據其危害程度的不同,分爲事前攔截和事中審覈
- 內部中控臺
- 支付核心需要爲內部的運營,財務,管理層提供查看交易數據的可視化管理網站,如交易總額,訂單轉化率,支付渠道佔比等可視化數據圖表;
- 報表下載:
- 交易報表: 交易流水報表
- 結算報表: 支付系統的清算核心對賬戶資金進行結算時,生產結算報表,供運營或者財務進行付款前或者作爲付款憑證進行後續審覈查賬
- 財務報表 按照公司財務報表編制的需求生產財務報表
- 權限控制,因爲交易數據屬於敏感信息,內部中控臺需要作出特定的限定,並且關鍵個人隱私數據需要脫敏
- 交易監控
- 支付系統的穩定性十分重要
- 監控支付渠道的交易穩定性,支付系統對接的外部渠道,監控支付渠道的接口響應市場和成功交易佔比這2個重要支付
- 監控支付核心處理交易的穩定性:主要監控支付核心處理交易的平均時間,保證支付系統的穩定信息
- 交易監控中發現的異常警告,以短信,郵件等方式及時通知負責人員處理交易異常信息;
- 支付系統的穩定性十分重要
- 借貸記賬法 有借必有貸,借貸必相等; 資產=負債+所有者權益
- 實現方式: 在賬務核心設計時,應重點對每一條賬務流水,並在多個相關聯賬戶中等值記錄資金的增加和減少情況;
- 在將已記錄的金額增加減少轉化成會計科目的借貸符號;
- 清結算規則:
- 清分規則:是基於一筆交易的商品,金額,買賣雙方等要素配置的一套資金劃分規則。通俗來說就是需要明確在一筆訂單的業務形成中,設置好規則,將每個賬戶的應付賬款同步至結算中心;
- 結算規則: 一般是指客戶的交易資金結算週期;
- 清分: 清算核心用於維護各個系統同步過來的清分規則,清算核心根據每筆交易的信息,查詢匹配設置的清分規則
- 實時清分 清算核心接收到訂單交易信息後,立即按照交易信息匹配清分規則,並完成相關的資金劃分
- 舉例:用戶a通過銷售人員b在買家c出購買100元商品,用戶使用10元優惠券,實際通過支付寶支付90元,平臺對每筆交易收取5%手續費,銷售人員可以按每筆交易獲取20%的提成。
- 在該筆交易中心,平臺收取5元手續費,銷售人員獲取20元提成,由清算核心進行處理交易資金。 平臺的10元優惠券和用戶支付90元,由賬務核心進行處理。
- 異步清分
- 在交易完成後,不能立即確認該筆交易的參與資金清分的客戶需要事後再次更新交易信息,才能確認資金清分。 舉例如快遞交易
- 實時清分 清算核心接收到訂單交易信息後,立即按照交易信息匹配清分規則,並完成相關的資金劃分
- 結算
- 對有資金結算需求的賬戶,需要對該賬戶內的賬務記錄,進行對賬狀態和結算狀態的標記;
- 對於未對賬的賬戶記錄,不予以結算
- 清算核心在向結算賬戶進行結算付款時,需要爲支付系統輸出結算數據。支付系統的其他模塊負責將這些數據整理爲結算對賬單提供給結算賬戶所屬賬戶,供客戶確認總金額和每筆金額是否正確。