Stripe 全球支付網關與跨國智慧路由架構：交易狀態機、多收單機構容災與超時補償實踐

在現代互聯網與電子商務生態中，支付系統（Payment System） 是整條商業價值鏈中最核心、容錯率最低的心臟模組。任何一筆扣款遺漏、重複請款或交易超時，都會直接引發嚴重的財務損失與用戶信任危機。

全球支付巨頭 Stripe 與 Adyen 之所以能夠在全球範圍內提供「點擊即付」的流暢體驗，背後依賴的是一套極其嚴密的金融級分散式架構：

本文將帶你從零到一拆解全球支付網關的底層運作原理與系統設計實踐。

1. 支付核心領域模型與參與角色

要設計支付網關，必須先釐清全球銀行卡支付鏈路中的 5 大核心角色：

參與角色	英文術語	核心職責
持卡人	Cardholder	消費者，持有銀行發行的信用卡或簽帳金融卡。
商戶	Merchant	提供商品或服務的平台（如 Shopify、Amazon）。
支付網關 / 服務商	Payment Gateway / PSP	封裝底層複雜金融通訊（如 Stripe、Adyen），提供標準 API 與安全 Token 化服務。
收單機構 / 收單行	Acquirer / Merchant Bank	代表商戶向卡組織發起授權結算並將資金存入商戶帳戶的金融機構。
卡組織	Card Network / Schemes	建立全球交換網路與結算清算標準（如 Visa、Mastercard、JCB）。
發卡行	Issuing Bank	向消費者發行卡片、審核信用額度並執行實際扣款的銀行（如 Chase、玉山銀行）。

在電商與訂閱業務中，支付通常分為兩大階段：

授權（Authorization）：
- 凍結用戶信用卡上的指定額度，確保用戶帳戶有足夠資金，此時資金尚未真正轉移至商戶。
- 授權通常具有時效性（一般為 7 天）。
請款 / 捕獲（Capture）：
- 商戶確認履約（例如商品已實際打包出貨或數位憑據已交付）後，通知收單機構正式向發卡行請款轉移資金。
- 支援部分請款（Partial Capture）或撤銷授權（Void / Release）。

支付系統的核心靈魂是嚴格的有限狀態機。任何未定義的狀態跳轉都屬於嚴重系統缺陷。

不可逆性：一旦進入終態（SETTLED、FAILED、REFUNDED），不可再轉移回中間態。
中間態容災：PROCESSING 與 TIMEOUT 必須設定 TTL，並由後台非同步對帳 Worker 負責推進。
樂觀鎖版本控制：資料庫交易紀錄必須包含 version 欄位，狀態變更時執行 UPDATE transactions SET status = 'AUTHORIZED', version = version + 1 WHERE id = ? AND version = ?，防止併發競態條件。

大型全球跨國業務無法單純依賴單一收單行。Stripe 等網關採用動態智慧路由演算法，根據以下維度計算最優路徑：

本幣本卡（Domestic vs. Cross-Border）：若持卡人為日本 JCB 卡，優先路由至日本境內收單行，避免跨國交易手續費（Cross-Border Fee）與發卡行風控攔截。
自適應重試與降級（Adaptive Retry）：
- 當收到收單機構的軟性拒絕（Soft Decline）（如網路超時、系統繁忙）時，智慧路由會立即切換至備用收單行重試；
- 當收到硬性拒絕（Hard Decline）（如卡號不存在、餘額不足、遭竊卡）時，直接標記失敗，嚴禁重複重試以避免被卡組織處以罰款。

金融系統最常見的崩潰情境是網路分區造成的「不知道扣款到底成不成功」：

此時商戶客戶端重試可能導致重複扣款。支付系統必須實作嚴密的雙重防禦：

若向收單行發起請求超過閥值（如 5 秒未回傳），網關將交易狀態標記為 TIMEOUT，並將任務投遞至延時消息隊列（Delayed Queue）。
背景 Worker 在 10 秒、30 秒、2 分鐘後向收單行主動發起「查詢訂單狀態」API，若收單行已扣款成功則自動補齊內部狀態並發送 Webhook 通知商戶；若收單行確認未收到請求，則安全關閉交易。

絕對不裸存卡號：所有卡號、CVV 必須在前端通過 PCI-DSS Level 1 認證的 Tokenization SDK 轉換為 Token，源站伺服器絕不接觸明文敏感資訊。
狀態機是唯一的真理之源：所有的業務異動必須以狀態機事件為準，禁止直接修改狀態欄位。
全鏈路冪等覆蓋：從商戶端、網關層到收單行通訊，每個環節皆需具備明確的冪等保護與超時主動補償管線。