The Grid Sandbox environment provides a complete testing environment for ramp operations, allowing you to validate on-ramp and off-ramp flows without using real money or cryptocurrency.Documentation Index
Fetch the complete documentation index at: https://ramps-docs-sync-20260320.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
Sandbox overview
Sandbox mirrors production behavior while using simulated funds:- Same API endpoints: Use identical API calls as production
- Simulated funding: Mock bank transfers and crypto deposits
- Real webhooks: Receive actual webhook notifications
- No real money: All transactions use test funds
- Isolated environment: Sandbox data never affects production
Sandbox is perfect for development, testing, and demonstrating ramp
functionality before going live.
Getting started
Create sandbox credentials
- Log into the Grid dashboard
- Navigate to Settings → API Keys
- Click Create API Key and select Sandbox environment
- Save your API key ID and secret securely
Configure sandbox webhook
Set up a webhook endpoint for sandbox notifications:Testing on-ramps (Fiat → Crypto)
Simulate the complete on-ramp flow in sandbox:Step 1: Create a test customer
In sandbox, customers are automatically approved for testing.
Step 2: Create an external account for the destination wallet
Step 3: Create an on-ramp quote (just-in-time funding)
Step 4: Simulate funding
Use the sandbox endpoint to simulate receiving the fiat payment:The reference code must match the one provided in the quote’s payment
instructions.
Step 5: Verify completion
Within seconds, you’ll receive a webhook notification confirming the on-ramp completed:Testing off-ramps (Crypto → Fiat)
Simulate the complete off-ramp flow:Step 1: Fund internal account with crypto
Simulate a Bitcoin deposit to the customer’s internal account using the sandbox funding endpoint:InternalAccount:btc001 with your actual BTC internal account ID.
You’ll receive an
ACCOUNT_STATUS webhook showing the updated balance.Step 2: Create external bank account
In sandbox, you can use special account number patterns to test different scenarios. The last 3 digits determine the behavior: 002 (insufficient funds), 003 (account closed), 004 (transfer rejected), 005 (timeout/delayed failure). Any other ending succeeds normally. See “Testing transfer failures” below for details.
Step 3: Create and execute off-ramp quote
In sandbox, off-ramp conversions complete instantly. In production, bank
settlement may take 1-3 business days.
Testing transfer failures
External account test patterns
The flows for creating external accounts in sandbox are the same as in production. The last 3 digits of an external account’s primary identifier (account number, IBAN, CLABE, Spark wallet address, etc.) determine the test scenario when that account is used in transfers or quotes. For identifiers with a domain part (e.g. PIX email keys), append the test digits to the username portion — for example,testuser.002@pix.com.br.
| Suffix | Behavior |
|---|---|
| 002 | Insufficient funds — transfer fails immediately |
| 003 | Account closed/invalid — transfer fails immediately |
| 004 | Transfer rejected — bank rejects the transfer |
| 005 | Timeout/delayed failure — stays pending ~30s, then fails |
| Any other | Success — transfer completes normally |
Beneficiary name verification
For account types that support beneficiary name verification, you can simulate different verification outcomes in sandbox. Use account identifiers with a1xx suffix to trigger verification scenarios (this range is reserved for verification and does not conflict with transfer or quote test patterns):
| Suffix | beneficiaryVerificationStatus | Behavior |
|---|---|---|
| 102 | NOT_MATCHED | Account is valid but name does not match |
| 103 | PARTIAL_MATCH | Account is valid, name is a fuzzy match |
| 104 | PENDING | Verification still in progress |
| 105 | (error) | Returns 400 — invalid account |
| 106 | UNSUPPORTED | Payment rail does not support name verification |
| 107 | CHECKED_BY_RECEIVING_FI | Verification deferred to receiving financial institution (e.g., ACH) |
| 109 | (error) | Returns 500 — simulated API error |
| Any other | MATCHED | Account is valid, name matches exactly |
Test scenarios
Successful conversions
The complete on-ramp and off-ramp flows described in the sections above demonstrate successful conversion scenarios. For quick reference: On-ramp test (USD → BTC):- Create customer and quote with payment instructions
- Use
/sandbox/sendto simulate funding - Verify completion via webhook
- Fund BTC internal account with
/sandbox/internal-accounts/{accountId}/fund - Create external bank account (use default account number for success)
- Create and execute quote
- Verify completion via webhook
Failed conversions
Test error scenarios systematically using the magic account patterns: 1. Test external account insufficient funds (002):Moving to Production
When you’re ready to move to production:- Generate production API tokens in the dashboard
- Swap those credentials for the sandbox credentials in your environment variables
- Remove any sandbox-specific test patterns from your code
- Configure production webhook endpoints
- Test with small amounts first
Next steps
- Webhooks - Handle real-time notifications
- Fiat-to-Crypto Conversion - Implement production flows
- Self-Custody Wallets - Advanced wallet integration
- Platform Configuration - Configure production settings
- API Reference - Complete API documentation