Checkout 流程迴歸 — Stripe → LemonSqueezy 遷移

依時序記錄 — 2 小時 14 分內共 8 項發現

1. !

   Stripe → LemonSqueezy 遷移時折扣碼遺失Severity: high

   00:42:17

   折扣碼 `LAUNCH20` 在 LemonSqueezy 收到 cart payload 時被丟棄。步驟與 payload diff 詳見 §3.2。

   1. 在 Chrome 126（macOS）開啟 /checkout，加入購物車項目
   2. 套用折扣碼 LAUNCH20，確認 line-item 折扣可見
   3. 點擊 Pay → 觀察 LS payload 缺少 discount 欄位
2. !

   地址自動填入覆蓋手動輸入的郵遞區號Severity: med

   01:08:54

   在 Chrome 126（macOS）+ Safari 17（iOS）重現。當郵遞區號與自動填入不符時表單靜默失敗。

   1. 在運送地址表單觸發 Chrome 自動填入
   2. 手動編輯郵遞區號為其他有效值
   3. 提交 → 表單靜默拒絕，無錯誤訊息
3. ✓

   Apple Pay 完整流程 — 通過Severity: low

   01:31:09

   Apple Pay 沙盒 checkout 在 iOS 17 / Safari 17 端到端通過。收據 email 在 SLA 內到達。

   1. 從 /checkout 啟動 Apple Pay sheet
   2. 於 iOS 17 用沙盒帳號驗證
   3. 確認收據 email 60 秒內到達
4. !

   Webhook 在 503 時 retry stormSeverity: high

   02:02:42

   當 LemonSqueezy webhook 接收端回 503 時，retry 策略在 11 秒內觸發 6 次（預期：指數退避）。

   1. 用故障注入強制 webhook 端點回 503
   2. 觀察 retry log — 11 秒內 6 次嘗試
   3. 比對預期指數退避（30 秒內最多 3 次）
5. i

   稅務計算 p95 延遲 = 1.4 秒Severity: low

   02:08:11

   Avalara API 呼叫在購物車更新時加 1.4 秒 p95 延遲。在 SLO 內但值得在 edge cache。

   1. 用新的稅務轄區郵遞區號觸發購物車更新
   2. 在 50 次呼叫上測量 p95
   3. 與快取轄區查詢基準比較
6. ✓

   退款流程 — 三個金流皆通過Severity: low

   02:11:25

   Stripe + LS + Apple Pay 都正確處理部分退款；下次 webhook 對帳簿。

   1. 在管理面板對每個金流發起部分退款
   2. 確認下次 webhook 帳簿餘額更新
   3. 確認客戶通知 email 到達
7. !

   多幣別轉換時購物車總額差 1 分錢Severity: med

   02:13:02

   USD → EUR 換幣中段時浮點運算產生 1 分錢誤差。伺服器總額 ≠ 客戶端總額 0.01。

   1. 加入 USD 商品到購物車
   2. 切換語系到 EU → 轉換為 EUR
   3. 比較客戶端顯示 vs 伺服器總額 — 觀察 0.01 差異
8. ✓

   全部 6 條 SOC 2 必要稽核日誌齊全Severity: low

   02:14:00

   每個 checkout 狀態轉換皆發出含 actor + delta + timestamp 的結構化稽核日誌。

   1. 在 staging 走完整 checkout 流程
   2. tail 稽核日誌，確認 6 條必要轉換已記錄
   3. 交叉確認 actor + delta + timestamp 欄位

報告完整段落

這是真實 Test4All 報告的樣貌 — 結構化、可重現、由資深 QA 工程師親手撰寫。