很多後端工程師在接觸支付系統時，第一關就卡在「業務語言」上，技術沒問題，但和 PM、業務、甚至面試官討論時，常常對不上頻率。四方模型（Four-Party Model）與三方模型（Three-Party Model）是支付產業的基礎架構分類，理解這兩者不只是業務知識，它直接影響你的：
- 系統設計決策（要不要抽象 Gateway 介面？對帳邏輯怎麼設計？）
- API 整合策略（Visa 和 Amex 的授權流程根本不一樣）
- 面試表現（支付公司面試幾乎必問）
本文從角色結構、資金流向、費用分配到工程師視角的實作影響，拆解這兩個模型。
四方模型（Four-Party Model / Open Loop）
五個角色，四段關係
「四方」這個名字略有誤導：實際上有五個實體，只是因為有「四段核心商業關係」才這樣命名。
角色 | 中文 | 實際例子（台灣） | 核心職責 |
|---|---|---|---|
Cardholder | 持卡人 | 你我這樣的消費者 | 發起交易、承擔帳單 |
Issuer | 發卡行 | 玉山、台新、花旗 | 核發信用卡、授權、承擔壞帳風險 |
Card Network | 卡組織 | Visa、Mastercard | 路由、清算規則、制定 Interchange 費率 |
Acquirer | 收單行 | 聯合信用卡中心、玉山收單 | 代商家接收款項、撥款給商家 |
Merchant | 商家 | 全聯、momo、各電商 | 提供商品或服務、繳交手續費 |
關鍵點：Issuer 和 Acquirer 是完全獨立的兩家機構，彼此之間透過 Card Network 溝通。這就是「Open Loop（開放迴路）」名稱的由來，任何 Issuer 發的卡，理論上可以在任何 Acquirer 服務的商家刷卡。
一筆交易的完整資金流
以「用玉山 Visa 在全聯刷 NT$1,000」為例：
階段一：授權（即時）
持卡人 → POS 機（全聯） → 聯合信用卡中心（Acquirer）
→ Visa 網路（Card Network）→ 玉山銀行（Issuer）
玉山確認額度夠、風控通過，回傳 Approval Code。此時只是凍結額度，資金未動。
階段二：清算（當日批次）
全聯日終把所有刷卡記錄批次送給收單行，收單行整理後送給 Visa，Visa 計算各方應付金額（含 Interchange）。
階段三：結算（T+1 或 T+2）
玉山（Issuer）→ 扣除 Interchange，撥款給 Visa
Visa → 扣除 Network fee，撥款給聯合信用卡中心（Acquirer）
聯合信用卡中心 → 扣除 Acquirer Markup，淨額撥給全聯帳戶
最後全聯帳戶實際入帳 NT$985（假設 MDR 1.5%）。
Interchange：四方模型的核心機制
Interchange fee 是整個四方生態的財務引擎，也是很容易搞混的費用。
它的流向：Acquirer 代商家支付給 Issuer。
它的邏輯：Issuer 承擔了持卡人的信用風險（萬一持卡人不還錢），又要提供回饋點數吸引消費，這筆成本要有人買單，就由收款方（商家側）透過 Interchange 補貼。
費率決定因素：
- 卡種（白金卡 > 普通卡，因為白金卡持有者消費力強、吸引商家）
- 商店類別（MCC Code）：超市、加油站費率較低；餐廳、精品較高
- 交易方式：實體刷卡 < 線上刷卡（線上風險更高）
這就是為什麼同一張 Visa 卡，在不同店家刷，Interchange 費率可能不一樣。
三方模型（Three-Party Model / Closed Loop）
核心概念：三個角色合為一
三方模型的核心概念是：發卡、清算、收單三個功能由同一家公司包辦。
持卡人 ←──────────────────────→ 商家
↑ ↑
└── Amex（扮演三個角色）──┘
Issuer + Network + Acquirer
Amex 自己發卡給持卡人、自己建立交易網路、自己直接跟商家簽約。不需要 Interchange，因為左口袋和右口袋都是自己的。
代表品牌：American Express
資金流的簡潔性
同樣 NT$1,000 的刷卡：
持卡人 → 刷 Amex 卡
Amex → 授權（自己決定）、清算（內部處理）
Amex → 扣除手續費後，撥款給商家
持卡人 → 帳單日還款給 Amex
中間完全沒有第三方，所有數據、資金、風控都在 Amex 內部流動。
為什麼手續費反而更高？
表面上省掉了 Interchange，理論上成本應該更低——但現實中 Amex 的 MDR 反而高達 2.5–3.5%（Visa 約 1–2%）。
原因有幾個：
持卡人福利更豐厚：Amex 白金卡的機場貴賓室、高額旅遊保險、豐富回饋，成本要由商家手續費補貼。
客群定位高端：Amex 主打高消費力族群，商家願意為「吸引這群客人」付出溢價。
無法議價：四方模型下，大商家可以和 Acquirer 談判 MDR；三方模型下，費率幾乎是 Amex 單方面決定。
這也解釋了一個現實：很多小商店拒收 Amex，因為 3% 的手續費可能直接把利潤吃光。
逐項比較
比較面向 | 四方模型（Open Loop） | 三方模型（Closed Loop） |
|---|---|---|
角色結構 | 5 個實體，職責分離 | 3 個實體，核心由 1 家包辦 |
代表品牌 | Visa、Mastercard、銀聯 | Amex、Discover、Diners |
Interchange | 存在，Network 制定費率 | 不存在，內部消化 |
商家手續費（MDR） | 約 1–2% | 約 2.5–3.5% |
持卡人福利 | 中等，視 Issuer 策略 | 通常更豐厚 |
全球接受度 | 幾乎通用 | 部分商家拒收 |
消費數據掌握 | 分散在各 Issuer | 全鏈路自己掌握 |
競爭障礙 | 低（任何銀行可發卡） | 高（需自建整套生態） |
工程複雜度 | 較高（多方整合） | 較低（單一對接） |
台灣本地的延伸思考
行動支付更接近三方模型
在台灣，街口支付、LINE Pay Money、全支付這類「電子支付」，其實在架構上更接近三方模型：
- 發帳戶（等同 Issuer）：用戶在 app 儲值或綁定帳戶
- 處理交易（等同 Network）：自建清算和風控系統
- 對商家收費（等同 Acquirer）：直接和商家簽服務合約
這給了這些平台一個四方模型做不到的優勢：完整的消費行為數據。Visa 只看到你刷了多少錢、在哪個 MCC 類別；街口卻知道你在哪家店、買了什麼、什麼時間、搭配什麼優惠券。這個數據優勢在精準行銷和反詐欺上非常關鍵。
銀聯的特殊地位
銀聯（UnionPay）是一個有趣的例子——在中國境內運作更接近三方（高度整合、政策主導），但在國際上和 Visa/Mastercard 合作時走四方模型。同一個品牌，在不同市場用不同的模型運作。
工程師視角：這兩個模型怎麼影響程式碼？
API 整合：不要假設一致性
四方的 Visa 和三方的 Amex，授權 API 長得完全不同：
// 不建議的做法：針對每家寫死邏輯
if (cardType == "VISA") {
var request = new VisaAuthRequest { ... };
// Visa 特定欄位...
} else if (cardType == "AMEX") {
var request = new AmexAuthRequest { ... };
// Amex 完全不同的欄位...
}
// 建議的做法：抽象 Gateway 介面
public interface IPaymentGateway {
Task<AuthResult> AuthorizeAsync(AuthRequest request);
Task<CaptureResult> CaptureAsync(string authCode, decimal amount);
Task<RefundResult> RefundAsync(string transactionId, decimal amount);
Task<VoidResult> VoidAsync(string authCode);
}
public class VisaGateway : IPaymentGateway { ... }
public class AmexGateway : IPaymentGateway { ... }
public class TapPayGateway : IPaymentGateway { ... } // 本地閉環
這個介面抽象讓你日後新增支付方式時，只需要新增一個實作類別，不動核心邏輯。
對帳邏輯的差異
四方模型的對帳需要核對三本帳：
- 你系統的訂單帳（
orders表） - Acquirer 的結算報表（含 Interchange 拆分）
- 公司銀行帳（實際入帳金額）
由於 Interchange 的存在，商家拿到的金額 ≠ 交易金額，你的對帳系統要能算出正確的預期入帳金額再比對。
三方模型的對帳相對簡單：
- 你系統的訂單帳
- Amex/電支的結算報表
費用扣法更直觀，一份報表就能完成對帳。
訂單狀態機要能對應兩種流程
四方的授權後還有獨立的 Capture 步驟；某些三方模型（尤其是電子支付）可能是「授權即扣款」，沒有分開的 Capture。
四方信用卡：INITIATED → AUTHORIZED → CAPTURED → SETTLED
三方電子支付：INITIATED → PAID → SETTLED
如果你的狀態機只支援一種路徑，遇到另一種模型就會踩坑。設計時要讓狀態機夠彈性，或針對不同 Gateway 有不同的狀態定義。
Chargeback 處理的不同
四方：持卡人向 Issuer 申訴 → Issuer 向 Card Network 發起 → Network 通知 Acquirer → Acquirer 通知你。中間有多個環節，Webhook 通知可能延遲 1–3 天。
三方（Amex）：Amex 直接通知你。流程短，但 Amex 對商家的舉證要求更嚴格，時限也更短。
你的系統收到 Chargeback 通知後，要能在幾分鐘內拉出：訂單資訊、付款憑證、物流軌跡、客服記錄。這要求你在設計訂單系統時就要把 audit log 做好，不能事後補。
面試常見問法與建議回答方向
Q：四方模型和三方模型有什麼差別？
不要只說「角色數量不同」。完整回答包含：角色結構 → Interchange 有無 → 費用高低的原因 → 接受度差異。最後主動帶到工程影響（API 抽象設計），讓面試官知道你能把業務知識轉成技術決策。
Q：如果系統要同時支援 Visa 和 Amex，你會怎麼設計？
說出 IPaymentGateway 介面、Strategy Pattern，以及對帳邏輯的分離。如果有時間，提到 Chargeback 的處理差異更加分。
Q：台灣的電子支付算哪個模型？
說三方（Closed Loop），並解釋原因：發帳戶 = Issuer、自建清算 = Network、直簽商家 = Acquirer。可以提到數據掌握優勢作為延伸。
延伸學習資源
資源 | 說明 |
|---|---|
Stripe 官方文件 | 最好的支付流程入門，"How payments work" 那章必讀 |
Visa Developer Portal | 有完整的四方模型技術文件和 API 規格 |
PaymentsJournal.com | 業界媒體，追蹤支付產業動態 |
《Payments Systems in the U.S.》(Kindle) | 系統性了解支付基礎設施的書籍 |
microservices.io | Saga Pattern、Outbox Pattern 等與支付相關的微服務設計 |
四方模型 | 三方模型 | |
|---|---|---|
一句話 | 開放生態，各司其職 | 閉環控制，一家通吃 |
最大優點 | 接受度廣、競爭充分 | 數據完整、流程可控 |
最大缺點 | 費用分配複雜、工程整合難度高 | 手續費貴、接受度低 |
工程重點 | 多方 API 抽象、Interchange 對帳 | 單一對接、狀態機簡化 |
理解這兩個模型，就能掌握和支付業務對話的基礎語言，也為設計出正確的支付系統架構打下地基。接下來，可以深入研究冪等性設計和 Webhook 的可靠送達，那才是支付後端工程師每天真正要面對的硬仗。
本文為個人學習筆記，持續更新中。
