試想一個結帳情境:支付成功,但訂單更新失敗。顧客看到錯誤訊息後再次嘗試。與此同時,客服手上有一筆交易紀錄,倉庫沒有確認的訂單,而財務部門需要知道顧客是否仍欠款。

哪個系統應該解決這種情況?這類事故正是架構決策浮上檯面的時刻:當責任歸屬未定義時,每次事故都會得到一個手工打造的修補,而這些修補往往累積在最容易撰寫的地方。

架構應該在第一筆交易進入正式環境之前回答這個問題。否則,支付程式碼會逐漸吸納訂單復原、訂閱規則、發票調整與履約決策。

以下描述的責任模型提供一個務實的起點:讓閘道專注於與供應商的溝通,讓支付作業有自己的歸屬,並將商業決策留給帳務與訂單。

從四個職責開始,而非三個

在這個設計中,要將支付閘道與更廣義的支付服務區分開來。此模型使用四個邏輯邊界,涵蓋閘道、支付服務、帳務與訂單。

將這些視為責任邊界,而不是部署四個微服務的指示。如果適合團隊,從單一應用程式內的模組開始也無妨。無論如何,職責都應該被明確定義。

在審視支付閘道架構時,請將元件圖與決策地圖搭配使用:誰決定金額、誰發起收款、誰記錄結果、以及誰授權下一個業務動作?

讓閘道貼近供應商

給予閘道一個狹窄的契約。它應該接受一個受支援的支付操作,將其轉換為供應商的格式,並回傳支付服務可解讀的結果。

這種隔離有實際的動機:各家支付供應商在 API、驗證機制、欄位格式與通知方式上各不相同,將這些差異集中在一個層,可以讓系統其餘部分免於受到供應商細節的影響。

賦予它以下職責:

• 驗證面向供應商的請求
• 對與供應商的通訊進行身分驗證
• 將內部欄位轉換為供應商專屬欄位
• 驗證供應商傳入的通知
• 映射回應,同時保留有用的供應商資訊

產品知識不應進入這份契約。閘道不需要理解會員等級、出貨資格、訂閱寬限期或促銷組合。傳遞給它的是已核准的金額、幣別、支付參照與必要的支付方式資訊——而非產生這些資料的規則。

一個實用的審查問題:修改退貨政策是否需要修改閘道程式碼?如果是,請重新考慮這條邊界。

為支付作業安排獨立的負責者

支付嘗試及其結果應歸屬於支付服務。對每一次嘗試,記錄內部識別碼、相關的供應商參照、請求金額、幣別、操作類型與狀態。保留足夠的歷史紀錄,以調查當時請求了什麼以及實際確認了什麼。

避免將模型簡化為單一個 paid 旗標。應定義工作流程所需的各種區別,包括未確定的結果。與供應商的通訊有時確實存在不確定性——逾時、延遲通知與亂序更新是家常便飯——因此狀態模型需要容納模糊性的空間,而不是將所有結果壓縮為成功或失敗。

針對以下假想情境進行明確設計:支付服務請求授權,請求送達供應商,但回應遺失。應用程式接著必須決定下一步。逾時絕不應自動觸發新的扣款。應要求支付服務先解決或安全地管理原始嘗試,才允許進行其他操作。

兩種重試也應該區分:

• 技術性重試:在定義的安全規則下,對同一個預期操作重複通訊。
• 收款重試:為收取未清餘額而發起的新嘗試。

技術性重試的處理應歸入支付整合設計。帳務決定收款的時機與資格,由支付服務執行已核准的嘗試。

讓帳務定應收金額

帳務擁有財務義務:費用計算、發票、折抵與剩餘餘額。對訂閱型產品而言,方案變更、按比例計費、帳單週期與收款排程的規則都屬於這裡。

要求帳務在發起每一筆收款請求時,附上明確的金額、幣別以及對應收款義務的參照。支付服務回報結果,帳務再決定該結果如何影響餘額。

