先建立一份可核對的優惠規則
「九折」這種宣傳字眼不足以讓結帳系統判斷優惠。每個活動要記下折扣類別、適用商品或系列、顧客群或市場限制、開始與結束時間、最低消費、使用次數，以及能否與其他優惠同用。把核准的對客文案與設定放在一起，市場推廣、客服和結帳才會依據同一份規則。Shopify 區分商品、全單及運費折扣，也把優惠碼與商品原價劃線後顯示的減價分開。若使用其他平台，應先按其實際功能映射規則，再公布承諾。優惠碼在後台存在，不代表所有顧客和購物車都適用；真正資格要在當下計價時判斷。
講清楚優惠按哪個金額計算
最低消費條件須明定按合資格商品、整張購物車商品小計，還是套用另一項折扣後的金額判斷；運費和稅項是否計入門檻及最後應付額，也須按實際規則處理。宣傳承諾若取決於這些條件，就不能把它們藏作純技術細節。指定款式九折與全單九折不同，固定減額只扣一次亦不同於每件都扣。Shopify 文件分開商品、全單及運費優惠，並說明可以指定商品款式。購物車變更時，要根據當前貨品重新計算，不能沿用上一畫面的折扣數字。顧客應能看見哪些貨品真正獲得優惠，而不只是總計位置突然少了一筆。
把時區和使用限制寫進規則
優惠碼在某個時區的午夜啟動，對另一個地區的顧客未必同一刻有效。記下平台後台所用時區，活動文案寫清本地截止時間；跨境銷售尤其需要這一步。Shopify 說明折扣的結束日期與時間按後台顯示時區計算。使用限制亦要分清「整個活動最多使用幾次」和「每位顧客一次」，兩者不是同一規則。顧客在截止前打開結帳頁、截止後才提交時，系統會怎樣處理，應在所用平台實測，不要假定購物車會鎖定資格。訂單成功接受時適用的條款要留底。若代碼顯示用盡卻找不到完成訂單，先查未完成結帳有否暫時佔用名額，勿立即指稱顧客已使用。
疊加優惠要雙向設定
店舖可能容許商品優惠與免運費同時使用，卻不容許同一件貨品重複打折。先用簡單矩陣列出准許的組合，再與平台設定逐項比對。在 Shopify，每項涉及的折扣都要容許該組合，而且部分組合受商戶資格或方案限制；因此「所有優惠碼都可疊加」是危險承諾。檢查時要包括自動優惠，因為顧客輸入代碼前，購物車可能已自動減價。若兩項優惠不能同用，結帳頁要指出實際採用了哪項、另一項為何排除。客服應看得到相同的代碼和購物車狀態，毋須猜測顧客看過哪則廣告。除了常見情況，還要測算所有合資格優惠同時出現時的最終金額。
拒絕訊息要指出可修正的條件
代碼有效但購物車缺少合資格貨品時，只顯示「優惠碼無效」並不足夠。介面要區分代碼不存在、已過期、顧客資格不符、商品被排除、未達最低消費、使用次數已滿，以及與其他優惠衝突。解釋須足以幫助真正顧客，同時避免洩露私人會員分類或他人使用紀錄。Shopify 常見問題也分別列出代碼不存在、不適用於購物車貨品及不能疊加的訊息。自建結帳頁可用不同字眼，但應遵守同一原則。顧客編輯購物車時可保留已輸入代碼，惟每次都要重算並說明變化；失效後不能繼續顯示已劃掉的舊總額。最後確認與實際支付請求須對應伺服器的現時計算。
用一張示例購物車演練
假設一張純示例購物車有一件合資格外套，售價港幣四百元；一件不合資格配件，售價一百元；另有四十元送貨費。若商戶核准的條款只是外套九折，沒有運費優惠，商品折扣便是四十元，商品小計變成四百六十元，送貨費仍是四十元；是否另有適用稅項，須按真實交易處理。這只是自設數字的算術練習，並非任何店舖的實際價格。移除外套後，可保留輸入的代碼，但已套用優惠應歸零並說明原因。再加入免運費代碼時，能否疊加要看商戶核准設定及平台資格，不能預先保證一定成功。驗收要同時測試可用與不可用路徑。
付款界線只接受一致的金額
結帳顯示、儲存的訂單和送交支付服務商的金額，必須來自同一個權威計算。顧客提交訂單時要重新核對資格，因為購物車、登入身份、時間或優惠名額可能在先前顯示有效後改變。付款失敗不等於成功使用優惠；不能只因顧客按過「付款」就記為已兌換。Shopify 文件說明未完成結帳可暫時佔用代碼名額，付款被拒後通常釋放，但整合問題仍可能令佔用未解除；自建系統須設計自己的預留及釋放規則。若金額改變，應在再次付款前讓顧客明確檢視，不能暗中收取高於畫面顯示的款項。訂單還應記錄規則版本和逐項折扣，方便客服重建爭議。
活動文案與設定必須同步
優惠上線前，把電郵、社交帖文、商品頁及結帳字眼與後台設定並排閱讀。宣傳若寫「全店適用」，代碼卻排除一個系列，應在發送前改正其中一方。若活動連結會自動帶入代碼，要測試顧客能否移除，以及它與購物車已有優惠怎樣互動；Shopify 指出分享連結帶入的代碼可留在購物車，能否疊加仍按設定決定。不要把某張示例購物車的折扣總額放進廣告，令所有人以為都能獲得同額。內部核准應有日期及修改權限紀錄。活動結束後，要同步更改對客文案與客服指引，免得仍有流量的頁面繼續宣傳過期優惠。
用精簡而足夠的情境驗收
驗收表每列對準一條規則邊界：合資格與被排除商品、低於與剛好達到最低消費、截止前後、合資格與不合資格顧客、未用盡與已用盡代碼、單一優惠及互相衝突的兩項優惠。再加入手機結帳與帶着舊購物車回來的顧客。每列在測試前先寫預期的逐項折扣、畫面說明、訂單總額和支付金額，避免測試員把看似合理的錯數當成通過。商品系列、市場或疊加設定一改，就要重測。若平台限制令活動根本做不到，應修改活動條款，而不是掩飾結帳失敗。本文沒有真實兌換成效數據；真正要驗收的是顧客能理解價格變化，再決定是否落單。
指派優惠規則變更負責人
優惠上線後，即使無人直接修改優惠碼，活動仍可能失效：商品調整後離開合資格系列、市場設定改變可用範圍，或另一團隊啟動了與活動衝突的自動優惠。應由一名負責人管理優惠規則紀錄，在相關商品目錄、定價或結帳設定變更前做簡短影響檢查。保存誰在何時為何修改設定的紀錄，並留下一張能展示核准結果的示例購物車。客服收到投訴時，可重做相同購物車，辨別是文案誤導、設定漂移，還是顧客確實不合資格。修正時要同時更新源頭規則及對客說明。私下發一個補償代碼或可解決單一個案，但不能掩蓋整個活動令合資格買家普遍失敗。
讓客服能重現爭議
顧客表示優惠碼不能使用時，客服可收集代碼、購物車商品及款式識別、數量、市場、按權限可見的顧客資格、大約嘗試時間及畫面訊息。不要要求完整卡號或含敏感付款資料的截圖。用相同條件在測試結帳重做，再把平台設定與已宣傳條款比較。若顧客已完成訂單但沒有得到應有優惠，按已公布條款決定是否由獲授權人員作出調整；決定要連回訂單，不可暗中改寫歷史售價。若訂單未完成，就明確指出可以修正哪個條件，或承認店舖設定有誤。顧客得到可用答案，而且根本問題已有負責人後，個案才算結束。
上線前核對
- 活動文案是否與商品範圍、時間及使用限制一致？
- 優惠不能疊加時，是否說明實際採用了哪項？
- 畫面、訂單及支付請求的金額是否一致？
