金流串接整合完整指南：客製化系統安全接入綠界、藍新、TapPay 的關鍵設計
為什麼客製化系統的金流串接這麼重要？
金流是電商、SaaS、訂閱平台、社群電商等客製化系統最核心的功能之一，也是最容易出問題的環節。一旦金流流程設計不當，輕則造成訂單狀態錯亂、客訴爆增；重則可能導致重複收款、漏帳、甚至資安事件。
近年台灣企業在自建系統時，普遍會選擇與第三方金流（如綠界、藍新、TapPay）整合，而非自行串接銀行 API。這些金流商已處理大部分 PCI-DSS 合規與發卡銀行對接，能讓開發團隊把心力放在業務邏輯與使用者體驗上。
台灣企業常用的金流方案比較
選擇金流商前，建議從費率、整合難度、支援的支付方式、撥款週期、API 文件品質與技術支援回應速度等多個面向綜合考量。以下整理四個在台灣客製化系統中最常被選用的方案，協助你快速評估。
綠界 ECPay
台灣使用率最高的金流之一，支援信用卡、超商代碼、超商條碼、ATM 虛擬帳號、Apple Pay、Google Pay 與行動支付。費率約 2.75%~3%，介面與文件對開發者友善，且後台對帳工具完整，是中小企業客製化系統的常見首選。
藍新 NewebPay
支援的支付方式與綠界相當接近，並提供分期付款、定期定額與背景授權（會員儲卡）等功能。對於訂閱制系統或會員卡綁定場景特別合適，技術文件清楚，並支援 RWD 結帳頁。
TapPay
主打 Direct Pay 的儲卡與快速結帳體驗。卡號加密在前端 SDK 中完成，後端只接收 prime token，可大幅降低 PCI-DSS 範圍。適合追求結帳轉換率與行動體驗的 D2C 品牌與電商。
Stripe
跨國金流首選，支援 135+ 種貨幣與 Apple Pay、Google Pay、Klarna 等。API 與 webhook 設計被視為業界範本，但台灣本地支付（如超商繳費）支援度較低，較適合 SaaS 訂閱與跨境電商。
金流串接的核心流程
無論選擇哪一家金流商，整體流程都圍繞五個階段：建立訂單、產生付款單、導向付款頁、收取通知、更新訂單。理解這五個步驟有助於你快速判斷整合範圍與工時。
建立訂單：系統先在自家資料庫產生 order，狀態為
pending，紀錄商品、金額與買家資訊。訂單編號要設計為不可預測（例如加上 hash），避免被外部猜測。產生付款單：呼叫金流商 API 或組裝 HTML form，把訂單編號、金額、商店代號與檢核碼傳給金流商，取得付款連結。
導向付款頁：使用者跳轉到金流商的結帳頁面（或使用 SDK 嵌入信用卡欄位），完成輸入卡號或選擇支付方式。
接收通知：金流商透過 Webhook（背景通知）告知付款結果，後端依檢核碼驗證請求真實性，再更新訂單狀態。
更新訂單與後續流程：付款成功才觸發出貨、開立發票、發送通知；失敗則保留 pending 給使用者重新付款的機會。
Webhook 通知設計：背景通知比前景跳轉更可靠
很多新手會把「使用者付款後跳回的網址」當成更新訂單的依據，這是金流串接最常見的錯誤。使用者可能在付款後直接關閉視窗，跳轉就不會發生，但金流商已扣款。正確的做法是以後端 Webhook（綠界稱 ReturnURL、藍新稱 NotifyURL、Stripe 稱 webhook event）為訂單狀態的唯一真實來源（Source of Truth）。
Webhook 設計時必須考量三件事：
檢核碼驗證：每筆通知都要重新計算 CheckMacValue / signature，確認來源是金流商而非偽造請求。
冪等性 Idempotency：同一筆訂單可能收到多次通知，要以訂單編號 + 狀態做唯一性鎖，避免重複出貨或重複開發票。
2xx 回應與重試策略：處理成功必須回傳指定字串（如綠界要求
1|OK），否則金流商會持續重試造成資料異常。
訂單一致性與重複付款處理
客製化系統最容易踩雷的不是「成功的付款」，而是「失敗、重試、退款」這些邊界情況。建議以狀態機（State Machine）明確定義訂單生命週期：pending → paid → shipped → completed，並列出所有合法的轉移條件。
常見的邊界情境包括：
使用者送出付款後，前端跳轉失敗，但 Webhook 已通知付款成功 → 系統應根據 Webhook 直接更新狀態，不依賴前端確認。
使用者重複按下付款按鈕造成兩次扣款 → 結帳頁需要前端 disable 與後端冪等性檢查雙重防護。
付款後立即取消 → 系統需支援退款 API，並同步沖銷庫存與發票。
分期付款後悔 → 退款金額計算與分期手續費歸屬要事先設計清楚。
金流串接的 5 個資安重點
金流是攻擊者最有興趣的標的。客製化系統在串接金流時，至少需要做到以下五項基本資安措施：
不在後端儲存完整卡號：除非你有完整的 PCI-DSS 認證，否則卡號處理一律交給金流商前端 SDK，後端只接收 token。
金額在後端再次計算：絕對不要相信前端送來的金額。建立付款單前，必須由後端依商品 ID、優惠券、運費等重新計算總額，避免前端被竄改。
HTTPS 與 HSTS 必備：所有金流頁面與 API 通訊必須走 TLS 1.2 以上，並啟用 HSTS 防止降級攻擊。
Webhook 來源 IP 白名單與簽章雙驗證：除了驗證簽章，建議再以 IP 白名單做額外保護。
金鑰管理：HashKey、HashIV、API Secret 不可寫死在程式碼中，應透過環境變數或秘密管理服務（如 AWS Secrets Manager、Vault）載入，並定期輪替。
客製化系統金流整合常見的 4 個錯誤
從多年協助企業整合金流的經驗，我們歸納出以下幾個高頻率的錯誤：
把 Webhook 當輔助、把跳轉當主要依據：導致使用者關閉視窗就漏單，是最常見的客訴來源。
沒有處理測試金流與正式金流切換：常常上線後才發現 HashKey 沒換到正式環境，造成首日訂單全部驗證失敗。
缺乏對帳機制：金流商每日提供對帳檔，若沒有自動下載與比對，月底才發現帳對不上時已難以追溯。
沒有重試與監控：Webhook 失敗時沒有重試佇列、沒有告警，造成數筆訂單長期停留在錯誤狀態。
結語：金流是客製化系統的信任基石
對企業客戶來說，金流串接的品質直接決定了顧客對你產品的信任程度。從訂單一致性、Webhook 處理、資安到對帳，每個環節都需要扎實的設計與測試。建議在規劃客製化系統時，把金流模組獨立出來，以服務化的方式設計，未來不論換金流商或擴展到多通路，都能用最低的成本完成切換。
山葵組有多家電商、訂閱制與企業 ERP 的金流整合經驗。金流本身的串接做法整理在第三方金流串接；若需求是從報價、簽核到訂單與收款的完整流程，可參考訂單與報價系統開發。