第三方支付上線前測試清單：付款成功、失敗、取消、逾期都要驗證
金流串接完成後正式上線前，要測哪些情境？本文整理付款成功、失敗、取消、逾期、重複通知與退款的測試方法，避免上線第一天就出包。
金流上線前至少要測試六種情境：付款成功、付款失敗、客人中途取消、超過繳費期限、重複通知，以及退款。只測「付款成功」就上線，是最常見也最昂貴的錯誤，因為真正的問題多半出在例外情境，例如客人已付款但訂單顯示未付款，或同一筆訂單被重複出貨。把下列測試做完，並留下紀錄，能大幅降低上線後的客訴與帳務爭議。
為什麼要有完整的測試
金流牽涉真實金錢，一旦出錯就是客人與你的實際損失，而且很難在事後完全補救。測試的目的是在受控環境中確認：每種付款結果都能正確更新訂單狀態、通知客人、保留紀錄，並讓帳務可核對。大多數業者提供測試環境與測試用的卡號或帳號，請務必先在測試環境完成驗證，再切換到正式環境。切換時，要特別注意正式環境與測試環境的商店代號、金鑰與回傳網址不同，不要把測試參數帶到正式環境，也不要把正式金鑰留在測試環境。
六大測試情境
| 情境 | 要驗證什麼 | 預期結果 |
|---|---|---|
| 付款成功 | 訂單狀態、庫存、通知信、發票 | 狀態更新為已付款，客人收到確認 |
| 付款失敗 | 錯誤訊息、訂單狀態、庫存 | 訂單維持未付款，客人可重新付款 |
| 客人中途取消 | 取消後的導回頁面與訂單狀態 | 訂單取消或保持待付款，庫存正確 |
| 超過繳費期限 | 逾期後系統處理 | 訂單自動取消並釋放庫存 |
| 重複通知 | 同一筆付款通知收到多次 | 只處理一次，不重複出貨或開票 |
| 退款 | 退款流程、金額與狀態 | 訂單狀態更新，金額正確，帳務可對 |
逐項測試怎麼做
付款成功：用測試帳號完成一筆付款，檢查訂單狀態是否更新、庫存是否扣減、客人是否收到通知、發票是否正確開立。同時用業者後台確認這筆交易已被記錄，金額與訂單一致。
付款失敗：模擬刷卡被拒、餘額不足等情況，確認客人看到明確的失敗訊息，且可以重新嘗試或改用其他方式，訂單不會被誤判為已付款。
客人取消：在付款頁面按取消或關閉視窗，確認系統不會誤判，訂單維持適當狀態，庫存不被永久鎖定。
逾期：對超商或 ATM 這類有期限的付款，建立訂單後不付款，等到期限過後，確認訂單自動取消並釋放庫存。因為要等到期限，這項測試要提前安排時間。
重複通知：手動重發同一筆付款通知，確認系統不會重複處理。這是自行串接最容易遺漏的地方，需要訂單狀態檢查或唯一性限制。
退款：測試部分退款與全額退款，確認金額、訂單狀態、電子發票折讓與客人通知。同時查看業者後台，確認退款紀錄正確。
如何記錄測試結果
測試不只是跑一遍，還要留下可重複查證的紀錄。建議做一張簡單的測試表，每一列是一個測試案例，欄位包含：測試日期、測試人員、測試情境、使用的訂單編號、預期結果、實際結果、是否通過與備註。若發現問題，要記錄重現步驟與截圖，修正之後重新測試同一個案例，直到通過為止。
測試時還要特別留意一些邊界狀況：金額含小數或很大的訂單、訂單中包含特殊字元的商品名稱、客人短時間內連續按下付款按鈕、同一位客人在不同裝置同時付款、以及在付款頁面停留很久才付款。這些情況在平常使用中不常見，卻是最容易觸發意外的地方。若你的商店有優惠券、運費與稅額的計算，也要確認傳給業者的總金額與你網站顯示的金額完全一致，差一塊錢都可能造成驗證失敗或對帳困擾。
最後，建議由非開發者的同事或朋友，以一般客人的角度，從商品頁開始一路走到收到確認信，看看流程是否順暢、說明是否清楚。這種「外行人測試」常常能發現工程師看不到的使用性問題，例如按鈕太小、提示不清楚、付款失敗後不知道怎麼辦等。
安全與資料檢查
除了功能測試，也要做基本的安全檢查：
- 金鑰是否只存放在伺服器端，沒有出現在前端程式碼或公開程式庫。
- 背景通知是否驗證簽章，並核對金額與訂單編號。
- 網站是否全站使用 HTTPS。
- 日誌中是否避免記錄完整卡號等敏感資料。
- 個資的蒐集、儲存與使用是否符合《個人資料保護法》，並在隱私權政策中說明。
上線當天與上線後一週
首次正式上線時，建議自己用小額真實交易走一遍完整流程，包括付款與退款，確認款項確實出現在業者後台與後續撥款中。上線後第一週，要每天核對訂單、業者後台與銀行入帳三方的資料，並密切注意客服訊息，快速發現沒預料到的問題。
建議同時準備一份「緊急應變清單」：若付款功能出錯，可以暫時切換回備用付款方式或關閉結帳；負責人與工程師的聯絡方式；業者客服的聯絡管道與緊急處理方式。有這份清單，出事時才不會慌亂。
客服與退款流程也要預演
很多團隊只測系統，卻忘了測人。上線前請讓客服人員實際操作一次：客人說付款了但訂單沒更新，客服要到哪裡查詢？客人要求退款，客服要怎麼發起、需要誰核可、多久能退回？客人詢問為什麼被重複扣款，客服能否從業者後台查出授權與請款的差異，並向客人說明這可能只是暫時的授權保留？把這些情境寫成標準作業程序，附上截圖，貼在客服共用的資料夾，新人也能快速上手。
常見錯誤
- 只測付款成功，沒測例外情境。
- 把測試環境參數誤帶進正式環境，導致客人實際付款卻沒被記錄。
- 沒有處理重複通知，造成重複出貨。
- 上線前沒有演練退款，結果第一筆退款時才發現流程不通。
- 上線後沒有每日核對，問題累積多日才發現。
常見問題
測試環境可以收到真正的錢嗎？
不能。測試環境使用的是模擬資料，不會產生真實交易。上線前要切換到正式環境，並用小額真實交易驗證。
我可以自己用信用卡測試正式環境嗎？
可以用小額交易測試，但要注意後續退款與手續費處理。建議事先與業者確認處理方式。
上線後發現付款異常，應該怎麼辦？
先暫停有問題的付款方式或結帳流程，避免擴大影響，再聯繫業者與工程人員釐清原因，並逐筆核對受影響的訂單。
需要保留測試紀錄嗎？
建議保留，日後遇到爭議或系統升級時可作為參考，也能幫助新成員了解流程。
