問題
要賣到不同國家，就得用各地習慣的方式收錢。多家本地金流商帶來不同的 Webhook 方言與銀行清算檔案格式——而每天結束時，帳本仍然要和它們全部對得起來。
我負責的部分
公司電商的 Payment Gateway：結帳前端、每一家金流商的後端串接，以及兩者之間的資料流——從客人選擇付款方式，到訂單、付款紀錄與帳本三者一致為止。
這裡保留我的工作範圍與整合原則，不展開商家的內部路由設定、銀行連線資訊或原始交易內容。
金流路由
不同市場有不同付款方式，也需要對接不同金流商。我負責串接各家的介面與回傳格式，讓結帳流程能接到後續的付款狀態處理。供應商選擇條件與商業設定不在公開案例中展開。
清算對帳
導入 CODA 之後，原本重複的人工比對被改成例外處理：解析銀行對帳單，用參考號與金額跟帳本比對，只有真正的例外才需要人看。改善不是來自程式跑得比較快，而是把不需要人工判斷的工作移除了。
可靠性設計
冪等鍵與統一的 Webhook 事件格式，讓重試能對回同一筆操作，下游也能用一致的方式處理付款狀態。這段工作的重點，是讓外部通知、內部狀態與對帳結果接得起來。
資料保存則需要另訂邊界：事件應保留必要的交易識別與處理結果；若確實需要原始證據，應依資料分類、查閱權限與保存期限管理，而不是一律完整保存所有 payload。這是整理這段經驗後的設計原則，不代表每項保存控制都已在當時實作。更多取捨見 PSP 交易生命週期。