服務各自保存金流機密
改由共用金流中心集中管理供應商憑證，第三方服務只持有自己的 API 驗證資訊。
SERVICE APPROACH
金流不只是一個
付款按鈕
真正可營運的金流服務，需要能確認交易來源、驗證供應商回呼、避免重複處理，並保留從付款到權益交付的完整證據。
我們以供應商解耦的標準介面承接自有服務費付款；合作服務不需保存金流供應商憑證，也不需理解供應商欄位。
WHAT WE SOLVE
讓交易流程可驗證、
可復原、可稽核
從提交到回傳，每一段都使用 POST，並以伺服器端驗證結果作為交易狀態依據。
瀏覽器返回被當成付款成功
以驗證完成的供應商 Server Callback 更新交易；瀏覽器返回只負責導回指定頁面。
重送造成重複訂單或權益
Idempotency Key、唯一交易編號與事件去重，確保相同請求只生效一次。
付款完成但服務未收到結果
Callback Inbox 與 Outbox 保留可重試事件，讓已付款但未交付的狀態可以復原。
WHAT WE BUILD
完整金流生命週期
建立交易
以標準 POST API 建立付款，驗證來源、金額、回傳網址與冪等鍵。
直接前往付款頁
收到請求後直接輸出自動送出的 POST 表單，不顯示轉接提示。
驗證付款結果
驗證簽章、商店資料與訂單狀態後，才更新付款結果。
通知與導回
以 POST 通知來源服務，並將會員導回指定頁面與必要交易結果。
交易查詢
來源服務可依標準介面查詢狀態、時間、金額與交付結果。
退款與對帳
保留退款、差異追蹤、重試、稽核與供應商診斷能力。
STANDARD API, PROVIDER INDEPENDENT
服務只對接共用介面，
不綁定金流供應商
金流中心對外維持統一契約，供應商欄位、簽章與環境切換留在中心內部。未來增加或更換供應商時，既有服務端契約保持穩定。
本次金流範圍
只處理自有服務費，例如 PushMe 平台訂閱；不承接廟宇捐款、活動費、商品或其他服務對終端會員的代收款。
01來源服務POST 建立付款
→ 02金流中心驗證・記錄・轉送
→ 03金流供應商測試環境
04已驗證 Callback → 交易狀態 → POST 通知／導回
DELIVERABLES
每次導入都有
可驗收的成果
不只交付功能，也把契約、安全、例外處理與後續維運方式一起建立。
標準 API 與欄位規格
請求、回應、簽章、錯誤碼、冪等與版本策略。
第三方服務串接說明
環境設定、測試案例、Callback 與查詢使用方式。
監控與異常處理
交易紀錄、重試、對帳、稽核與故障追蹤。
IMPLEMENTATION PROCESS
從契約到正式切換
需求與邊界
確認付款項目、權益與責任範圍。
API 契約
定義請求、回應與錯誤處理。
測試環境串接
以金流供應商測試環境完整驗證。
例外與回歸
重送、失敗、查詢與交付測試。
正式環境切換
核對正式設定後再啟用收款。
FAQ
常見問題
實際規格會依服務需求與既有系統確認。
第三方服務需要保存金流供應商憑證嗎？
不需要。供應商憑證只保存在金流中心，第三方服務使用各自的 API 驗證資訊。
付款頁會顯示轉接提示嗎？
不會。建立付款成功後會直接以 POST 前往供應商付款頁，不顯示任何轉接提示頁。
如何判定付款真正完成？
以金流中心驗證通過的供應商伺服器 Callback 為準，不以瀏覽器返回或前端參數作為付款證明。
正式環境何時啟用？
目前先使用測試環境。待服務端串接、例外情境與回歸測試完成後，再核對正式設定並切換。
START YOUR PROJECT
建立可靠的金流服務
從 API 契約與付款邊界開始，把交易流程做成能長期維運的共用能力。