換金流那 4 天：21 次進結帳、0 筆成交

太長不看版： 2026-08-31 我們的水蜜桃乾店「桃梨生活」把金流和物流從藍新換到綠界，簽章、幕後通知、物流建單全部驗過才上線，同一天廣告也重新開跑。接下來 8/31 到 9/04，GA4 記到 21 次進入結帳、0 筆付款成交。原因是三處跟著舊金流的設定沒改到：超商地圖按鈕還在送藍新的代碼、物流代碼欄位被截成 2 個字、網站安全設定（CSP）的表單白名單還是藍新的網域。三個都編譯得過、測試抓不到、線上沒有錯誤訊息。現在我們換任何供應商，都會額外把「所有寫了供應商網域的設定檔」掃一遍。

這篇是我們自營店摸索過程的連載之一，格式固定：當時數字、漏在哪、怎麼發現與修、之後怎麼檢查。

當時的數字是多少？

當時的背景：桃梨從 08-17 起藍新被要求另開商店，新商店卡補件，綠界的信用卡收款 08-28 才過審，08-29 金鑰問題才解。08-31 上線那天，我們同時把 Meta 廣告重新打開。也就是說，這 4 天是收款管道卡了兩週之後，第一批重新進來的廣告流量。

21 次進結帳是什麼概念？桃梨最好的一週（09-20 到 09-26）是 7 天 27 筆已付款訂單。進結帳不等於會付款，這兩個數字不能直接比；但 4 天裡有 21 次走到結帳頁，就算只有一部分人真的要付，也不該是 0。（GA4 的 begin_checkout 是「進入結帳」的推薦事件，定義見 Google Analytics 事件參考↗。）

換綠界的時候，漏改了什麼？

加解密那一層我們是重寫的，因為藍新和綠界完全不同（藍新整包 AES 加密，綠界是明文欄位加 CheckMacValue，金流用 SHA256、物流用 MD5）。那一層我們用官方測試向量驗過，沒有出錯。出錯的全部是舊金流留下來、沒人想到要改的東西：

第 3 個最致命。我們的結帳流程是：網站先建訂單，再由前端組一張表單 POST 到綠界收銀台。CSP 的 form-action 規定網頁的表單只能送到白名單裡的網址（MDN：form-action↗），白名單沒有綠界，瀏覽器就不送。結果是：訂單進了資料庫、購物車清空了，客人卻到不了付款頁。畫面上沒有任何錯誤，只有瀏覽器開發者工具的 console 裡一行違規訊息。

我們的紀錄裡有兩位客人的經過看得最清楚。其中一位選宅配，按付款沒反應（CSP 擋掉），3 分鐘後改選超商取貨，點超商按鈕地圖也打不開（第 1 處），最後只能留著原本的宅配地址再試。這位客人一個人就踩到了三個漏改裡的兩個。

驗證都過了，為什麼沒抓到？

08-31 上線前我們驗的東西：

08-31 晚上 22:30 我們做了上線首日巡檢，金流基礎設施全部正常，但也記下一句：從 8/30 起訂單庫只有我們自己的 1 筆測試單，金流能用是靠合成驗證證明的，還沒有一筆真客人的錢走過。

回頭看，四項驗證全部是用程式直接打 API，沒有一項是「一個人用瀏覽器打開結帳頁、點超商按鈕、按付款」。CSP 只在瀏覽器裡生效，用程式 POST 表單完全繞過它；超商按鈕是前端元件，打 API 根本不會碰到它。我們驗證了後端的每一條路，唯獨沒有走客人會走的那一條。

怎麼發現的？怎麼修的？

2026-09-04 發現第 1 處。 看到 21 次進結帳、0 筆訂單的落差，追到超商地圖。線上實測修復前送 t=1 會得到綠界不認識的 LogisticsSubType=1。修法是前端按鈕改送綠界的代碼，另外在地圖 API 加一張舊代碼對照表，因為舊草稿、書籤、貼出去的連結可能還帶著 t=1。

同一天順著同一個漏改找到第 2 處。 把散在四個地方的超商類型處理收成同一支函式，認不得的值一律退回 7-11。理由是寄錯超商客人會反應、還能補救；送一個綠界不認識的值，收了錢出不了貨，最難收拾。

第 3 處是投廣告那一邊的檢查發現的，白名單改成綠界金流與物流的正式站、測試站共四個網域。修完後我們再對一次線上的回應標頭，確認和設定檔一致、沒有被後來的部署蓋掉。

2026-09-05 補救客人。 被擋掉的兩位真實客人，我們各寄了一封「我方系統故障」的道歉信加補款連結，金額分別是 NT$1,150 和 NT$1,990。沒有沿用原本的「提醒你還沒付款」那封信，因為其中一位在 CSP 還壞著的時候已經收過一次，再寄同一封只會更像騷擾。補款連結實測都能進到綠界收銀台。兩位後來有沒有付款，我們的文件沒有記錄。

