不同意接收推廣，顧客仍可完成付款嗎？

拒絕推廣也要有路可走

驗收時，店主要看的不是開發人員說「已改成自願」，而是實際操作結果：拒絕推廣後，訂單是否成立、付款是否成功、確認訊息是否照常送達？有些問題藏在建立帳戶的一頁，另一些則在付款時才彈出錯誤。先沿着現有購物流程找出阻礙，未必需要換掉整套網店系統。

私隱專員公署個案 2024C06 涉及一間寢具公司：網店要求顧客先勾選直接促銷同意欄，否則無法完成付款。公司其後按公署建議修改頁面，讓顧客自行選擇。公署指出，捆綁同意令拒絕變得不可行，可能構成不公平收集資料。這是公署公開的個案，並非 Astera 客戶經驗，也不能用來推斷罰款或替其他網店作合規保證。

把交易所需與推廣選擇分開

先把用途逐項拆開：送貨地址用來安排配送，電郵可用來通知訂單進度，推廣訊息則另作選擇。若交易條款需要確認，應有獨立的操作位置，別把條款、私隱聲明和接收優惠全部塞進一個必須勾選的欄位。香港顧客常用手機付款，繁體中文標籤換行後，仍須看得到「自願」等關鍵內容；英文版也要分別檢查，不能只驗收其中一個語言。

維護預算有限，可以先考慮在結帳頁保留一個預設不勾選的推廣選項；也可以完成購買後才邀請訂閱，但邀請不能擋住收據或訂單確認。兩種做法的取捨，是結帳頁的複雜程度及後續維護工作。如果現有接駁無法可靠保留拒絕結果，修復期間可先停止從結帳新增推廣訂閱。這些屬於功能設計建議；實際聲明涵蓋甚麼資料、用途及通訊渠道，仍要由負責私隱的人員或顧問核對。

用同意與拒絕兩條路徑驗收

請開發人員用測試顧客、獲授權的測試結帳環境及隔離郵件環境操作，不要向真實客戶寄測試推廣。以下各項都要在繁中、英文，以及網店支援的手機和桌面流程重做；若同時提供訪客及會員結帳，也須涵蓋。比較同意與拒絕時，貨品、配送方式及付款測試條件要相同，避免把缺貨或付款失敗誤判成同意欄位的問題。

逐項另記實際結果及證據。此表是建議測試，並非任何網店的實測成績。

追到名單系統才算完成

不要只收一張前台截圖。請開發人員沿同一位測試顧客，展示提交的選擇、後台保存的紀錄，以及名單系統最後的訂閱狀態。驗收紀錄可列出測試編號、時間、語言、聲明版本、選擇的渠道及最終決定，並訂明證據的存取和保留安排。若訂閱還需要確認電郵，必須分清「待確認」與「已啟用」。接駁回覆成功，只代表請求獲接收，還要查看自動推廣流程有沒有排除拒絕或已退訂的聯絡人。

回頭客的選項不能靠開發人員猜意思。請負責私隱的人員先確認：畫面上的選擇應如何處理既有偏好？再把決定寫成清楚的欄位說明及測試個案。這份驗收表不判定過往同意是否仍然有效；顧客亦應有清晰的途徑管理通訊偏好。接駁測試可另設一個情境：測試顧客先退訂，系統其後才收到較早排隊的同意事件。此項測試的預期結果訂為「維持退訂」，並到名單系統核對。請開發人員展示如何辨別事件先後，而不是只按訊息抵達時間更新狀態。服務確認與自動推廣應分開處理，讓這位測試顧客仍能收到收據。

把結果交成一份可執行的修改單

下一步可直接開一張修改單：附上目前卡住交易的位置、已確認的雙語文案，以及這份留有證據欄的驗收表。同時指定誰負責結帳、誰負責名單欄位對應，別讓問題停在兩個供應商之間。通過的條件是拒絕後照樣買到貨，而且經重試、同步後仍不會被新加入推廣流程。任何一項失敗，就記錄原因，修復後重測相關路徑。這次驗收只處理購物與推廣選擇的關係；資料收集、保留及存取等較廣的要求，應另作私隱檢視。