試想一張假想的 100 元發票,附有 30 元折抵。帳務應請求剩餘的 70 元。絕不應要求閘道從訂閱中繼資料重建這項計算。

定價越複雜,風險越高:每一項落在錯誤元件中的計算,日後都成為必須被找出、遷移並跨系統對帳的邏輯。

退款之後也適用同樣的紀律。支付紀錄確立透過供應商退回了什麼;帳務則決定哪張發票或餘額調整對應該筆退款。

讓訂單決定購買的後續處理

履約與購買生命週期決策留在訂單領域。支付服務應發布支付結果,而不是下達倉庫指令,訂單工作流程則應將該結果與其他需求一併解讀。對結果的解讀既是業務判斷也是技術判斷,因為同一筆已確認的支付,對不同的履約模式可能有不同的意義。

明確履約規則的一個例子:只有當必要的支付條件已滿足、庫存已分配且所有必要的審核已完成時,才釋出訂單。支付條件應依商業模式選擇,絕不應藏在供應商回應處理器之中。

取消作業也應遵循同樣的分離原則。訂單決定是否允許取消以及購買該如何處理,再透過支付服務請求適當的支付操作。避免使用一個過載的「取消」指令,讓它可能同時代表取消訂單、釋放授權、退款或終止訂閱。請為每個動作精確命名。

協調退款,但別讓單一系統包辦所有工作

退款流程是檢驗邊界是否穩固的好方法。假設顧客從一件三件組的訂單中退回一件。將流程計成:

• 退貨或訂單元件核准退貨。
• 被指定的商業計算負責者決定可退款金額。
• 支付服務檢查支付歷史與適用的操作限制。
• 閘道提交供應商請求。
• 支付服務記錄已確認或未確定的結果。
• 帳務與訂單各自更新自身的紀錄。

為每項計算指定唯一的負責者。不應讓帳務與訂單各自獨立計算出不同的退款金額,再讓支付端從中挑選。

將「已請求退款」與「已確認退款」分開。如果供應商結果未確定,應保留該不確定性並提供調查途徑,而不是將整個流程標記為完成。

把復原納入契約

每一項跨邊界的操作,都應規範成功回應以外的事項。文件應涵蓋:

• 如何識別重複的請求
• 哪個元件擁有權威狀態
• 如何處理延遲或重複的通知
• 當下一個元件無法使用時該怎麼辦
• 人員如何調查未確定的結果
• 哪些動作可以安全地重試

特別是重複請求,供應商通常提供專為此目的設計的冪等機制,讓同一個操作可以在不被重複執行的情況下重新提交。

為每個領域配置各自的識別碼並明確串接:訂單 ID、發票 ID、支付 ID、嘗試 ID 與供應商參照。不要強迫單一識別碼代表所有關聯。

客服人員可以取得合併的時間軸,但修正應保留在擁有該資料的元件控制之下。方便的儀表板不應成為覆寫支付歷史或悄然更改發票餘額的許可。

用業務變動測試邊界

在核准設計之前,演練幾種變動:

• 在不更改定價規則的情況下新增支付供應商。
• 在不編輯閘道介接器的情況下更改訂閱收款時程。
• 在不重寫供應商通知處理的情況下導入部分退貨。
• 在不改動支付狀態定義的情況下調整履約政策。

將意料之外的跨元件變更視為審查訊號。某些協調是合理的;無法解釋的耦合則值得關注。

責任漂移很少會自我宣告;它透過一次次的權宜變更逐漸累積。每當引入新的供應商、支付方式或定價模型時重新執行這些演練,才能讓邊界在初次設計審查之後長期保持明確。

閘道應止於面向供應商的支付通訊。支付服務應擁有支付執行與憑證。帳務應擁有義務與餘額。訂單應擁有購買及其履約。

請將這些職責寫進介面、復原程序與團隊權責之中。光靠一張圖,無法讓它們保持離。