支付系統掃盲

本文大部分內容轉載自支付系統設計系列文章,在其中加入了一些個人的理解和經驗,僅供參考。

一、支付系統結構

圖1

上圖爲某支付系統的模塊結構圖,一般來說,支付主流程會涉及到如下模塊:

圖2

流程大致爲:

  1. 商戶側應用發起支付請求。注意,這個請求一般是從服務器端發起的。比如用戶在手機端提交“立即支付”按鈕後,商戶的服務器端會先生成訂單,然後請求支付網關執行支付。
  2. 支付請求被髮送到支付(API)網關上。網關對這個請求進行一些通用的處理,比如QPS1控制、驗籤等,然後根據支付請求的場景(網銀、快捷、外卡等),調用對應的支付產品。
  3. 支付產品對用戶請求進行預處理,包括執行參數校驗、根據支付路由尋找合適的支付通道、評估交易風險、生成訂單、調用通道落地執行支付、響應通道的結果並將交易結果通知到商戶側。
  4. 支付產品調用支付通道執行支付。這個請求並不是直接落地到通道上,而是通過支付通道前置來封裝,由支付通道前置來完成和通道的交付。 支付產品是按照可以提供的支付服務來設計的。
  5. 支付通道前置,負責和支付通道之間的通訊,調用支付通道接口完成最終的支付操作。

下面分別敘述各個模塊。

二、支付網關

支付網關是直接對接業務系統的接口,它本身並不執行任何支付相關的業務邏輯,它的主要功能是:

  1. API路由。在聚合支付場景下,當有多個支付產品可以提供支持時,使用支付網關可以讓接入方對接時無需考慮支付產品的部署問題。
  2. 接口安全: 熔斷、限流與隔離。 這對支付服務來說尤爲重要。

三、支付產品

即圖2中的“賬戶支付”、“外卡支付”等支付產品。其按照支付場景來爲業務方提供支付服務。這個模塊一般位於支付網關之後,支付渠道之前。它根據支付能力將不同的支付渠道封裝成統一的接口,通過支付網關來對外提供服務。其主要功能爲:

  1. 風控攔截: 風控是和支付產品有關,不同產品的風控措施、處理對策也是不同的,所以風控是在產品層實現。
  2. 支付路由: 路由也是和產品有關。不同產品路由策略也不同。
  3. 參數校驗: 這也是和支付產品相關的,不同的產品接口其參數也不同。
  4. 支付流程: 生成交易記錄、落地渠道執行支付、同步和異步通知等操作。

支付網關、支付產品的職責分工爲:

1.按照支付能力來劃分支付產品。
2.同一支付能力的公共支付流程,在支付產品中實現。 支付產品提供的是和渠道無關的、和支付能力流程相關的功能。
3.在各支付產品中,其和支付能力無關的公共功能,在支付網關上實現。

另外,身份驗證和驗籤功能既可能做在支付網關中,也可能做在支付產品中:

1.身份驗證: 確認付款方、收款方、渠道是否有執行當前操作的權限。 在哪一層實現取決於這些信息是否有提煉爲公共行爲。
2.驗籤: 對接口參數進行簽名並驗證其簽名。這是爲了避免接口被盜刷和篡改的必要手段。如果對各個接口採用統一的簽名規則,則可以在網關層實現。

支付產品分類

在不同的公司由於接入渠道和應用的差異,對支付產品分類略有不同。綜合支付場景和流程,支付產品可以分爲如下幾類:

圖3

