《創新者的解答》給出兩種產品架構，分別是整合型的交互式產品架構，和分包型的模塊化產品架構。在交互性產品架構中，業務系統將承擔更多的責任，獨立的串聯模塊，在創新產品中可以快速迭代，比較適用。在模塊化產品架構中，業務系統的各個功能被分散到各個模塊，模塊做一些標準化的能力，提供同樣的服務給到更多的業務產品。在產品成熟期中，產品模塊化對人員的要求會更低，通過接口來實現功能的串聯，同時可以通過復用一些功能，提升整體的產品工作效率，保障產品質量，但這必須依靠很好的業務架構和組織架構保障溝通效率，否則上下遊會存在很多的分歧。

4.1.1 交易結構設計

在設計產品時，首先我們需要知道參與方是誰，各個參與方之間的關系如何，理解瞭這塊也就理解瞭交易結構。對於信貸產品而言，最重要的就是信息流、資金流和法律文件流。圖4-1是互聯網信用支付產品最簡單的交易結構，參與方分別是用戶、小貸和商戶。在這個基礎上，目前市面上已衍生出很多復雜的結構，比如出資方會有聯合貸和助貸的模式，增信方也有保險公司和擔保公司的參與。

圖4-1 信用支付交易結構

4.1.2 業務系統架構

不管我們是否有無系統，系統是否復雜，我們心中必須有一張大圖，才可以對全局有所瞭解，這張大圖就是業務架構圖。業務架構整體有以下幾個特點： 1. 業務架構服務於業務，會隨著業務的發展而不斷調整。 2. 業務架構既要兼容過去的問題，更要解決現在的問題，還能適度解決未來的問題。 3. 業務架構是三維的，橫向是平級的關系，縱向是上下遊的關系，同時每個模塊還會細拆功能模塊。 4. 業務架構圖是靜態，但是業務架構是動態的，不同的業務場景會調用不同的業務模塊。 5. 理想的系統邊界設計會跟業務架構保持一致，理想的組織人員配置會跟業務架構保持一致，雖然現實上很難完全匹配。

圖4-2 信用支付產品架構

4.1.3 信息流

信息流是系統交互的方式，理解瞭信息流，我們就更好的清楚業務實現的細節。根據上圖中，我們會把信息流分成授信、支付、還款、賬單分期、退款、註銷等幾大環節。本文重點還是在於實現層面，主要以圖示來展示。

4.1.3.1 授信

授信可分為C端授信和B端授信。我們通常比較熟悉的都是C端授信，即用戶在經過信用風險審批之後決策用戶是否可用該產品以及用戶的授信額度。

圖4-3信用支付授信流程

圖4-3主要是用戶視角的各個環節。圖4-4主要是系統之間的交互，更偏產品實現層面。

圖4-4 信用支付授信交互

不同於現金貸，C端用戶授信完成不會立刻推送到機構去做授信，而是先讓用戶正常使用一段時間後，挑選比較合適的資金方去做出表授信。這個資金方可以是聯合貸資金方，也可以是信托資金，也可以是銀行助貸資金。這樣做的好處在於，C端的授信不用完全依賴於B端，同時有使用習慣的用戶會更活躍，推送到資金方後也會產生更多的金融價值。

圖4-5 信用支付授信出表交互

4.1.3.2 交易

用戶在收銀臺上選擇信用支付產品並發生支付行為，可以是普通支付，也可以是交易分期，具體的交互可參考圖4-6。

圖4-6 信用支付交易交互

4.1.3.3 還款

信用支付產品的還款類型較多，不同還款方式的交互不一致，比如主動還款跟代扣還款就是兩套流程，圖4-7以主動還款為例。

付款方式/結清方式	全額還款	分期還款	延期還款	取現還款	分期提前結清	最低還款
主動還款	✔️	✔️	✔️	✔️	✔️	✔️
代扣還款	✔️					✔️
朋友幫還	✔️
對公還款	✔️				✔️

圖4-7 信用支付主動還款流程

4.1.3.4 賬單分期

賬單分期可以理解成是一種虛擬還款，它會結清當期賬單同時生成新的賬單，不同於還款，賬單分期不會產生資金流。

圖4-8 信用支付賬單分期流程

4.1.3.5 退貨退款

一旦在商戶側發生退貨，那麼在支付側就會發起退款，退款的要求是原卡進出。具體的流程如下：

圖4-9 信用支付退款流程

退款的沖銷邏輯比較復雜，用戶往往很難理解。所以需要花一些時間好好給用戶做解釋。

4.1.3.6 註銷

一旦用戶不想使用信用支付產品，我們就需要提供一種註銷的功能。

圖4-10 信用支付註銷流程

4.1.4 資金流

作為一個金融產品，資金流是非常重要的，它可以很清晰說明財務模型，好的財務模型是業務可持續發展不可或缺的一部分。一般而言，財務同學會非常關註這一塊內容，而在我們啟動產品的早期，我們必須要把資金模型給財務同學講清楚才可以動手開工建設產品。

我們的資金模式有純小貸、小貸-銀行聯合貸模式、信托助貸模式和純銀行助貸模式。下述以小貸-銀行聯合貸模式為例：

圖4-11 信用支付的聯合貸模式的資金流圖