網站串接金流前，先確認這 10 個技術環節

付款按鈕是前台畫面；訂單是否正確成立，還要看金鑰、檢查碼、背景通知、重複處理、退款與對帳。

以下整理綠界（ECPay）、藍新（NewebPay）等金流串接常見的 10 個檢查項目。即使由開發團隊處理，業主也可以用這份清單確認測試是否完整。

1.測試金鑰和正式金鑰搞混

金流商會給你兩套密碼（MerchantID、HashKey、HashIV）：一套測試用、一套正式用。很多人開發時用測試的，上線卻忘了換成正式的。

若正式站仍使用測試參數，畫面可能看似完成付款，但實際交易並未進入正式商店帳戶。上線前應重新核對環境與商店代號。

2.檢查碼 CheckMacValue 算錯

每一筆交易都要附一段「防偽印章」，用你的金鑰把參數依規則加密產生。編碼方式、英文大小寫、URL 編碼只要差一點點，這枚印章就對不上。

計算不一致時，金流會回傳「CheckMacValue Error」，付款請求也會被拒絕。

3.只信前端畫面，沒驗證回傳的檢查碼

付款完成後，金流會回傳一則「成功」訊息。關鍵是：你必須反過來用檢查碼驗證「這則訊息真的是金流發的」，不能照單全收。

沒驗證會怎樣？有心人可以自己偽造一則「付款成功」打給你的網站，你信以為真就出貨——等於東西被白白拿走，零元購。

4.只靠前端 ReturnURL，沒接背景通知 NotifyURL

金流通常有兩條回報路線：一條是付款後回到網站的畫面（ReturnURL），另一條是金流伺服器送出的背景通知（NotifyURL）。訂單狀態應以伺服器端通知與查詢結果為主要依據。

如果只依賴前端跳轉，客人關閉分頁或連線中斷時，訂單狀態可能無法更新。伺服器端背景通知才是主要依據。

5.背景通知收到後，沒回「1|OK」

金流在背景通知你之後，規定你要回一句「1|OK」告訴它「我收到了」。沒回，它會認定通知失敗。

於是金流會每隔幾分鐘一直重送同一筆通知，你的系統可能因此重複建單、重複寄信給客人。

6.沒做「重複通知」防呆（冪等性）

承上：同一筆付款的通知，可能因為網路或重送而來好幾次。你的系統必須認得「這筆我已經處理過了」。

沒做防呆，同一張訂單就會出貨兩次、扣兩次庫存、寄兩封確認信，客人一頭霧水，你還倒貼成本。

7.金額用了小數或浮點數

台幣金流只收整數。金額傳成 199.00，或程式算出 199.9999 這種浮點誤差，都會出事。

格式不符時交易可能被拒絕；計算若使用浮點數，也可能造成訂單與對帳金額不一致。

8.訂單編號重複、或可以重複使用

每筆交易的訂單編號必須「唯一、而且用過就不能再用」。

一旦撞號，金流會擋掉新交易，客人想付錢卻一直失敗；或者舊的付款連結被重複使用，造成金額糾紛。

9.沒規劃退款、取消、關帳前後的差異

信用卡在「當日關帳前」是取消授權、關帳後是退刷，兩者流程不同；超商代碼、ATM 轉帳又各有自己的規則。

上線前要確認取消、退款與對帳流程，以及商家端由誰負責操作，避免收到退款需求時才臨時查找。

10.把信用卡號存在自己的伺服器

一般網站可使用金流商的代收頁面或安全元件處理刷卡資料，避免自行接觸或保存完整卡號。

若系統需要處理持卡人資料，會涉及 PCI DSS 等安全要求。實作方式應依金流商文件與專業資安建議確認。

金流驗收應包含付款成功、付款失敗、重複通知、分頁中斷、退款與對帳等情境。

所以——你真的要自己串嗎？

AEL TECH 在規劃含金流的網站時，會把背景通知、檢查碼驗證、防重複處理與對帳方式列入測試，不把「付款畫面有跳轉」當成完成。

實際金流仍應使用商家自己的金流帳戶，網站服務商不代收交易款項；權限、退款與對帳責任也應在上線前確認。