Exciting times! You have made it this far, you are almost ready to go live. All you have to do now is test your integration, complete a test transaction and then get ready to go live. Nice work! 🎉

Environment Access

Ensure you are using the correct base URL and API keys for the sandbox environment.

Note: The sandbox domain ends in .dev, while production ends in .com.

Important: Sandbox Purpose and Limitations

The Onramper sandbox is a simulated environment. It is critical to understand what it can and cannot do.

What Sandbox Is For

• UI Integration: Testing the look and feel of the widget within your application or WebView.
• Flow Exploration: Understanding the steps a user takes (email entry, KYC simulation, payment method selection).
• Handling API Responses: Verifying that your application correctly handles success/fail callbacks from the widget.

What Sandbox Is NOT For

Critical Warning: The sandbox environment has significant limitations compared to production:

• ❌ No Testnet Transactions: Unlike some other platforms, none of the providers support actual testnet blockchain transactions. You cannot verify on-chain settlement in this environment.
• ❌ Data Accuracy: Available assets (fiat/crypto) in sandbox often differ from production and may lack complete data accuracy.
• ❌ APM Testing: Alternative Payment Methods (e.g., Apple Pay, Google Pay) generally cannot be tested; you must use dummy cards.
• ❌ Production Bleed-over: For providers without a dedicated sandbox, Onramper may display their production environment inside the .dev sandbox. Be careful: using real card data here may result in actual charges.

Sandbox-Friendly Providers

While Onramper integrates many providers, their sandbox reliability varies significantly.

Recommended for Testing

Only one provider is recommended for simulating a full user flow securely.

• Banxa: This is the most mature sandbox environment available on Onramper. It is highly recommended to use Banxa (specifically for GBP or EUR) for all integration testing

Limited Sandbox Support:

The following providers have sandbox environments, but they may be "janky," often reject KYC, or lack full functionality.

• Sardine: Supports specific email/phone triggers for fraud checks.
• Topper: Supports specific OTPs and low-KYC flows.
• Stripe: Functional but requires specific test SSNs.
• TransFi & BTC Direct: Basic test card support available.
• Coinify: Different cards trigger different responses.

❌ Production Only / Real Payments Required

• These providers effectively operate in production mode even within the sandbox.
  • Alchemy Pay: Sandbox functions like production; requires real payments to test.
  • Fonbnk: Requires real wallet addresses matching the token; no test cards available

Testing Best Practices##

1. Prioritize Banxa
   Always start your integration testing using Banxa with GBP or EUR. This provider offers the highest probability of completing a flow without unexpected errors or rejection.
2. Verify Wallet Addresses
   Even though transactions do not settle on the testnet, some providers (like BTC Direct) may require a syntactically valid wallet address to proceed past the quote screen.
3. Production Testing Strategy
   Because provider sandboxes are non-standardized and often lack testnet support, we recommend:
   1. Deploying your integration behind a feature flag or on a hidden staging page.
   2. Performing final validation using Production mode (pk_prod) with small, real transactions to ensure calculations and liquidity are accurate.
4. Troubleshooting
   If you encounter empty wallet errors or rejected transactions in Sandbox:
   1. Check if you are using the correct dummy card for the specific provider selected.
   2. Recall that on-chain settlement will not occur.
   3. If a provider interface looks identical to a live payment screen and rejects the dummy card, you may be viewing a production environment.