更改訂單前，如何驗證付款通知真偽

通知只是請求，並非收據

付款通知會送到公開網址，任何人都可以向該網址發送請求。JSON 欄位寫着「已付款」仍只是聲稱；商戶須先驗證來源，再按自己的訂單狀態理解事件。若系統會自動安排出貨，偽造請求便可能令未付款訂單進入執貨流程。先列明採用哪個服務、哪個接收端點、哪類事件，以及事件可以推動哪個訂單狀態，讓營運與開發人員有共同準則。

Stripe 的文件說明，驗證事件須同時使用原始請求內容、Stripe-Signature 標頭及該端點的簽署密鑰。這是具體例子，不能推論每個支付服務都採用同一格式。若使用另一收款平台，應閱讀該平台現行的驗證指引，並分別測試測試環境與正式環境。事件編號看似合理、網址只供供應商使用、JSON 可以解析，都不能代替驗證。

驗收規則應寫得清楚：只有通過服務商驗證的請求，才可進入付款事件處理程序。驗證失敗時，系統不應更新訂單、通知顧客、預留存貨或記帳。程式審查與測試都要涵蓋這一點。同時要分清「簽署無效」與「簽署有效但找不到訂單」；兩者都需調查，只有後者已通過來源驗證。

保留驗證所需的原始內容

不少錯誤在驗證函式執行前已出現：框架可能先解析 JSON、改變欄位次序、空格或編碼。Stripe 明確指出，原始內容一旦被改動，簽署驗證便會失敗。接收路由應取得原始內容，並依照服務商對所用框架的指示設定；完成驗證後才解析業務欄位。若反向代理或無伺服器閘道會轉換請求，也要檢查其映射設定，因為程式無法重建已被上游丟棄的原文。

簽署密鑰屬於個別端點。Stripe 指出，本機 CLI 監聽取得的密鑰與控制台管理端點的密鑰不同；混用會造成本機測試通過、正式站每次驗證失敗。可維持一張設定表，記錄環境、目的網址、事件格式、密鑰負責人和輪換程序，但不要把密鑰寫進文章或測試報告。應限制可讀取密鑰的人員，使用應用程式的秘密管理機制，並測試密鑰缺失或錯誤時必須拒絕處理。

可用供應商產生的測試事件演練：在應用程式接收邊界保留原始內容，先驗證未改動的版本，再分別改一個看似無關的空格及一個金額數字。原版應通過，改動版應在寫入訂單前失敗。測試應經過正式部署所用的代理路徑，而非只呼叫本機函式。這個結果只證明真偽驗證邊界有效，並不代表整個結帳流程已正確。

有效簽署仍須檢查時間

來源真確不等於請求仍在有效時間內。Stripe 會把時間戳與內容一併簽署，其程式庫預設容許五分鐘差距；文件亦警告，把容許值設為零會停用時效檢查。因此伺服器時鐘必須準確。除非有具體理由並測試過影響，商戶宜保留程式庫預設。若正常請求因時鐘偏差而失敗，應先修正時間同步和部署問題，而非盲目放寬時間窗。時間窗越長，被截取的有效請求可被重播的機會也越大。

Stripe 文件亦說明，同一事件重試發送時會獲得新的簽署和時間戳。因此，新近且有效的簽署只證明這次送達請求符合驗證要求，不代表事件從未出現。真偽檢查與防止同一事件重複更改訂單的業務規則，須各自處理。既有的事件復原文章討論重複、延遲及漏送；本文聚焦每個 HTTP 請求能否先進入該處理流程。

測試矩陣可涵蓋有效新請求、沒有簽署標頭、使用錯誤端點密鑰、內容被改動、過期的已簽署請求，以及刻意調錯時鐘的伺服器。每項都應記錄預期回應及「沒有訂單副作用」的結果。再以供應商重新簽署的正常重試事件測試，確認真偽層不會拒絕合理重試。應使用服務商工具或可靠測試資料產生標頭，不要自行修改標頭後聲稱得到有效簽署。

通過驗證後，仍要核對訂單意思

通過簽署驗證後，仍須把事件種類及識別碼與本店訂單核對。有效事件可能涉及另一筆付款、已取消訂單、測試模式物件，或尚不足以出貨的狀態。應建立明確轉移表：目前訂單狀態、服務商事件及物件狀態、預期付款參考編號、允許的新狀態，以及人工例外處理。只有業務已批准的組合可觸發執貨，避免把所有已簽署通知都當成出貨許可。

以一件商品的示例訂單說明：顧客付款後回到「多謝」頁，但付款事件尚未到達，並向職員傳來畫面截圖。訂單應維持待確認，按店舖政策查核服務商紀錄、已驗證事件或支援的 API。截圖與瀏覽器跳轉只反映顧客看到的畫面，不是已驗證的付款證據。收到有效事件後，仍須比對付款參考編號與待處理訂單，才可推進流程。

稽核紀錄要有用，但不應把密鑰或完整敏感內容放進一般日誌。可記錄接收時間、服務商事件編號、驗證結果、端點環境、相關訂單、處理決定及安全的錯誤類別；存取和保存期限應符合業務需要。事故發生時，這些資料可協助職員分辨簽署錯誤、有效但未能配對的訂單，以及業務規則拒絕，也能解釋訂單為何仍待處理。

以可觀察的驗收計劃上線

啟用自動出貨前，應在非正式環境演練整條路徑：服務商送出測試事件、代理原樣轉送、驗證器接受，以及符合條件的訂單只轉移一次。反面案例也要經同一路徑測試。檢查哪些 HTTP 回應會引發重試；如服務商要求迅速確認，耗時的後續工作應另行處理。驗證失敗的請求則不能因此進入背景處理。

正式推出初期，應指定負責人監察驗證失敗、有效但無法配對的事件，以及顧客返回結帳頁後仍待確認的訂單。遇到問題時，按流程查閱服務商送達紀錄及店舖帳目。部署後失敗突然增加，可能與中介軟件、環境設定或端點密鑰輪換有關；應逐項調查，不能叫職員略過驗證。暫時可採用人工核對與延後出貨，並向顧客清楚解釋。

最後的驗收問題很具體：未通過驗證或被改動的請求，即使看似合理付款事件，能否更改訂單？若能，應暫停自動處理並修復信任邊界。若不能，還要確認真正已簽署事件可推動正確的訂單轉移，而異常個案會顯示給職員處理。這比單看服務商標誌、綠色狀態燈或一次成功測試更可靠。

密鑰輪換亦應事先演練。先記錄每個環境對應哪個端點、誰有權更改密鑰、服務商支援的過渡期如何接納新舊簽署，以及何時移除舊密鑰。Stripe 文件指出，輪換期間端點可以暫時擁有多個有效密鑰。更改後要由服務商送出新的測試事件，確認正常簽署仍可通過，而使用無關密鑰的事件仍被拒絕。若驗證突然全部失敗，應恢復正確設定、檢查端點與密鑰配對及部署版本，不能為了讓訂單繼續流動而關掉驗證。營運團隊還應預先訂出等待付款確認期間的人工核對和顧客通知方式，讓安全修復有足夠時間完成。

最後還要指定辦公時間以外由誰處理驗證警報。若收款平台送來的事件持續被拒，值班人員需要知道端點名稱、所屬環境、最近部署變更，以及如何在不外洩密鑰的情況下核對送達紀錄。團隊應預先決定待確認訂單的標示方式、何時通知顧客，以及誰有權在平台後台作人工查證。這能把技術驗證故障轉化為可管理的業務例外，也令訂單積壓時不會有人因趕出貨而關掉驗證。