上一篇拆解了四方模型和三方模型的角色結構、資金流向、費用差異；這些概念如果只停在「知道」的層次，對工程師來說價值有限，重要的是理解這兩個模型如何具體影響要寫的程式碼。

本文接續上一篇，說明 API 整合、對帳邏輯、狀態機設計、Chargeback 處理這四個工程面向的差異，最後整理面試中最常見的問法和建議的回答方向。

API 整合：不要假設一致性

四方的 Visa 和三方的 Amex，授權 API 長得不相同：

 1// 錯誤做法：針對每家寫死邏輯
 2if (cardType == "VISA") {
 3    var request = new VisaAuthRequest { ... };
 4    // Visa 特定欄位...
 5} else if (cardType == "AMEX") {
 6    var request = new AmexAuthRequest { ... };
 7    // Amex 完全不同的欄位...
 8}
 9
10// 正確做法：抽象 Gateway 介面
11public interface IPaymentGateway {
12    Task<AuthResult> AuthorizeAsync(AuthRequest request);
13    Task<CaptureResult> CaptureAsync(string authCode, decimal amount);
14    Task<RefundResult> RefundAsync(string transactionId, decimal amount);
15    Task<VoidResult> VoidAsync(string authCode);
16}
17
18public class VisaGateway : IPaymentGateway { ... }
19public class AmexGateway : IPaymentGateway { ... }
20public class TapPayGateway : IPaymentGateway { ... }  // 本地閉環

這個介面抽象讓你日後新增支付方式時，只需要新增一個實作類別，不動核心邏輯。實務上通常會再搭配一個簡單的工廠（Factory）依卡種或商家設定選擇對應的實作：

1public class PaymentGatewayFactory
2{
3    private readonly Dictionary<string, IPaymentGateway> _gateways;
4
5    public IPaymentGateway Resolve(string cardType) =>
6        _gateways.TryGetValue(cardType, out var gateway)
7            ? gateway
8            : throw new NotSupportedException($"不支援的卡別：{cardType}");
9}

呼叫端只需要跟 IPaymentGateway 介面互動，不需要知道底層走的是四方還是三方模型。

對帳邏輯的差異

四方模型的對帳需要核對三本帳：

  • 系統的訂單帳（orders 表）
  • Acquirer 的結算報表（含 Interchange 拆分）
  • 公司銀行帳（實際入帳金額）

由於 Interchange 的存在，商家拿到的金額 ≠ 交易金額，對帳系統要能算出正確的預期入帳金額再比對；以一筆 NT$1,000 的 Visa 交易為例，對帳系統要先算出「扣除 Interchange、Network fee、Acquirer Markup 後的預期淨額」，再和實際入帳金額比對，任何一段費用算錯都會產生差異單。

三方模型的對帳相對簡單：

  • 系統的訂單帳
  • Amex/電支的結算報表

費用扣法更直觀，一份報表就能完成對帳，因為沒有多方拆分的費用結構，商家只需要核對「訂單金額 − 平台手續費 = 實收淨額」這一條公式就好。

這個差異直接反映在對帳系統的複雜度上：如果商家同時支援 Visa/Mastercard 和 Amex/電子支付，對帳系統要能區分不同閘道的費用結構，不能用同一套公式套用到所有交易上。

具體數字對照

以同樣一筆 NT$1,000 的交易為例，兩種模型的對帳計算過程差異明顯。

四方模型（Visa，MDR 1.5%）：

訂單金額：NT$1,000
  − Interchange fee（約 NT$10，付給 Issuer）
  − Network fee（約 NT$2，付給 Visa）
  − Acquirer Markup（約 NT$3，付給收單行）
= 商家實收淨額：NT$985

對帳系統需要分別驗證這三段費用是否正確，任何一段的費率設定錯誤（例如某張卡的 Interchange 費率因促銷活動臨時調整），都可能造成淨額對不上，需要對帳系統能定位到是哪一段費用出了問題。

三方模型（Amex，MDR 3%）：

訂單金額：NT$1,000
  − 平台手續費（NT$30，一次扣除）
= 商家實收淨額：NT$970

只有一段費用需要驗證，對帳邏輯直接對應閘道報表上的單一手續費欄位即可，不需要拆解成多段分別核對。

這個差異在系統規模擴大後會被放大：一個月處理十萬筆四方模型交易，代表對帳系統要能追蹤三十萬筆費用拆分記錄，同樣規模的三方模型交易則只需要追蹤十萬筆單一手續費記錄；這也是為什麼許多電子支付新創在初期會優先選擇自建閉環錢包，而不是一開始就串接信用卡四方模型的原因之一：工程和財務的複雜度差距實際上相當可觀。

訂單狀態機要能對應兩種流程

四方的授權後還有獨立的 Capture 步驟；某些三方模型（尤其是電子支付）可能是「授權即扣款」，沒有分開的 Capture。

四方信用卡：INITIATED → AUTHORIZED → CAPTURED → SETTLED
三方電子支付：INITIATED → PAID → SETTLED

如果狀態機只支援一種路徑，遇到另一種模型就會踩坑，因此設計時要讓狀態機夠彈性，或針對不同 Gateway 有不同的狀態定義；常見的做法是讓電子支付的 Gateway 實作在收到授權成功時，連續呼叫 Authorize 和 Capture 兩個 Domain 方法，這樣核心的訂單狀態機邏輯只需要維護一份，不需要為三方模型另外設計一套規則。

Chargeback 處理的不同

四方：持卡人向 Issuer 申訴 → Issuer 向 Card Network 發起 → Network 通知 Acquirer → Acquirer 通知你；中間有多個環節，Webhook 通知可能延遲 1–3 天。

三方（Amex）：Amex 直接通知你；流程短但 Amex 對商家的舉證要求更嚴格，時限也更短。

系統在收到 Chargeback 通知後，要能在幾分鐘內拉出：訂單資訊、付款憑證、物流軌跡、客服記錄，這要求訂單系統在設計時就要把 audit log 做好，不能事後補；若同時支援四方和三方兩種模型，建議在 Chargeback 記錄裡明確標示來源模型，因為兩者的舉證時限、格式要求都不同，處理流程若混用同一套 SLA 會導致三方模型的爭議常常超期未回應。

這兩篇文章從概念到工程應用，完整拆解了四方模型和三方模型的差異。

用一句話概括，四方模型是「開放生態，各司其職」，三方模型是「閉環控制，一家通吃」；四方模型最大的優點是接受度廣、競爭充分，最大的缺點則是費用分配複雜、工程整合難度高，三方模型最大的優點是數據完整、流程可控，最大的缺點則是手續費貴、接受度低；反映在工程重點上，四方模型的挑戰在於多方 API 抽象和 Interchange 對帳，三方模型的挑戰則相對集中在單一對接和狀態機簡化。

理解這兩個模型，就能掌握和支付業務對話的基礎語言，也為設計出正確的支付系統架構打下地基；下一步會深入研究冪等性設計和 Webhook 的可靠送達，那是金流支付後端工程師每天要面對的硬仗。