沙箱環境和正式環境有什麼區別？支付測試模式如何運作，以及如何安全上線
支付接口的沙箱與正式環境：哪些數據相互隔離、測試模式下哪些行為不同，以及安全切換到正式密鑰的上線檢查清單。
每個支付接口都有兩個世界：沙箱（測試模式），在這裏做什麼都不會動用真實資金；以及正式環境，在這裏會。沙箱和正式環境的區別，不只是「假卡和真卡」：兩個環境的數據相互隔離，在幾個重要方面表現不同，而在兩者之間切換，正是接入最容易出錯的地方。
這篇文章説明 KukoPay 上沙箱和正式環境如何隔離、測試模式下哪些行為不同，以及一份安全切換的上線檢查清單。
沙箱和正式環境如何隔離
API 密鑰決定環境。 kuko_test_ 密鑰只能訪問沙箱，kuko_live_ 密鑰只能訪問正式環境。沒有任何請求字段可以切換環境，所以測試代碼永遠不會意外產生真實扣款，正式代碼也永遠讀不到測試數據。
其他一切都由此而來：
| 按環境隔離 | 説明 |
|---|---|
| API 密鑰 | 沙箱密鑰隨時可以查看；正式密鑰只完整顯示一次 |
| 訂單、退款、拒付、事件 | 每個環境只能看到自己的 |
| 餘額和資金流水 | 沙箱資金不是真錢，也不能提現到銀行 |
| 結算賬戶和提現 | 正式環境的賬戶和提現要經過審核，沙箱不需要 |
| Webhook 端點 | 一個端點只接收一個環境的事件 |
控制台也以同樣的方式隔離，環境寫在網址裏：/dashboard/... 是正式環境，/test/dashboard/... 是沙箱。發給同事的鏈接，會在你當時所在的環境中打開。賬戶審核通過前，正式環境的地址會自動跳到對應的沙箱頁面。
有一樣是共用的：API 調用頻率限制按賬戶計算，所以沙箱和正式環境的調用計入同一份每分鐘配額，見 API 調用頻率限制。
沙箱裏哪些行為不同
| 沙箱 | 正式環境 | |
|---|---|---|
| 賬戶審核 | 不需要，註冊後即可開始 | 必須通過資質審核 |
| 幣種 | USD、HKD 和 CNY | 為你開通的幣種 |
| 支付方式 | 全部（你自行關閉的除外） | 為你開通的支付方式 |
| 銀行卡表單 | 只接受測試卡號 | 真實銀行卡 |
| 錢包和 3D Secure | 測試授權頁，由你選擇結果 | 真實的錢包或銀行 |
| 初始餘額 | 每個幣種 $5,000.00 測試資金，隨時可以補充 | 從 0 開始 |
| 提現 | 立即完成，流水記錄相同 | 先審核，再通過銀行轉賬 |
| 結算賬戶 | 立即可用 | 使用前需要審核 |
| 收款限額 | 從不生效 | 賬戶設有限額時生效 |
| 收據 | 標有 [TEST] | 真實收據 |
兩個環境的手續費都按真實公式計算，所以沙箱的餘額看起來和正式環境一樣。測試卡號和測試頁面見 支付測試卡號大全。
沙箱證明不了什麼
沙箱測試的是你的接入：你的下單、Webhook 處理、退款和對賬。它無法展示：
- 真實的發卡行如何拒絕真實的卡，或者有多少買家會放棄真實的 3D Secure 驗證（見 3D Secure 是什麼）；
- 真實的結算時間：沙箱資金會立即入賬、立即提現（見 支付結算是什麼）；
- 你的生產網絡：正式 Webhook 地址前的防火牆、出口 IP 和 TLS。
所以切換之後，請密切關注最初的幾筆正式付款。
上線檢查清單
完成資質審核
資質審核通過前，正式密鑰會被拒絕並返回 403 merchant_not_approved，見 KYB 驗證是什麼。
簽發正式密鑰
在正式環境的 開發者 → API 密鑰 中，為每個應用和服務簽發 kuko_live_ 密鑰，並立即存到服務端配置中，因為它只顯示一次。接口地址和請求字段都不變，只換密鑰。
配置正式環境的 Webhook
正式訂單需要公網 HTTPS 的 notify_url，或者一個正式環境的 Webhook 端點，至少訂閲 payment.succeeded、payment.failed、refund.succeeded 和 dispute.created。沙箱端點收不到正式環境的事件。
核對驗簽代碼
確認它能接受多個 v1= 簽名中的任意一個，否則密鑰輪換期間每一次投遞都會失敗，見 收不到支付 Webhook 回調怎麼辦。
確認幣種和支付方式
正式環境只能使用為你開通的幣種和支付方式。缺少的支付方式請在上線前申請開通。
接好對賬
每天用資金流水對賬，不要只依賴 Webhook，見 支付對賬怎麼做。
收緊訪問權限
如果服務器有固定出口 IP，就設置 IP 白名單；並讓所有能退款或提現的成員開啓兩步驗證，見 如何保護你的商戶賬戶安全。
跑一筆真實付款
用真實銀行卡支付一筆小額正式訂單，確認 Webhook、訂單和流水都正確，然後退款，見 部分退款怎麼操作。
從沙箱切換到正式環境的常見錯誤
- 生產配置裏留着測試密鑰，正式訂單被創建在沙箱裏，從來沒有真正扣款。
- 只配置了沙箱的 Webhook 端點，正式付款成功了，卻沒有人收到通知。
- 在兩個環境之間混用密鑰，用測試密鑰查正式訂單，得到
404。 - 把密鑰打包到前端：密鑰只能放在服務端。
- 在業務高峯期壓測沙箱，它和正式環境共用同一份頻率配額。
總結
- 密鑰前綴決定環境：
kuko_test_是沙箱，kuko_live_是正式環境，請求裏沒有任何字段可以切換； - 訂單、餘額、提現、密鑰和 Webhook 端點按環境隔離，頻率限制共用；
- 沙箱不需要審核，提供全部支付方式、測試卡號、$5,000 測試資金和即時提現；
- 它證明不了真實的拒卡、真實的結算時間，也證明不了你的生產網絡；
- 上線步驟：完成審核、簽發正式密鑰、配置正式 Webhook、核對驗簽、支付方式和對賬，再跑一筆真實付款並退款。
在沙箱裏把它跑通
註冊商戶後即可申請測試密鑰，不需要等待資質審核。