電商購物流程怎麼設計？購物車、結帳、付款與訂單驗收指南

顧客按下「加入購物車」之後，頁面的任務便從介紹商品轉為完成交易。此時最容易造成困惑的，往往不是畫面風格，而是優惠突然不適用、運費最後才出現、付款跳轉後不知道訂單是否成立，或填錯一個欄位就失去前面輸入的內容。

一套可靠的電商購物流程，要讓價格、商品、付款與訂單狀態前後一致，也讓顧客知道「目前發生什麼、資料是否保留、下一步可以做什麼」。本文整理設計、開發、營運與客服可共同驗收的做法；它不保證成交結果，但能減少可避免的歧義。

封面是 AI 生成的電商購物流程編輯示意，呈現跨裝置的商品摘要、運費、總額與配送資料，非客戶作品、真實後台或交易紀錄。圖中的英文與金額只供情境說明，不是台灣商店的完整結帳規格，也不代表付款成功、訂單成立或轉換成效；實際狀態須依金流與訂單資料驗收。

一、購物流程要從加入購物車後逐步核對

二、購物流程驗收示意

下表為非客戶介面的流程示意，可用來盤點購物車、結帳、付款與訂單節點；實際欄位及狀態仍須依商店、金流、物流與後台設定。

下圖為教學示例，非客戶交付，讓商品小計、折扣、運費與總額在送出前可逐項核對；範例金額不代表任何商店的實際售價。付款回傳延遲的畫面，則在後文的情境驗收中另行說明。

三、先畫狀態，不要先畫結帳頁

開稿前先列狀態圖：購物車、填寫資料、確認、前往付款、付款回傳、訂單成立，再延伸到待付款、備貨、出貨、送達、取消與退款。不同商店未必具備所有節點，重點是列完實際狀態，不套固定步驟。

每個狀態至少要回答四件事：後台目前認定的事實、顧客看到的文字、此刻允許的動作，以及下一次狀態改變由誰觸發。畫面名稱不能代替狀態，例如顧客回到「付款完成頁」，後台仍可能等待金流確認；若前台先宣布成功，客服與出貨端就會得到不同答案。

四、購物車要能編輯，也要說明變動

購物車中的每一列，都要能辨認商品名稱、版本或規格、數量、單價與小計。若顏色、尺寸、口味、組合或贈品會影響庫存與價格，不能只留一張無法確認版本的縮圖。修改數量、移除商品或改選規格後，總額要立即依同一份規則重算；刪除若可復原，也應說明復原範圍與時限。

顧客停留期間可能遇到庫存不足、價格更新、訂購上限或活動結束。系統應指出變動品項、目前狀態，以及移除、改量或返回選購的路徑，不可只在最後顯示「無法結帳」。購物車若會跨裝置或登入後合併，也要定義重複品項與失效優惠如何處理。

五、優惠、運費與總額要由同一套規則計算

優惠碼可能出現可用、不適用、已使用、已過期、門檻未達或指定商品排除等狀態。提示應說明當下未成立的原因與可修正方法，而不是只有「優惠失敗」。會員價、滿額贈、組合折扣和免運門檻若能並用或互斥，也要在顧客送出訂單前看得懂。

金額區應分層呈現商品小計、折抵、運費、其他費用與應付總額。切換配送、付款或優惠後，摘要與後續付款頁必須同步。計算順序由營運端提供正式規則，設計與開發再以相同測試資料核對。

六、結帳表單只收完成交易需要的資料

先確認訪客能否購買、何時需要登入，以及會員資料可以帶入哪些欄位。購買人、收件人與發票資料若有相同內容，可提供明確的沿用選項；但取消勾選後仍要讓使用者知道哪些欄位將被清除或保留。選填、必填與用途要直接標在欄位附近，不以星號讓人猜。

手機版要實測地址選擇、長姓名、電話格式、鍵盤展開、自動填入和返回上一頁。欄位若依配送或發票選項改變，焦點順序也要同步，不可落到已隱藏控制項。平台功能與資料串接應在 客製化網站功能規劃階段確認，設計稿不能假設系統一定支援。

七、配送、取貨與發票選項要依條件展開

宅配、門市取貨、特殊溫層或其他方式，各自可能有不同地區、費用、付款與商品限制。先選配送方式，再顯示真正需要的地址或門市欄位；選項不可用時，要在原位置說明原因。預計出貨或到貨資訊應依品牌可承諾的資料呈現，不能把未確認的日期做成保證。

發票選項要依實際開立方式與系統規格設計。載具、捐贈或公司資料若非當次選項所需，就不應同時攤開；切換後保留可合理沿用的資料。名稱、格式與錯誤條件由營運、會計或服務供應商確認，設計端不代填規則。

八、付款不是一個成功頁：回傳、逾時與重複操作都要設計

顧客離開網站前往外部付款服務時，要知道訂單內容是否已保留、完成後如何回站，以及中途關閉會發生什麼。回站後至少區分處理中、成功、失敗、取消與逾時；「沒有立即收到結果」不等於失敗，也不應要求顧客立刻重新建立一張訂單。

