沙盒環境
支付處理沙盒環境，允許在通過合作收單方路由實際交易量之前模擬整個交易生命週期，有助於徹底測試支付邏輯。
- 類別
- 開發者
- 功能
- 6
- 適用於
- 所有方案
Cardflo 沙盒環境讓開發人員能夠整合和測試支付解決方案，而不會影響實際交易。 這個獨立的空間模擬我們的生產環境，可以徹底測試所有 Cardflo 功能，從支付處理到網絡鉤子和 API 互動，確保順利過渡到實際營運。
在沙盒環境中測試允許商戶嚴格驗證其支付整合並模擬整個交易生命週期。 這一步驟對於上線處理至關重要，可最大限度地減少上線時的風險和錯誤。
概述沙盒環境概覽
沙盒環境充當支付網關或協調平台的非生產實例，允許開發人員在不移動真實資金的情況下模擬整個交易生命週期。 它作為實時 API 的副本運行，包括授權、捕獲和結算組件。
在這個隔離的容器中，技術團隊可以根據嚴格的驗證規則驗證他們的整合邏輯、請求結構和身份驗證標頭。 通過使用測試憑證和模擬卡識別號碼 (BIN)，商家可以評估其後端如何響應各種回應，例如成功支付、軟拒絕或 3DS 身份驗證提示。
沙盒位於商家應用程式和模擬收單機構之間，提供一個安全的空間，以確保代碼處理邊緣情況，例如資金不足或卡過期，然後再轉移到實時生產環境，在該環境中錯誤可能導致收入損失或退單率增加。
如何沙盒環境的運作方式
憑證生成和身份驗證
開發人員獲取一組專門用於測試環境的 API 密鑰或 Bearer 令牌。這些憑證將請求路由到模擬處理器，而不是實時支付計劃。這確保沒有商家識別號碼 (MID) 被收取處理費用，也沒有真實持卡人數據進入生產系統。
模擬交易處理
商家使用預定義的測試卡號發送支付請求，這些卡號會觸發特定的結果。例如，使用一個 BIN 可能會模擬成功的授權，而另一個則會觸發 CVV 不匹配或硬拒絕。沙盒返回與實時 API 相同的 JSON 回應結構，以確保兼容性。
網絡鉤子事件通知
一旦沙盒中的交易狀態發生變化，系統就會生成異步網絡鉤子。商家伺服器在指定端點接收這些通知，以驗證其系統是否正確更新內部數據庫。此步驟對於實時測試自動訂單履行或訂閱管理邏輯至關重要。
為何沙盒環境的重要性
部署期間的風險緩解
直接在生產環境中實施新的支付流程會產生很高的營運風險。通過利用沙盒，開發人員可以識別邏輯錯誤或格式錯誤的 API 請求，否則這些錯誤或請求會導致結帳失敗。這種隔離保護了實時商家識別號碼的完整性，並防止在積極測試新的實體卡或非實體卡整合邏輯期間可能發生的反欺詐過濾器意外觸發。
複雜邏輯的驗證
現代支付通常涉及多步驟流程，例如強客戶身份驗證 (SCA) 或循環計費。沙盒允許對持卡人發起和商家發起的交易進行嚴格測試，而無需實際交易的財務成本。它確保系統正確解釋發卡機構的各種拒絕代碼和回應訊息，從而允許改進催收邏輯和重試策略，以優化最終轉換率。
監管注意事項：沙盒環境的監管備註
Payment Card Industry compliance verification
Testing environments must strictly avoid capturing or storing genuine financial details to maintain clean boundaries around PCI DSS scope. Quality assurance protocols mandate the exclusive use of designated test payment credentials, ensuring that development databases never ingest regulated primary account numbers during system validation phases.
The Cardflo staging infrastructure mirrors the cryptographic tokenisation requirements enforced by global card networks.
Development teams must implement the exact same client-side encryption logic and token exchange mechanisms used in reality, allowing security auditors to verify that sensitive fields never touch the merchant server application logic.
Strong Customer Authentication preparation
The revised Payment Services Directive mandates strict adherence to Strong Customer Authentication protocols for electronic transactions within the European Economic Area. Developers must demonstrate that their integration correctly requests necessary exemptions and properly handles mandatory step-up challenges initiated by issuing banks during the checkout sequence.
Simulating these regulatory requirements requires a robust staging capability that can artificially trigger SCA requests across different payment types.
Engineers rely on the payment gateway sandbox to verify that their routing logic successfully falls back to 3D Secure workflows when acquirer partner networks reject low-value or recurring transaction exemptions.
用例沙盒環境的應用場景
初始 API 整合
新商家使用沙盒將其內部訂單管理系統映射到支付網關的 API 端點。這確認了貨幣代碼和商家類別代碼等數據字段已正確格式化以進行授權。
循環計費驗證
基於訂閱的企業通過模擬卡過期或資金不足來測試其催收序列。這確保系統在服務暫停之前正確嘗試重試並向客戶發送適當的通知。
網絡鉤子端點調試
開發人員使用測試環境來驗證其防火牆和伺服器配置是否允許傳入的網絡鉤子通知。這可以防止儘管在收單機構級別成功授權，訂單仍保持「待處理」狀態的問題。
替代支付方式測試
在啟用本地支付方式之前，商家可以模擬 APM 所需的重定向流程。這確保當客戶被發送到第三方錢包或銀行門戶時，用戶體驗保持一致。
統計沙盒環境的數據
技術團隊在使用全面的沙盒時觀察到的典型效率提升，與手動文件審查和直接生產測試相比。
當嚴格的沙盒測試作為 CI/CD 管道的一部分實施時，與支付邏輯相關的部署後錯誤的估計減少範圍。
模擬 API 端點的行業標準響應時間，允許在軟件開發生命週期中快速迭代。
方法論：這些數字是根據已公佈的行業數據和觀察到的商戶群組得出的說明性範圍，而非保證。實際結果取決於您的風險狀況、卡片組合、地理位置和收單設置，並僅在您自己的定價和審批條款中確認。
與我們的團隊討論在我們收單合作夥伴的 rails 上進行即時部署。
{{title}} 的優勢 沙盒環境
- 在安全的環境中，根據官方文件驗證 API 請求和回應結構。
- 模擬特定的授權拒絕原因，以驗證錯誤處理和客戶訊息。
- 觸發並接收網絡鉤子通知，以獲取捕獲、退款和爭議等狀態更新。
- 測試 3D Secure 身份驗證流程，以確保符合 PSD2 和 SCA 要求。
- 驗證網絡代幣和帳戶更新通知的處理，無需真實數據。
- 在過渡到更高交易量的生產環境之前，對整合邏輯執行負載測試。
A short scoping call, then a written plan for your MIDs.
關於 沙盒環境
沙盒交易會出現在真實銀行結單上或產生計劃費用嗎？
不會，在沙盒環境中處理的交易不會與 Visa 或 Mastercard 等實際支付計劃互動。 它們由模擬處理器處理，該處理器模擬發卡機構的回應。
因此，不會移動真實資金，不會向持卡人收費，商家也不會產生任何交換或計劃費用。 該環境完全隔離，以防止財務影響。
我可以在沙盒中測試強客戶身份驗證 (SCA) 和 3D Secure 嗎？
可以，高品質的沙盒環境提供特定的測試卡或標誌來觸發 3DS 流程。 這允許開發人員測試重定向到模擬的存取控制伺服器 (ACS) 並處理由此產生的身份驗證結果，例如成功、失敗或繞過。
這是歐洲商家確保符合 PSD2 電子支付指令的重要步驟。
如何在測試中模擬硬拒絕與軟拒絕？
模擬通常是通過使用文件中指定的不同測試卡號或交易金額來實現的。 特定的 BIN 可能會映射到「遺失或被盜」回應（硬拒絕），而另一個可能會觸發「資金不足」（軟拒絕）。
測試這些變體對於開發人員實施正確的重試邏輯並區分永久性故障和臨時性故障至關重要。
沙盒中儲存的持卡人數據是否受 PCI DSS 合規性約束？
雖然沙盒不應包含真實持卡人數據，但 API 密鑰和模擬數據的安全性仍然很重要。 大多數沙盒環境使用類似真實 PAN 的偽數據，但未能通過 Luhn 算法檢查或屬於未分配的範圍。
但是，開發人員應保持良好的安全實踐，切勿在測試環境中使用真實客戶數據，以避免潛在的數據洩露風險。