重要訂單確認前，顧客應可核對甚麼？

先找出真正生效的一步

先把購物車、收貨資料、送貨選項、付款授權、商戶接納及最終確認逐步畫出。頁面寫着「核對」不代表交易仍可修改；若款項已扣取或訂單已產生約束，事後顯示收據不能代替事前修正機會。團隊應記錄每個按鈕在付款服務及自家訂單系統實際觸發甚麼。若付款授權後仍可更改貨品，就要查明是否需要重新授權，並向顧客清楚交代。最後按鈕的字眼須描述當刻真正發生的事，例如提交有待確認的訂單，或確認即時付款。預購、稍後付款與待核庫存的流程尤其需要分清狀態，不應把所有確認畫面都當作同一事件。這個流程圖亦應成為設計和測試的依據，而不是單靠頁面名稱判斷風險。

列出會左右決定的資料

有用的核對頁應重現顧客在多步結帳時容易記錯的資料。逐項顯示貨品名稱或款式、數量、單價及小計；列明收貨地址或自取地點、已選送貨方法與有根據的預計時間。實際收款金額及貨幣須清晰呈現，適用的運費、稅項、折扣及附加費應能與總額對上。付款方式可以顯示足以辨識的資料，但不應露出完整卡號。若交易涉及預約日期、收件人留言、客製選項或不可退款條件，亦應在最後決定前重現。重要條款應放在確認操作附近，不能只藏在籠統的「條款」連結之後。版面在手機及放大後仍要容易逐項閱讀，每一組資料要有明確修改入口。核對內容須跟隨實際交易風險決定，不能用一張通用清單省略關鍵選擇。

讓修改可以順利返回核對頁

修改按鈕應帶顧客回到相關欄位，保留先前輸入，完成修改後再返回核對頁展示更新結果。更改送貨地區可能改變可選服務及收費；改變貨品款式可能影響存貨及出貨時間。系統須在伺服器重新計算，並在最終提交前顯示新的總額，不可沿用舊核對畫面的數字。若付款服務已按另一金額授權，也不能默默把原授權套到較高金額的訂單。對格式有效但可疑的輸入，例如明顯異常的數量，可提供具體提示及修正方法。W3C 準則容許在適用情況採用可撤回、檢查或確認的途徑，商戶應選擇真正能營運及測試的一種。只問「你確定嗎」而沒有重現地址或金額的對話框，難以幫顧客發現實際錯誤。

用混合購物籃走一次流程

假設顧客同時購買一般現貨和訂製禮品，並送給另一位收件人。第一次輸入時，顧客選擇送貨上門、填寫收件地址及禮物字句。到核對頁才發現單位號碼錯誤，於是選「修改送貨地址」，只改該欄後返回。店舖根據修正後的地區重新確認送貨服務是否適用，顯示任何更新的運費及預計時間；禮物字句和款式應保持原樣。最終按鈕之前，顧客仍可分辨哪件貨品屬於訂製，以及其適用條件。若原送貨服務已不可選，頁面要求重新選擇，不應代顧客猜測。提交後的確認資訊須如實說明訂單和付款狀態。這是用來驗證設計的假設情境，不代表任何特定店舖採用這些條款，也不能證明只要加一個「確認」步驟便符合所有要求。

測試嚴重錯誤及狀態轉換

測試時應選會真正影響買家的錯誤：數量錯、收件人錯、舊地址、送貨選項錯、優惠變動，以及核對與提交之間貨品售罄。逐項觀察畫面顯示的資料是否與伺服器最後記錄一致。受控測試只提交一次，再分別查看訂單及付款記錄；畫面出現成功訊息，並不足以證明付款服務收取了預期金額。再用鍵盤及屏幕閱讀器走流程，確認修改連結、更新後總額與最後操作名稱容易理解，閱讀次序亦合理。於窄螢幕及放大文字下重試，找出被截斷的核對項目。若商戶改以限時撤回交易來提供保障，應測試真正的撤回方法及期限，不能只假設政策頁存在便足夠。修復時記錄失敗步驟與確切數值差異，讓設計、開發及營運人員能重現問題。

上線前訂明驗收規則

實際可用的上線驗收規則是：顧客知道最後操作會產生甚麼後果，能核對所有重要數值，修正錯誤時不會遺失無關資料，並在承諾前看到重算結果。團隊亦要能把一宗測試交易由核對畫面追到訂單及付款的最終狀態。若此期間條件或金額改變，應停止提交並要求顧客重新作決定。客服須使用同一套狀態用語，避免把付款授權說成已完成收款，或在真正不可撤回的一步之後仍承諾可以取消。這項規則涵蓋資料、時間及實際商業動作，比單純加一頁畫面更有用。本文聚焦介面與流程設計；具體退款權利、合約效力和付款服務行為，均取決於商戶實際條款與整合方式，對顧客作出承諾前必須另外核實。

為最後決定分配責任

核對頁每項資料都應有負責人。商品團隊管理貨品名稱及款式，出貨團隊管理送貨承諾，付款團隊管理收款金額及交易狀態，客服則負責顧客要求更改訂單時使用的說法。請各方指出最後畫面顯示的欄位，以及哪些事件會改變它。若核對頁讀取舊購物車，但伺服器按重算後的購物籃收款，即使兩個元件單獨運作正常，仍會出錯。只有真正等待重新計算時才暫停最後操作，並清楚顯示狀態及失敗後的處理路徑。結果返回後，應明確指出已變動的資料。這也是商戶決定顧客究竟在提交待接納訂單，還是在即時完成付款的交接點，不能讓籠統按鈕掩蓋營運上的差異。

驗收測試可先寫下一宗範例訂單的預期貨品、運費及付款狀態，再按此執行。安排一人修改地址、一人修改數量，另一人讓庫存在核對頁開啟期間變動。每次都記下最後操作前顯示的數值，提交後再與儲存的訂單比較。如兩者不一致，修正資料更新或提交的環節，然後沿同一路徑重試。也要加入取消及付款失敗情況，確認草稿訂單仍可理解，而不會偽裝成已付款交易。這些檢查使承諾可測試，無須虛稱能提高轉換率。核心決定是顧客必須明白甚麼，以及系統在無法如實呈現資料時，應拒絕完成甚麼操作。