下面分別介紹這些支付產品。

  1. 快捷支付
    用戶在完成綁卡之後(銀行接口會返回token,後續使用token來作爲支付憑證),在支付的時候,不需要再輸入卡或者身份信息,僅需要輸入支付密碼就可以完成支付。對於小額度的支付,甚至可以開通小額免密,直接完成支付。 這種支付方式不會打斷用戶的體驗,是目前主要的在線支付方式。一般快捷支付產品是通過封裝銀行或者第三方支付平臺提供的快捷支付接口或者代付接口來實現的。
  2. 網銀支付
    用戶在支付的時候,需要跳轉到銀行網銀頁面來完成支付。在網銀頁面,需要輸入用戶的卡號和身份信息。這種支付方式會中斷用戶當前的體驗,一般僅用於PC Web上的支付。 網銀支付是封裝銀行提供的網銀支付來實現。
  3. 協議支付
    協議支付也稱代收或者代扣,代收指渠道授權商戶可以從用戶的銀行賬戶中扣款,一般用於定期扣款,不用於日常消費。比如水電煤氣、有線電視費。協議支付是通過封裝銀行、第三方支付提供的代扣或者快捷接口來實現。
  4. 平臺支付
    使用微信、支付寶等第三方支付平臺來完成支付。使用時,一般需要用戶預先安裝支付平臺系統(手機上),註冊並登錄到第三方支付平臺,並且已經在該平臺上完成綁卡等操作(平臺在服務器側保留用戶的賬戶信息,比如身份證號,卡號,手機號)。 由於微信、支付寶已經被大量使用,用戶也產生對這些平臺的信任,平臺支付往往是電商公司的主要支付方式。但是這種方式相對不安全,需要向平臺暴露個人信息,一旦被竊取,資金就容易被盜走。
  5. 外卡支付
  6. 話費支付
  7. 虛幣支付
    不少公司會有自己的虛擬幣,比如京豆、Q幣等。這些虛幣也可以作爲一種支付方式。
  8. 賬戶支付
    也成爲餘額支付、零錢支付等。 指爲用戶建立本地賬戶, 支持充值,之後可以使用這個賬戶來完成支付。
  9. 信用支付
    如京東的白條,螞蟻花唄等,指使用信用賬戶進行透支,類似信用卡支付。
  10. 代付
    和代扣相反,代付是平臺將錢打給用戶。

支付產品需要提供的接口

一般來說,支付產品需要提供如下接口:

圖4

  1. 簽約和解約
    在快捷支付、代扣等產品中,用戶在使用前,需要先完成簽約。簽約可以在渠道側進行,一般第三方支付採用這種方式,當電商需要接入時,讓第三方給授權。 銀行和銀聯的簽約一般是在電商側進行, 電商側負責收集用戶的信息,調用銀行和銀聯的接口進行簽約。簽約後,後續的支付行爲就使用簽約號來進行,無需再輸入個人信息。 和簽約相對應,解約則是取消簽約關係。
  2. 支付
    支付是少不了的操作。 不同產品中支付行爲不一樣。快捷支付是在電商服務器上發起,請求渠道進行支付;網銀支付則是跳轉到銀行支付網關上進行; 而賬戶支付、虛幣支付,則是在本地進行的。
  3. 撤銷和退款
    有些渠道區分撤銷和退款,比如銀聯、農行等,撤銷指取消當天在渠道側未結算的交易; 而退款僅針對已經結算的交易。有些渠道則不作區分。
  4. 查詢簽約狀態
    對於需要簽約的交易,可以通過這個接口來查詢簽約狀態。
  5. 查詢訂單狀態
    通過這個接口來查詢支付清單狀態以及退款的訂單狀態。
  6. 預授權
    預授權交易用於受理方向持卡人的髮卡方確認交易許可。受理方將預估的消費金額作爲預授權金額,發送給持卡人的髮卡方。預授權在一定時間後會自動撤銷。
  7. 預授權撤銷
    對已成功的預授權交易,在結算前使用預授權撤銷交易,通知髮卡方取消付款承諾。預授權撤銷交易必須是對原始預授權交易或追加預授權交易最終承兌金額的全額撤銷。
  8. 預授權完成交易
    對已批准的預授權交易,用預授權完成做支付結算。
  9. 預授權完成撤銷
    預授權完成撤銷交易必須是對原始預授權完成交易的全額撤銷。預授權完成撤銷後的預授權仍然有效。
  10. 對賬
    通過FTP或者HTTP方式提供對賬文件供商戶側對賬。
  11. 餘額查詢
    查詢商戶的交易賬戶的餘額,避免由於餘額不足導致交易失敗。 注意,不是客戶的餘額。 當然,不是所有的銀行或者第三方支付都提供這個接口。

支付產品業務流程

上述操作,除了對賬、查單外,每個操作實現的主流程,一般會包括參數校驗,支付路由,生成訂單,風險評估,調用渠道服務,更新訂單和發送消息這7步,對於一些比較複雜的服務,還會涉及到異步同通知處理的步驟。