付款送出後要有可辨識的處理狀態。重新整理、上一頁、多分頁或從銀行應用程式返回時，前台仍須依訂單事實顯示結果。避免重複扣款與訂單是平台、工程和金流端的技術責任；設計交付列出情境與預期畫面，不宣稱僅靠介面即可解決。

情境驗收：銀行已扣款，商店還沒收到回傳

先設定測試金流已成功、商店原訂單仍等待確認，讓測試者返回網站。預期畫面應說明「付款結果確認中，請先不要再次付款」，保留原訂單識別並提供查詢或客服入口；前台此時不能自行判為失敗或重建訂單。

工程與金流窗口用同一交易識別核對回傳及查詢結果；確認成功後更新原訂單，重複回傳不得產生第二筆付款或訂單。若通知寄送失敗，應重試通知，不回退已確認的付款。只有確認原付款可安全重試後，才讓顧客從原訂單繼續。把畫面、訂單筆數、付款紀錄與通知結果一起列入驗收，才能驗證整條流程。

九、送出訂單前，讓顧客重新確認交易內容

最後確認區應列出商品版本、數量、價格、折扣、運費、總額、配送與付款，以及必要的收件資料。編輯入口回到對應區段，修改後再計算；最終按鈕也要表明按下後會建立訂單、進行付款，或只是前往下一步。

數位發展部公布的 零售業等網路交易定型化契約應記載及不得記載事項 ，列出企業資訊、商品資訊、訂約前確認機制、交付方式、付款說明、運費、解除權與爭議處理等項目。它適用於規範所述的零售業等網路交易定型化契約；特定產業仍可能有其他要求，不能因畫面放入幾個欄位，就直接宣稱已符合所有法律義務。 也應對照全國法規資料庫的 消費者保護法 及個案適用規範；本文不是法律意見。

十、錯誤訊息要幫人修正，不要把資料清空

好的錯誤訊息會指出哪裡有問題、為什麼無法接受，以及可以怎麼改。例如門市停止服務時，應保留其他正確資料並引導重選門市；付款未完成時，則要呈現訂單目前狀態與安全的下一步。只用紅框、頁首一句「資料錯誤」或送出後把畫面清空，都會讓修正成本變高。

W3C 的 Web Content Accessibility Guidelines (WCAG) 2.2 ，對輸入用途、錯誤辨識與建議、重複輸入、狀態訊息，以及法律或財務交易送出前的檢查、確認或修正提出可測試準則。專案可把相關準則轉成表單驗收項目，但完成幾項檢查不代表整站已取得無障礙認證或達成完整等級。

十一、訂單成立後，狀態與通知仍是購物流程

完成頁至少要提供訂單識別、目前付款狀態、下一個處理節點與客服入口。待付款、付款確認中、已付款、備貨、已出貨、已送達、取消和退款不應混成同一個「處理中」；若付款與出貨由不同系統更新，也要讓顧客看見最後更新時間，而不是靠猜測資料是否停住。

網站與品牌啟用的通知通路，應從同一份訂單事實產生文字。通知失敗不能改寫訂單狀態，重送也別讓顧客以為多了一筆交易。訊息只帶辨識與下一步所需內容，詳細個人與付款資料留在受控環境。

十二、跨裝置驗收要用真實任務，不只看靜態稿

驗收腳本應使用接近正式資料長度的商品名、地址與選項，分別走訪客、會員、手機與桌機。除了正常付款，還要測返回、重新整理、多分頁、網路中斷、優惠失效、庫存或價格改變、外部付款應用程式返回，以及付款完成但結果仍等待確認等情境。

測試使用測試用姓名、電話、地址與測試付款環境，分享畫面前遮蔽識別碼。重現問題要記錄裝置、瀏覽器與操作順序，才能判斷源自文案、介面、資料同步或外部服務，不把異常都歸為「使用者操作錯誤」。

十三、交付一張狀態表，讓設計、開發、金流、物流與客服對得上

交付不以固定頁數計算，而看狀態是否完整。狀態表包含觸發條件、顧客文案、允許動作、資料來源、備援方式與負責人，再附手機、外部跳轉及錯誤原型，供開發估工與客服準備。

委託前可用網頁設計公司評估與驗收清單 確認合作方是否願意釐清平台限制、金流與物流串接、例外畫面及上線測試責任。視覺設計、系統開發與第三方服務各有邊界，但顧客只會經歷同一條流程，因此交付文件必須說清楚交界由誰接手。

十四、電商購物流程常見問題

十五、把每一個「不知道現在怎麼了」改成可確認的下一步

電商購物流程的專業，不在於把結帳壓成固定幾步，而在於商品、金額、資料、付款與訂單事實始終一致。若正在盤點購物車、結帳與跨裝置驗收，可先查看法西納的 設計服務範圍，再帶著現行平台、付款配送條件與已知異常聯絡法西納 ，共同界定需要設計、開發或營運調整的部分。