YayJun
LOADING
YayJun
LOADING
單一金流異常就收不到錢 → 動態路由熱切換與三層補償。
我的角色｜協作開發：國內外金流介接、動態路由熱切換設計，以及排程補償、每日對帳與電子發票開立的實作。
THE PROBLEM ／ 問題與情境
多家
每家金流的簽章、參數與回調格式都不同，接一家就要重寫一套流程。
單點
任一家異常就整條收款斷掉，得改設定重新部署才能換人收。
對不平
callback 會延遲、重送或遺漏，訂單狀態與帳務容易對不起來。
THE SOLUTION ／ 解決方案
01 起單
統一訂單模型
各家金流的差異全部收斂在轉接層，上層只看得到一種訂單。
02 路由
動態熱切換
路由設定放 Redis，改設定即生效，不必重新部署。
03 關鍵
三層補償
重複的擋掉、逾時的排程補查、剩下的每日對帳，任一層漏掉都由下一層接住。
04 收手
人工邊界
補查連續失敗就停止自動處理，標記人工介入，不讓程式硬猜結果。
ARCHITECTURE ／ 系統架構
進線層
訂單與轉接層
補償層・三層接住
逐層接住漏掉的
callback 去重・逾時主動查回
差異標記待人工處理
資料與通知
INTERACTIVE DEMO ／ 互動演示
可互動建立訂單
統一訂單模型，各家金流差異收斂在轉接層
動態路由
依 Redis 設定選金流商，可即時熱切換
Callback 異常
逾時、失敗或重送，都在這一步被攔下
補償重試
排程主動查詢補寫，同一筆只入帳一次
異常情境 ／ 合成資料
訂單狀態時序
待機中從左邊選一個異常情境，看它在哪一步失敗、又是怎麼補回來的。
預設路由：信用卡費率最低
狀態時序
補償結果
熱切換：金流商 A 連續失敗達門檻，自動降權
狀態時序
補償結果
指定路由：該支付方式僅此商支援
狀態時序
補償結果
本頁為去識別化整理，不含前雇主原始碼或資料；訂單編號、金額與時間皆為前端合成資料。
TECHNOLOGY & DESIGN DECISIONS ／ 技術選型與設計決策
ALTERNATIVE CONSIDERED
為何不只做 callback 重試，而要三層補償？
只靠 callback 重試，僅限「對方有送、我方沒收到」這一種故障。真實情況還包括金流商沒送、我方收到但寫入異常，以及雙方金額或狀態不一致。因此分成三層：callback 進來先擋掉重複的、排程主動查詢補寫、每日對帳標記人工介入。代價是三套邏輯都要維護，但少任何一層，就會留下無法回查的缺口。
CHALLENGES & RESULTS ／ 挑戰與成果
挑戰 01
callback 重送與亂序
同一筆交易可能收到多次、甚至先收到後面的狀態；用交易鍵檢查是否處理過，搭配只能單向前進的訂單狀態擋下。
挑戰 02
切換金流商時的在途訂單
路由切換只影響新訂單，已送出的在途訂單沿用原金流商直到終態，避免對不到帳。
熱切換
改 Redis 設定即生效，不必重新部署。
自動補償
逾時交易由排程主動查回，不必人工撈。
對帳可追
每日核對差異，異常一定留下紀錄。