引言
前一篇文章中，我們有了一些重要的支付概念，本篇我們先建立領域模型（也稱業務模型），技術是服務於業務的，開發人員都明白爲什麼我這裏要強調這個，業務沒搞明白，吭哧吭哧的開發，多半被項目經理唾沫淹死。
1、業務關係
- 商戶需要在第三方支付平臺註冊，並開通相關的代付、代扣協議。
- 用戶需要先操作銀行卡簽約，簽約完成才能進行後續的支付、查詢、退款操作。
- 商戶作爲中間層處理，也需要有用戶的幾種基本操作。
- 商戶還需完成和第三方支付平臺的對賬，通常都是以天爲單位進行對賬。
- 對賬無誤，則當日資金結算完畢。
疑問解答：爲什麼以天爲單位對賬
答：對賬以月爲單位，粒度太大，風險也太大，排查起來困難；以小時爲單位，粒度太小，不易控制，增加系統複雜性；以天爲單位，第二天統計第一天的數據，時間充分，風險易控。
2、支付流程
- 用戶向商戶發起支付請求；
- 商戶驗證用戶銀行卡簽約是否成功，如是，則向對應的支付通道發起代扣（需要加密）；
- 第三方支付平臺收到請求，會校驗商戶信息等，校驗成功，則發起扣款，並同時返回同步結果；
- 銀行異步通知第三方支付，第三方支付將支付狀態更新，並異步通知商戶，商戶再告知用戶支付結果。
疑問解答：
- 爲什麼有同步結果和異步結果
答：從用戶發起支付請求：用戶——商戶——第三方支付——銀行，處理成功響應：銀行——第三方支付——商戶——用戶。支付處理的流程複雜，調用鏈路長，爲了不必要的等待，提高處理效率，支付系統中多使用異步機制。同步返回的是受理結果，異步返回的是處理結果。 - 爲什麼參數需要加密
爲了保證數據的安全性，事實上，不僅僅是請求的參數進行了加密，商戶請求第三方支付平臺時候，第三方支付平臺也需要校驗商戶服務器的IP是否在白名單中，異步回調的時候，商戶也需要驗證消息的來源是否是第三方支付平臺的服務器IP發過來的。
3、模塊劃分
3.1、用戶模塊
用戶需要進行銀行卡簽約，簽約需要驗證四要素（姓名、身份證、銀行卡、手機號）是否一致。銀行卡簽約成功後，在一定時間內是不需要重新簽約的，除非用戶解綁銀行卡，否則後續支付和退款中不需要重新簽約。
疑問解答：爲什麼是一定的時間
答：因爲時間長了，用戶可能換卡了，可能改手機號了，這些都會導致銀行卡簽約無效。
3.2、支付模塊
支付模塊主要是支付、查詢、退款的操作，涉及虛擬賬戶、支付流水、退款流水的日誌記錄等。設計要點：1. 接口的冪等性，2. 交易結果的正確性，3. 日誌的完善性。
疑問解答：這裏的日誌完善性是指什麼
答：前面兩條相信大家不會有疑問，日誌的作用相信大家也知道：肩負着問題定位和分析的重任。但是在交易中，日誌還肩負着交易跟蹤的重任，能在與第三方支付平臺扯皮時快速的扔出憑證，完善的日誌系統交付給運營使用後，是不是感覺離正常下班又早了一步！
3.3、對賬模塊
對賬模塊主要負責定時的將前一天的支付流水和退款流水彙總，生成彙總結果，然後進行比對，確保各方記錄一致。
對賬標準：
- 支付流水和退款流水的彙總金額和商戶虛擬賬戶中的金額變化是否一致。
- 商戶虛擬賬戶中的金額和商戶在第三方支付賬戶的金額是否一致。
- 財務通過系統彙總的金額和第三方支付明細彙總金額是否一致。
結束語
本來這篇準備講講數據庫表設計的，但是又感覺不妥，畢竟能看到這篇文章的，不僅僅是成熟的支付開發者，更多的是新晉支付開發者，因此，還是先列出了領域模型，通過這兩篇支付掃盲，後面再看錶結構設計應該更容易了。