支付產品模組是按照支援場景來為業務放提供支付服務。這個模組一般位於支付閘道器之後，支付渠道之前。它根據支付能力將不同的
支付渠道封裝成統一的藉口，通過支付閘道器對外提供服務。所以，從微服務的角度，支付產品本身也是乙個**模式的微服務，它透
過支付閘道器響應業務放請求，進行一些統一處理後，分發到不同的支付渠道去執行，最後將執行結果做處理後，通過支付閘道器再迴轉
給業務方。
常見的幾種支付產品
1、快捷支付
使用者在完成繫結卡之後，在支付的時候，不再需要輸入卡號或者身份資訊，僅需要輸入支付密碼就可以完成支付。對於小額度的支付，
或者第三方支付平台提供的快捷支付介面或者代付介面來實現的。
2、網銀支付
使用者在支付的時候，需要跳轉到銀行頁面來完成支付。在網銀頁面，需要輸入使用者卡號和身份資訊，一般僅用於pc web上的支付。但
是這種使用者體驗不好。
3、協議支付
協議支付也稱代收或者代扣，代收指渠道授權商戶可以從使用者的銀行賬戶中扣款，一般用於定期扣款，不用於日常消費。比如水電煤氣
有線電視。協議支付是通過封裝銀行、第三方支付提供的代扣或者快捷介面來實現的
4、平台支付
支付方式
5、外卡支付
對於海外支付的需求，還需提供外卡支付支援。國內不少支付渠道都能支付外卡支付，如支付寶全球購等。直接對接paypal，也是目前使用
最多的外卡支付渠道
6、話費支付
對於有包月小額型別的支付，手機話費也是乙個不錯的選擇
7、虛幣支付
不少公司有自己的虛擬幣，這些也可以作為一種支付方式
8、賬戶支付
為使用者建立本地賬戶，支付充值，之後就可以使用該賬戶來完成支付
9、信用支付
如京東的白條、螞蟻花唄等，使用信用賬戶進行透支，類似信用卡支付
10、代付
和代扣相反，是指平台將錢打給使用者
模組功能
1、簽約和解約
在快捷支付、代扣等產品中，使用者在使用前，需要先完成簽約。簽約可以在渠道側進行，一般第三方支付採用這種方式，當電商需要接入時，
讓第三方給授權。銀行和銀聯的簽約一般是在電商側進行，電商側負責收集使用者的資訊，呼叫銀行和銀聯的介面進行簽約。簽約後，後續的支付
行為就可以使用簽約號來進行，無需輸入個人資訊。和簽約物件，解約則是取消簽約關係
2、支付
不同支付行為不一樣。快捷支付是在電商伺服器上發起，請求渠道進行支付；網銀支付則是跳轉到銀行支付閘道器上進行；
而賬戶支付、虛幣支付，則是在本地進行的
3、撤銷和退款
有些渠道區分撤銷和退款，比如銀聯、農行等，撤銷指取消當天在渠道側未結算的交易；而退款僅針對已經結算的交易。
4、查詢簽約狀態
對於需要簽約的交易，可以通過這個介面來查詢簽約狀態
5、查詢訂單狀態
通過該介面查詢支付清單字型以及退款的訂單狀態
6、預授權
預授權交易用於受理放心持卡人的發卡方確認交易許可。受理方將預估的消費金額作為預授權金額，傳送給持卡人的發卡方
7、授權信撤銷
對已成功的預授信交易，在結算前使用預授權撤銷交易，通知發卡方取消付款承諾。預授信撤銷交易必須是對原始預授權交易或追加
預授權交易最終承兌金額的全額撤銷
8、對賬
通過ftp或者http方式提供對賬檔案供商戶側對賬
9、餘額差
查詢商戶的交易賬戶的餘額
業務流程
除了對賬、查單外，每個操作實現的主流程，一般包括引數校驗、支付路由、生成訂單、風險評估、呼叫渠道服務、更新訂單和傳送資訊
對於一些比較複雜的服務，還會涉及到非同步通知處理的步驟
1、執行引數校驗
所有的支付操作，都需要對輸入執行引數校驗，避免介面受到攻擊
1-1、驗證輸入引數中各字段的有效性、比如使用者id、商戶id、**、返回位址等引數
1-2、驗證賬號狀態。交易主體、交易對手等賬號的狀態是處於可交易的狀態
下單時間和支付時間是否超過預定的間隔
1-4、驗證簽名。簽名是為了防止支付介面被偽造。一般簽名是使用分給商戶的key來對輸入引數拼接成的字串做md5 hash 或者rsa
加密，然後作為乙個引數隨其他引數一起提交到伺服器端。
2、根據支付路由尋找合適的支付服務
根據使用者選擇的支付方式確定用來完成該操作的合適支付渠道。使用者指定的支付方式不一定是最終的執行支付的渠道。比如使用者
路由會綜合考慮收費、渠道的可用性等因素來選擇最優方案
3、評估交易風險
檢查本次交易是否有風險。風控介面返回三種結果：阻斷交易、增強驗證和放行交易
3-1、阻斷交易 說明該交易是高風險需要終止
3-2、增強驗證。說明交易有一定的風險，需要確認是不是使用者本人在操作。可以通過傳送簡訊驗證碼或者其他驗證
使用者身份的方式來做校驗，驗證通過之後，可以繼續執行該交易
3-3、放行交易，即本次交易是安全的，可以繼續往下執行
4、生成交易訂單
將訂單資訊持久化到資料庫中。當訪問壓力大的時候，資料庫寫入會成為乙個瓶頸
5、呼叫支付渠道提供的服務
所有的支付服務都需要第三方通道來完成執行。一般銀行渠道的呼叫比較簡單，可以直接返回結果。一些第三方支付平台、一般會通過非同步介面
通知支付結果
6、更新訂單
對於同步返回的結果，需要在主線程中更新訂單的狀態，標記為支付成功還是失敗。對於非同步返回的渠道，需要在非同步程式中處理
7、傳送訊息
通過訊息來通過相關系統關於訂單的變更
8、非同步通知
上訴流程中，涉及到呼叫遠端介面，其延遲不可控。如果呼叫方一直阻塞等待，很容易超時。引入非同步通知機制，可以讓呼叫方在主線程
中盡快返回，通過非同步執行緒來得到支付結果。對於通過非同步來獲取支付結果的渠道介面，也需要對應的在非同步通知中將結果返回給呼叫方。
非同步通知需要呼叫方提供乙個**位址，一般以http或者https方式。如果呼叫失敗，還需要重試，而重試不能過於頻繁，需要逐步拉大
每次重試的時間間隔
支付系統架構
大部分公司，只要想賺錢，就得上支付系統，讓使用者或者客戶有地方交錢。當然，公司發展的不同階段，對支付系統的定位和架構也不同。整體上來說，我們可以把乙個公司的支付系統發展分為三個階段 支付系統 支付作為乙個 封閉 的 獨立的應用系統，為各系統提供支付功能支援。一般來說，這個系統僅限於為公司內部的業務提...
一文讀懂 完整的支付系統整體架構！
支付產品模組是按照支付場景來為業務方提供支付服務。這個模組一般位於支付閘道器之後，支付渠道之前。它根據支付能力將不同的支付渠道封裝成統一的介面，通過支付閘道器來對外提供服務。所以，從微服務的角度，支付產品本身也是乙個 模式的微服務，它透過支付閘道器響應業務方請求，進行一些統一處理後，分發到不同的支付...
支付公司系統架構概述
2.後台系統 每個前置系統都會對應不同後台系統。用來處理一些邏輯。3.交易引擎 支付閘道器 支付公司會有乙個統一的交易引擎來處理支付請求。對請求做一些處理，如核實風控資訊。賬戶訊息等，然後根據使用者選擇的資金平台，呼叫不同系統。如選擇了銀行卡快捷支付，則銀行閘道器 支付路由會選擇適合的通道完成交易。...