Sandbox

Test keys

A test key starts sr_test_…. It holds exactly these scopes:

• corridors:read
• quote
• beneficiaries:validate
• transactions:read
• transactions:write

It never holds rates:read, rates:write, beneficiaries:write or settlements:read; those calls get 403 with a test key.

Sandbox transactions

• A test key only ever creates and sees sandbox transactions. A live key never sees them, and a test key never sees live ones (404).
• A sandbox transaction always settles on the platform's mock rail, after a short delay, whatever settlement rail your account is set up with. It is never sent to a real payout rail.
• Sandbox transactions never message a real customer or recipient, and can never be paid on the hosted pay page.
• Sanctions screening still runs on every sandbox transaction, exactly as it does on live ones.
• Idempotency keys are kept per environment: the same Idempotency-Key used with a test key and with a live key creates two separate transactions.

A minimal sandbox run:

curl -X POST https://smartremit.ai/api/partner/v1/transactions \
  -H "Authorization: Bearer $TEST_KEY" \
  -H "Idempotency-Key: 5f0c8a3e-2b7d-4e61-9a4f-0d3b8c1e7a52" \
  -H "Content-Type: application/json" \
  -d '{
    "amount_source": 200,
    "source_currency": "USD",
    "purpose": "family_support",
    "sender":      { "phone": "+12025550142", "name": "Jane Doe", "kyc_status": "verified" },
    "beneficiary": { "name": "Anita Sharma", "phone": "+12025550143",
                     "payout_method": "bank", "payout_destination": "123456789012|HDFC0001234" }
  }'

Then confirm it with POST /transactions/{id}/confirm and read it back with GET /transactions/{id} until it is delivered.

The reference rail

Sandbox transactions always deliver: they never reach a settlement rail, so they cannot exercise your settlement endpoint or a failed payout.

To test the full settlement loop, SmartRemit can point your account at the hosted reference rail for a test run arranged with you. No real money moves on it. It runs the exact loop a production rail would: it receives the signed settlement instruction, verifies the signature, acknowledges it with a provider reference, and about 12 seconds later sends a signed status callback. See Webhooks for the loop itself.

On the reference rail, a bank payout whose account number is all zeros exercises the failure path. The account number must be the last group of digits in the payout destination, so for India send the inline payout_destination exactly as HDFC0001234|000000000000 (IFSC first, then the account). The reference rail acknowledges the instruction, then reports failed with reason account_unreachable. This trigger has no effect on sandbox transactions.