測試

這裡沒有模擬平台或 SDK 可供測試——運營商這一側的整合就是普通的已簽名 HTTP，所以測試工作主要是獨立地測試你自己的簽名/驗證程式碼和你的錢包後端，再加上在真正涉及真實資金之前，跑一次真實的端到端流程。

獨立於平台測試你的簽名與驗證

signRequest 和 verifyPlatformSignature 都是純函式，只依賴各自的輸入——測試它們不需要任何網路呼叫。一個有用的冒煙測試：用 signRequest 簽名一個請求，再把它的輸出直接餵給你的 verifyPlatformSignature，確認它會接受；然後改動請求體裡的一個位元組，或改動時間戳，或改動 nonce，確認它會被拒絕。這能在真正的請求發出之前，就抓到整合裡最常見的錯誤——一種和平台構造微妙不同的規範字串（欄位順序錯了、少了一個換行符、用了路徑而不是完整 URI 等等）。

直接測試你的錢包回調後端

你實作的 POST /v1/wallet/transaction 和 GET /v1/wallet/balance 不需要平台在跑起來才能測試——它就是你自己的 HTTP 伺服器。直接寫出符合 TransactionRequest 結構的請求打給它，並斷言回應：

• 超過玩家餘額的 BET 應該回傳 DECLINED，而不是錯誤。
• 重複的 transactionId（同一筆 BET 送兩次）應該回傳一模一樣的快取回應，且不會重複扣款——這是上線之前最需要驗證的單一屬性。見冪等性。
• 引用已知 originalTransactionId 的 ROLLBACK 應該退回正確的金額。
• 格式錯誤或未簽名的請求，應該在你的業務邏輯執行之前就以 401 被拒絕。

使用 DEMO 模式測試啟動與 shell 整合

DEMO 模式讓你可以完整跑一遍啟動 → 嵌入 → shell 橋接的流程，完全不需要動用你的錢包回調後端——平台會用一個臨時虛擬餘額鑄造 session，而不是呼叫你。這是驗證簽名、目錄列表、iframe 嵌入、以及你的 postMessage 監聽器是否都接對了的最快方式，且和你的錢包後端是否就緒完全無關。見 REAL 與 DEMO 模式。

上線前先跑一次真實的端到端流程

在兩邊各自獨立驗證通過之後，在正式服務第一位真實玩家之前，針對平台的預備環境（如果你的整合聯絡人有提供的話——見環境與基礎網址）跑一次完整的 REAL 模式 session：簽名一次啟動呼叫、嵌入結果、下一筆注、確認你的錢包後端收到並正確結算了它，並確認 shell 橋接 BET_END 事件裡顯示的餘額，和你帳本目前顯示的一致。在那第一個真實 session 之前還需要驗證的其他一切，見上線檢查清單。