YayJun
LOADING
YayJun
LOADING
單一金流異常就收不到錢 → 動態路由熱切換與三層補償。
我的角色｜協作開發：國內外金流介接、動態路由熱切換設計，以及排程補償、每日對帳與電子發票開立的實作。
01 ／ 問題與情境
THE PROBLEM ／ 問題與情境
多家
每家金流的簽章、參數與回調格式都不同，接一家就要重寫一套流程。
單點
任一家異常就整條收款斷掉，得改設定重新部署才能換人收。
對不平
callback 會延遲、重送或遺漏，訂單狀態與帳務容易對不起來。
02 ／ 解決方案
THE SOLUTION ／ 解決方案
01 起單
統一訂單模型
各家金流的差異全部收斂在轉接層，上層只看得到一種訂單。
02 路由
動態熱切換
路由設定放 Redis，改設定即生效，不必重新部署。
03 關鍵
三層補償
重複的擋掉、逾時的排程補查、剩下的每日對帳，任一層漏掉都由下一層接住。
04 收手
人工邊界
補查連續失敗就停止自動處理，標記人工介入，不讓程式硬猜結果。
03 ／ 系統架構
ARCHITECTURE ／ 系統架構
1／4 進線層
2／4 訂單與轉接層
3／4 補償層・三層接住
逐層接住漏掉的
callback 去重・逾時主動查回
差異標記待人工處理
4／4 資料與通知
※Desktop 版可展示 Data Flow 🖥️
進線層
訂單與轉接層
補償層・三層接住
逐層接住漏掉的
callback 去重・逾時主動查回
差異標記待人工處理
資料與通知
04 ／ 互動演示
INTERACTIVE DEMO ／ 互動演示
動手桌機可操作可互動送出付款
建立訂單
導向金流商付款
callback 逾時未達
排程掃描逾時交易
主動查詢並補配發
收到完成通知
每一筆的模擬交易結果是隨機的，同一家連續失敗達門檻就會被降權。
※Desktop 版可操作這段演示 🖥️
本頁為去識別化模擬，不含專案原始碼或資料；路由與補償邏輯在瀏覽器端執行，訂單資料皆為合成。
建立訂單
統一訂單模型，各家差異收在轉接層
動態路由
依權重選金流商，可熱切換
金流商 callback
驗簽、逾時與重送都在這
入帳完成
訂單狀態只允許單向前進
本筆事件時序／合成資料
尚未送單
金流商路由看板
已送 0 筆
路由設定放 Redis，連續失敗達門檻自動降權，不必重新部署。
每一筆的模擬交易結果是隨機的，同一家連續失敗達門檻就會被降權。
本頁為去識別化模擬，不含專案原始碼或資料；路由與補償邏輯在瀏覽器端執行，訂單資料皆為合成。
05 ／ 技術選型與設計決策
TECHNOLOGY & DESIGN DECISIONS ／ 技術選型與設計決策
ALTERNATIVE CONSIDERED
為何不只做 callback 重試，而要三層補償？
只靠 callback 重試，僅限「對方有送、我方沒收到」這種錯誤。真實情況還包括金流商沒送、我方收到但寫入異常，以及雙方金額或狀態不一致。因此分成三層：callback 進來先擋掉重複的、排程主動查詢補寫、每日對帳標記人工介入。
06 ／ 挑戰與成果
CHALLENGES & RESULTS ／ 挑戰與成果
挑戰 01
callback 重送與亂序
同一筆交易可能收到多次、甚至先收到後面的狀態；用交易鍵檢查是否處理過，搭配只能單向前進的訂單狀態擋下。
挑戰 02
切換金流商時的在途訂單
路由切換只影響新訂單，已送出的在途訂單沿用原金流商直到終態，避免對不到帳。
熱切換
改 Redis 設定即生效，不必重新部署。
自動補償
逾時交易由排程主動查回，不必人工撈。
對帳可追
每日核對差異，異常一定留下紀錄。