先釐清確認頁能證明甚麼
訂單確認頁的用途，比發票或物流追蹤頁更集中：告訴顧客商戶收到哪一張訂單、接受了哪些商品與金額、採用何種送貨或自取方式，以及下一步會發生甚麼。頁面也必須反映真實付款狀態。付款導向頁出現，不代表款項已經結算；文字應由後端訂單及付款紀錄決定。如果仍待付款確認，就直說並提供可行的後續步驟。不要習慣性把所有確認頁稱為收據或稅務文件。先決定商戶實際會發出哪些文件，只有文件存在時才提供相關連結。
顧客可能用瀏覽器儲存 PDF，或列印頁面作購物紀錄；即使商戶也發電郵，這仍是合理用途。電郵可能延遲、進入垃圾郵件，或日後無法存取，因此確認畫面本身要有用。另一方面，印出來的頁面也不能依賴目前瀏覽器分頁才能理解。若商品只標「這件」，旁邊靠圖片或顏色辨認；或付款狀態只用彩色圓點表示，一旦列印時圖片或顏色消失，意思便不完整。先建立清楚的文字紀錄，再安排螢幕及紙本版面；不要暗示瀏覽器列印件自動取得某種法律地位。
把交易事實放在一起
確認頁應顯示穩定的訂單編號、接受訂單的日期或時間；若讀者可能身處香港以外，應註明時區。每件商品的名稱要足以辨認，包括實際選擇的尺寸或顏色、數量、單價、真正套用的折扣、運費，以及標明貨幣的總額。這些數字應取自已接受訂單的快照，而非當下商品頁，因為目錄價格及名稱日後可能改變。如展示送貨和帳單地址，須分別標示；共用打印機上的私人資料也不應多於顧客所需。配送方式及已確認的自取點同樣要清楚列出。
訂單、付款與履行是不同狀態。商戶可能已收到訂單，但付款仍待最終確認；已付款訂單可能尚未包裝；已交運訂單則可能已有物流編號。不要以一個令人安心卻含糊的「完成」標記混合三者。分別概述這三項，顧客才知道哪些事實已確定、哪些稍後會更新。列出客服途徑及查詢時需提供的訂單編號，但不要列印登入權杖或私人操作連結。如有修改或取消的適用時段，應按真實政策說明並提供求助路線，不要為了令頁面看似完整而虛構期限。
設計真正可用的列印版
MDN 說明可用列印媒體查詢，為紙本或「儲存為 PDF」設定樣式。可以藉此移走網站導覽、推廣橫額、固定聊天視窗，以及印在紙上沒有作用的按鈕。訂單標題、編號、商品明細、總額、狀態文字、客服資訊，以及理解紀錄所需的條款則應保留。列印版要有易讀的標題層級和欄位名稱，不能只把螢幕版縮小到一張紙上。紙張大小、瀏覽器設定及使用者縮放比例各異；內容太長時應自然延續到第二頁，強迫單頁可能截斷長商品名稱或地址。
頁面上的列印按鈕可以呼叫瀏覽器列印介面，但使用者直接從瀏覽器選單按「列印」，仍應得到同樣重要的紀錄。MDN 也記載列印前後事件，但可靠設計不應依靠事件處理器在最後一刻補上缺失的交易事實；資料應早已在文件中，列印 CSS 只調整呈現方式。檢查商品列與總額附近的分頁位置，避免數字與名稱分離。若連結在紙上仍重要，應給出足夠的目的地說明或簡短穩定網址；PDF 中只有「按此」並無用處。另須測試灰階及停用背景圖的打印設定。
螢幕版也要易用
列印前的網頁同樣要可用。使用清楚的頁面標題和可見的訂單主標題，再以小標題分隔商品、付款、配送和求助資料。W3C 的表單指引強調控制項標籤要說明用途；列印按鈕和修改訂單操作亦應遵循同樣的白話原則。鍵盤使用者應按合理順序抵達操作項，並看得見焦點。螢幕閱讀器使用者須從文字得知訂單編號及付款狀態，不能只靠裝飾圖示推斷。若載入後狀態改變，頁面應顯示當前狀態，而非把舊快照偽裝成即時資訊；必要時提供重新整理或查詢狀態連結。
確認頁的存取路線也要保護。紙本紀錄可能被保存多年，但每次開啟即時網址時，仍須作適當的存取判斷。網址、畫面及列印件都不可包含帳戶工作階段金鑰、付款秘密或完整卡資料。訪客訂單要選擇符合業務流程的存取方法與有效期，不能讓訂單頁永久公開。若顧客日後需要副本，應提供受支援的取回途徑。列印設計無法補救錯誤的存取模式；螢幕頁與保存的文件都需要有意識地檢查私隱。
以較棘手的訂單演練
假設一張訂單有兩件商品、一項真正適用的優惠、運費，而付款仍待確認。顧客從付款供應商返回後看到確認頁。螢幕顯示訂單編號、已接受的商品與金額快照，並直接說明付款待確認及如何查詢狀態。顧客儲存 PDF 時，列印樣式可以移走導覽，卻須保留同樣的付款狀態及金額明細。商戶不能因導向成功便寫成「已付款」。後端核實付款後，即時訂單狀態頁可以更新；已保存的副本則應被理解為建立當刻的紀錄。
再用第二個假設情境測版面：商品中文名稱較長、送貨地址以英文填寫，而且商品列數多到跨頁。這次重點是版面而非付款流程。中文字形要正常顯示，貨幣與數量須緊貼對應商品，客服途徑也要容易找到。用多於一款瀏覽器儲存 PDF，再印出灰階版本，逐欄與螢幕紀錄比較。預覽畫面再漂亮，只要紙本截掉總額最後一行或付款狀態的限定語，就不能算通過。
逐項比較後才驗收
上線前，先為每個顯示欄位指定權威資料來源：訂單快照、付款紀錄、配送選擇，還是即時履行狀態。再用簡短驗收表比較螢幕、列印預覽、PDF 和實體紙張。測試案例應包括付款待確認、付款成功、訪客訂單、多頁商品清單，以及網站兩種語言。檢查可能引起歧義的日期有否時區、金額有否貨幣，所有狀態能否不靠顏色理解。發現缺漏時，應修正頁面或資料對應的根源。最後的確認頁要讓顧客保存及理解，但不能假裝證明尚未發生的事情。
還有一種情況值得單獨核對：配送資格或優惠條件可能令提交前的總額改變，但已接受訂單的確認頁必須使用最後正式確定的金額。瀏覽器若快取了較早的結帳摘要，列印版也不能沿用過期總額。測試付款前更改配送方式，以及優惠變得不適用的情況，再比較已接受訂單紀錄、付款指示與列印頁。若數值不一致，應先釐清資料流程；再精美的列印樣式也無法令矛盾金額變得可信。
進行前先確認
- 頁面有否分開訂單、付款及履行狀態？
- 螢幕、列印預覽、PDF 與紙本的金額及狀態限定語是否一致？
- 訪客日後能否安全取回副本，而不會公開訂單？