同一週還修掉兩個相關的問題：一是取貨門市欄位靠瀏覽器原生驗證，沒填時按付款只會捲動、不顯示任何文字，在 FB、LINE 的內建瀏覽器裡更常什麼都看不到，改成頁面上看得到的紅字和下一步指示；二是綠界交易狀態碼 TradeStatus 我們憑記憶寫反了，查官方文件加實測更正。這兩個沒有造成錯誤入帳，但會讓對帳摘要看不出客人卡在哪一步。

之後換金流，我們怎麼檢查？

三處漏改的共同點：都是舊供應商的契約殘留在別的層，編譯得過、測試不會抓、線上靜默失敗。用舊供應商的名字去全專案搜尋，抓得到第 1、2 處；第 3 處搜得到，但你不會意識到 CSP 是金流路徑的一部分。

所以我們現在換任何供應商（金流、物流、追蹤），都多做下面這些：

1. 列出所有寫了供應商網域的設定：CSP、CORS、防火牆、webhook 白名單、重新導向規則，逐條換。
2. 列出所有照舊供應商值域定的欄位：長度上限、列舉值、代碼對照表。新供應商的值放得進去嗎？
3. 用真的瀏覽器走完每一條付款方式 × 配送方式，不是用程式打 API。桃梨是 7 種付款方式 × 超商四家＋宅配，至少每種配送方式要真的點到收銀台頁面。
4. 加測 LINE、FB 的內建瀏覽器。 我們的流量來自 FB 廣告和 LINE 官方帳號，整理綠界串接注意事項時就把內建瀏覽器付款失敗列為高風險，另一家店也實測過內建瀏覽器送不出去，要引導客人用外部瀏覽器開。
5. 舊代碼留一張對照表，不要直接刪。客人手上的舊連結還會帶舊參數進來。
6. 上線後每天對一次「進結帳次數」和「付款成交數」。這 4 天如果第一天就看這個比例，21 次會在第 3、4 次就被抓到。這一條是我們事後整理的建議做法。

最後一條是最便宜的。前五條要懂程式，第 6 條只要每天打開 GA4 看兩個數字。進結帳有、成交是 0，就代表結帳頁之後那一段斷了，不用等到第 21 次。

之後的數字

修完之後，桃梨 2026 年 9 月一共 32 筆已付款訂單、NT$29,280，最密集的一週是 09-20 到 09-26 的 27 筆。這不代表店賺錢了：同期的廣告投報率還低於 1，那是另一篇要寫的事。這篇只講一件事，換金流那 4 天的 0，是我們自己漏改造成的，不是沒有人要買。

綠界的申請和退件過程寫在 綠界申請流程與被退件原因。送審前、串接上線前要檢查的 25 項整理在 金流送審前檢查清單，最後一段就是這篇的教訓。桃梨從開站到現在的完整紀錄在 桃梨生活案例。

常見問題

換金流要多久？

桃梨從決定換到綠界、綠界過審（08-28）、金鑰問題解決（08-29），到 08-31 上線，程式切換本身在上線那天就完成了，但上線後還花了 4 天才把三處漏改找齊。時間花在「上線後才發現」，不是寫程式。

結帳頁按付款沒反應，可能是什麼原因？

我們遇到的兩種：一是 CSP 的 form-action 白名單沒有金流網域，瀏覽器靜默擋掉表單，只有 console 有一行訊息；二是必填欄位走瀏覽器原生驗證，沒有顯示錯誤文字，在 LINE、FB 的內建瀏覽器裡更容易看不到。先開瀏覽器開發者工具看 console。

為什麼金流驗證都過了，客人還是付不了款？

因為我們 2026-08-31 上線前的驗證全部是用程式打 API，繞過了瀏覽器。CSP 只在瀏覽器裡生效，前端按鈕也只有人點才會觸發。要用真的瀏覽器走完每一種付款方式和配送方式。

藍新換綠界，有哪些程式不能沿用？

藍新整包 AES 加密，綠界是明文欄位加 CheckMacValue；綠界金流簽章用 SHA256、物流用 MD5，但共用同一組金鑰；綠界的訂單編號永久不能重複，客人重新付款要換一個尾碼。加解密那層幾乎要重寫。

怎麼最快發現結帳壞掉？

每天對一次 GA4 的進入結帳次數和實際付款成交數。進結帳有、成交連續是 0，就去走一次結帳流程。

換金流、換物流，找人幫你走一遍

這 4 天的損失不大，但它發生在收款管道卡了兩週、廣告剛重新開的時候。如果你正要換金流或物流，想找人先把設定檔、欄位、每一條付款路徑用真的瀏覽器走一遍，可以看我們的 電商陪跑服務，或直接 在 Telegram 找我們↗。

---

了解我們的電商陪跑服務 →