付款流程的程式碼通常不長，但失敗的方式很多。用一組成功卡號走完一次結帳，只證明了一條路徑；真正讓客服忙起來的問題，幾乎都藏在拒付、逾時、重試與使用者的奇怪操作裡。這份支付表單測試清單把值得涵蓋的情境整理成一張可以逐項勾選的矩陣，適合在每次改動結帳相關程式碼時拿出來對照，也適合當成上線前的最後一道檢查。
開始之前先確認三件事
第一，測試環境裡沒有任何真實卡號。 測試用的號碼應該是合成或服務商提供的測試憑證，理由不只是安全，還包括合規層面，詳見 PCI DSS 測試資料。
第二，測試資料是可重現的。 固定一組號碼並寫進版本控制，而不是每次執行都重新隨機產生。這一條能省下大量「昨天明明會過」的除錯時間。
第三，準備好各卡組織的代表號碼。 至少涵蓋 Visa、Mastercard 與美國運通，因為它們在長度與安全碼位數上不同；整理見各卡組織測試卡號。
該用哪些軸線組出測試矩陣
不要只想著成功與失敗兩種結果。把付款拆成幾條彼此獨立的軸線，再從中挑組合，涵蓋率會比隨機亂試高得多。
| 軸線 | 需要涵蓋的值 |
|---|---|
| 授權結果 | 成功、拒付、需要額外驗證 |
| 請款狀態 | 未請款、全額請款、部分請款 |
| 訂單金額 | 最小值、正常值、邊界值（例如零元或極大值） |
| 網路狀況 | 正常、緩慢、逾時、中途斷線 |
| 使用者操作 | 正常送出、重複點擊、返回上一頁、重新整理 |
不需要把每一格都測過一次，但每一條軸線至少要有一個案例，而且失敗的組合要優先於成功的組合。
拒付之後，哪些事情必須是對的？
拒付是付款流程裡最常被低估的部分。要驗證的不只是「有沒有出現錯誤」，還包括：
- 錯誤歸因正確。 額度不足、卡片失效、安全碼錯誤、需要額外驗證，四種情況的提示應該不同，讓使用者知道下一步能做什麼。
- 不以原始代碼示人。 使用者不該看到金流服務商的原始錯誤代碼，也不該看到未經整理的技術回應。
- 購物車狀態合理。 拒付後訂單不應標記為完成，購物車內容應保留，讓使用者能直接重試。
- 畫面與網址不留敏感資料。 錯誤提示與瀏覽器位址都不應包含卡號或安全碼。
- 不會因為重試而重複建單。 連續兩次失敗之後的成功交易，訂單數量必須是一筆。
第五點和下一節的冪等性直接相關，也是最容易在真實環境造成重複扣款的問題。
逾時與重試為什麼最棘手？
當請求逾時，使用者與系統都不知道那筆交易到底成不成功。這是付款流程裡最難處理的一類狀況，因為兩種猜測都可能錯。測試時要確認：
- 送出按鈕立即停用。 從按下到收到回應之間，按鈕不應能再次點擊，避免連點產生兩筆請求。
- 請求帶有冪等鍵。 同一次結帳嘗試重送時，閘道應能辨識為同一筆，而不是產生第二筆授權。
- 逾時後的行為明確。 系統應有超時上限，並在逾時後進入查詢狀態，而不是直接重送扣款。
- 重試有次數上限與退避。 自動重試若沒有上限，會在下游故障時把問題放大。
- 網路中斷可恢復。 使用者重新整理頁面後，能查出前一次嘗試的結果，而不是只看到一張空白訂單。
這幾項很難靠手動點擊驗證，建議寫成自動化測試，並以模擬延遲的方式執行。
退款與部分請款也要納入
退款常被視為後台功能，但它與前端的狀態顯示密切相關。要涵蓋的情況包括：
- 全額退款後，訂單頁與收據頁正確反映已退款的狀態。
- 部分退款後，剩餘金額與退款紀錄都正確，且不影響原交易的紀錄。
- 重複退款時，系統應阻擋或至少提出警示。
- 先授權後請款、且請款金額少於授權金額的流程符合業務需求。
- 退款透過代碼化憑證發起，而不是要求重新輸入卡號。
最後一點若沒處理好，會逼客服在電話中向持卡人索取卡號，而這正好違反「不要在客服流程裡處理真實卡號」的原則。
3D Secure 會多出哪些分支
牽涉持卡人驗證的流程有額外的分支，需要逐項確認：
- 驗證頁返回後，訂單狀態是否正確更新（實務上最常見的缺失）。
- 使用者在驗證頁中途關閉視窗或按返回時，訂單是否停在待付款而非已完成。
- 驗證逾時時的提示與後續選項是否合理。
- 在行動裝置的應用程式內建瀏覽器與外部瀏覽器中的行為差異。
- 驗證期間重複送出，是否產生重複訂單。
這整條路徑只有特定的測試憑證會觸發，相關說明見 Stripe 測試卡。
給開發者：欄位層級與無障礙的自查
把每個欄位當成獨立的驗證單元逐一檢查，通常能在上線前抓到不少問題。
- 卡號欄位：長度與前綴依卡組織變化，13 至 19 位都要能接受；美國運通是 15 位。
- 有效期限欄位：到期月的最後一天仍然有效，這個容易寫錯的邊界務必測試，做法見信用卡有效期限格式。
- 安全碼欄位：三位與四位都要能輸入，且送出後不得被回傳或記錄。
- 持卡人姓名：需要支援非拉丁字元與較長的姓名，並容忍多餘空白。
- 貼上行為：貼上帶有空格的卡號時，應能正確解析；全形數字應被轉換或明確拒絕。
- 標籤與錯誤訊息：必須與欄位正確關聯，讓螢幕閱讀器能讀出是哪個欄位出錯。
- 錯誤狀態：不能只靠顏色表達，需要文字或圖示輔助。
- 鍵盤操作：要能完整走完流程，包含選單與驗證頁返回。
- 自動填入：欄位要標示正確的用途，讓瀏覽器與密碼管理員把卡片資料填到對應欄位；填錯欄位是最常見的自動填入問題。
- 錯誤訊息的位置：應出現在焦點所在處附近，避免使用者需要往上捲才看得到失敗原因。
要在每次改動後重跑這份清單，先把測試資料固定下來。用信用卡號產生器選定卡組織批次產生一批號碼，存進固定裝置檔並加上註解，之後就照著這張清單逐項勾選。這些號碼結構正確、卻從未發行，只適合測試用途，無法完成任何實際付款。
下一步
先挑出這份清單裡風險最高的兩三項，例如拒付後的狀態更新與逾時重試，在這次迭代就補上自動化測試，而不是等上線前一次補齊。若還不確定測試資料該從哪來，接著讀 PCI DSS 測試資料那一篇；要理解各卡組織的欄位差異，讀各卡組織測試卡號那一篇。