Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.etherfuse.com/llms.txt

Use this file to discover all available pages before exploring further.

This page covers sandbox-specific testing details. If you haven’t set up your sandbox account yet, start with the Initial Setup.

​
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 you submit KYC for a personal customer via POST /ramp/customer/{id}/kyc or POST /ramp/customer/{id}/kyc/documents, the customer is marked approved immediately and a kyc_updated webhook fires. 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. Contact Etherfuse for information on obtaining testnet CETES, USDC, and other supported tokens on the relevant testnets.
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.