Skip to main content
This page covers sandbox-specific testing details. If you haven’t set up your sandbox account yet, start with the Initial Setup.
Sandbox onramps are capped at 500 MXN per quote. Larger sandbox onramp amounts are rejected — this keeps test volumes small. Production has no such cap.

​
Sandbox KYC & Bank Accounts

The sandbox environment accepts fake data for both KYC verification and bank account linking. You can submit any test identity information, documents, and bank details to complete the onboarding flow without providing real personal data.
Programmatic KYC auto-approves in sandbox. When a personal customer completes the programmatic flow — submit KYC, upload documents, and sign all agreements — the customer auto-approves and a kyc_updated webhook fires, with no manual review. Signing the final agreement is what triggers approval; submitting KYC or uploading documents alone leaves the customer proposed. This lets you exercise the full submit → webhook → order loop without waiting for Etherfuse to manually approve each test customer. Production still requires manual review.
Programmatic bank account registration requires sandbox RFCs. When you create a bank account via API in sandbox, use one of these placeholder RFCs so Etherfuse can fully provision the account without involving the real SPEI provider:
Account typeSandbox RFC
PersonalXEXX010101000
BusinessXEX010101000
Using these RFCs causes Etherfuse to skip the SPEI provider registration and mark the account compliant: true immediately, so you can move straight to creating orders. Any other RFC in sandbox is sent through to the SPEI provider’s sandbox environment and treated as a real registration — it will not auto-approve. The hosted onboarding UI uses these RFCs automatically; this guidance only applies to the programmatic flow. Both RFCs are rejected as generic/placeholder values in production.
Optional: Test with a real bank accountIf you want to verify that a real Mexican bank account can be correctly wired up with our SPEI provider, you can optionally link your real bank account in sandbox using your real RFC. No real funds will be moved or charged — all transactions in sandbox are simulated, even when using a real bank account. This is entirely optional — the sandbox RFCs above work for standard testing.

​
Testnet Tokens

You’ll need testnet tokens to test offramps and swaps — no need to contact Etherfuse to get them. Onramp to receive Etherfuse tokens (e.g. CETES), then swap those for any other supported token (USDC, etc.). See Testing Onramps and Testing Swaps for the flows.
Stellar: Trust lines for onramps are handled automaticallyWhen onramping to a Stellar wallet that doesn’t have a trustline (or doesn’t exist on-chain yet), Etherfuse handles the setup automatically. Pass walletAddress in your quote request — the quote fee will include a one-time onboarding cost. After the order completes, sign the stellarClaimTransaction from the order response to add the trustline and claim your tokens. See Testing Onramps for the full flow.For offramps and swaps, your wallet must still have trust lines established beforehand. Use GET /ramp/assets?blockchain=stellar to discover available assets and their identifiers in CODE:ISSUER format, then use the issuer address to create trust lines on your Stellar wallet.

​
Webhooks in Sandbox

Webhooks work the same in sandbox as in production. Make sure your webhook endpoint is publicly accessible (or use a tool like ngrok for local development) and register it via POST /ramp/webhook.