圖5

  1. 參數校驗
  2. 根據支付路由尋找合適的支付服務
    根據用戶選擇的支付方式確定用來完成該操作的合適的支付渠道。用戶指定的支付方式不一定是最終的執行支付的渠道。比如用戶選擇通過工行信用卡來執行支付,但是我們沒有實現和工行的對接,而是可以通過第三方支付,比如支付寶、微信支付、易寶支付,或者銀聯來完成。那如何選擇合適的支付渠道,就通過支付路由來實現。支付路由會綜合考慮收費、渠道的可用性等因素來選擇最優方案。
  3. 評估交易風險
    檢查本次交易是否有風險。風控接口返回三種結果:阻斷交易、增強驗證和放行交易。
    • 阻斷交易,說明該交易是高風險的,需要終止,不執行第5個步驟;
    • 增強驗證,說明該交易有一定的風險,需要確認下是不是用戶本人在操作。這可以通過發送短信驗證碼或者其他可以驗證用戶身份的方式來做校驗,驗證通過後,可以繼續執行該交易。
    • 放行交易,即本次交易是安全的,可以繼續往下走。
  4. 生成交易訂單
    將訂單信息持久化到數據庫中。
  5. 調用支付渠道提供的服務
    所有的支付服務都需要第三方通道來完成執行。一般銀行渠道的調用比較簡單,可以直接返回結果。一些第三方支付,支付寶,微信支付等,會通過異步接口來告知支付結果。
  6. 更新訂單
    對於同步返回的結果,需要在主線程中更新訂單的狀態,標記是支付成功還是失敗。對於異步返回的渠道,需要在異步程序中處理。
  7. 發送消息
    通過消息來通知相關係統關於訂單的變更。風控,信用BI等,都需要依賴這數據做準實時計算。
  8. 異步通知
    如上述流程,其中涉及到調用遠程接口,其延遲不可控。如果調用方一直阻塞等待,很容易超時。引入異步通知機制,可以讓調用方在主線程中儘快返回,通過異步線程來得到支付結果。對於通過異步來獲取支付結果的渠道接口,也需要對應的在異步通知中將結果返回給調用方。 異步通知需要調用方提供一個回調地址,一般以http或者https的方式。這就有技術風險,如果調用失敗,還需要重試。而重試不能過於頻繁,需要逐步拉大每一次重試的時間間隔。 在異步處理程序中,訂單根據處理結果變更狀態後,也要發消息通知相關係統。

支付產品的資金流

在支付產品的支付過程中,會觸發資金的流動,即資金從用戶個人賬戶上轉移到電商公司的賬戶,而轉移分爲同行轉移和跨行轉移:

  1. 同行轉移
    不管支付系統對接的是銀行直連還是銀聯,都是由目標銀行在內部系統完成兩個賬戶間的轉賬,即時完成。
  2. 跨行轉移
    如果支付系統沒有對接目標銀行,那麼需要走銀聯或者第三方支付。銀聯:銀聯發報文給兩個銀行,分別完成兩個賬戶上資金的增減,在用戶看來,資金已經到賬,但是實際上的資金流並沒有即時流動,銀聯會在半夜做清結算後處理這筆資金,即金融機構之間的清結算;第三方支付:對用戶來說,第三方支付與銀聯的表現沒有不同,但是在資金流方面,第三方支付一般在各個銀行都有託管資金,發生交易後,資金不會跨行流動,用戶A的資金流入第三方支付在銀行A的託管賬戶,而第三方支付在銀行B的託管賬戶會流出相應金額到用戶B在銀行B的賬戶。

四、支付路由

用戶在前端選擇一種支付方式,比如使用招行借記卡來支付後,系統不一定就是調用招行的接口來執行支付。支付寶、百付寶等第三方支付平臺以及銀聯等,都支持招行借記卡支付。 這種將支付方式落地到具體的支付接口的模塊,就是支付路由。

支付路由的職責

設計支付路由的目的是:

  1. 錢,省錢,省錢,這是支付路由選擇支付通道的最主要的規則。 哪個通道省錢,基本會優先考慮這個通道。
  2. 提升支付產品的QOS2。這體現在系統的可靠性、穩定性、性能和可用性上。通過屏蔽掉無法連接、不穩定、性能低的通道來提升這些指標。
  3. 支持營銷。通過優先選擇有優惠活動的通道,可以幫助業務提升付費客戶量。
  4. 降低運營成本。一個設計良好的支付路由,可以大大降低運營投入。

支付路由的架構設計如下:

圖6

支付路由並不會直接對接前端的支付產品或者後端的支付渠道,它是支付網關的一部分。

目前已知的路由規則(考慮因子)有如下這些:

圖7


  1. Query Per Second,每秒查詢率,描述特定的查詢服務器在規定時間內所處理流量的多少
  2. Quality of Service,指一個網絡利用各種基礎技術,爲指定的網絡通信提供更好的服務能力
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章