Sandbox Testing - Grid API Documentation

Overview

The Grid sandbox environment allows you to test your payouts integration without moving real money. All API endpoints work the same way in sandbox as they do in production, but money movements are simulated and you can control test scenarios using special test values.

Getting Started with Sandbox

Sandbox Credentials

To use the sandbox environment:

Go to app.lightspark.com, create an account, and generate your sandbox API keys from the dashboard.
Add your sandbox API token and secret to your environment variables.
Use the normal production base URL: https://api.lightspark.com/grid/2025-10-13
Authenticate using your sandbox token with HTTP Basic Auth

Simulating Money Movements

Funding Internal Accounts

In production, internal accounts are funded by following the payment instructions (bank transfer, wire, etc.). In sandbox, you can instantly add funds to any internal account using the following endpoint:

POST /sandbox/internal-accounts/{accountId}/fund

{
  "amount": 100000  # $1,000 in cents
}

Example:

curl -X POST https://api.lightspark.com/grid/2025-10-13/sandbox/internal-accounts/InternalAccount:abc123/fund \
  -u "sandbox_token_id:sandbox_token_secret" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 100000
  }'

This endpoint returns the updated InternalAccount object with the new balance. Alternatively, you can also fund internal accounts using the /quotes or /transfer-in endpoints as described below.

Testing Transfer Scenarios

Adding Test External Accounts

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.

Beneficiary name verification

For account types that support beneficiary name verification, you can simulate different verification outcomes in sandbox. Use account identifiers with a 1xx 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)
Any other	`MATCHED`	Account is valid, name matches exactly

Testing Transfer-In (Pull from External Account)

When you call /transfer-in with an external account created using test patterns, the transfer will complete instantly in sandbox with the behavior determined by the account number:

POST /transfer-in

{
  "source": {
    "accountId": "ExternalAccount:abc123"  // Uses test pattern from creation
  },
  "destination": {
    "accountId": "InternalAccount:xyz789"
  },
  "amount": 10000  // $100 in cents
}

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

Testing Transfer-Out (Push to External Account)

Transfer-out works the same way - the destination external account’s test pattern determines the outcome:

POST /transfer-out

{
  "source": {
    "accountId": "InternalAccount:xyz789"
  },
  "destination": {
    "accountId": "ExternalAccount:abc123"  // Uses test pattern
  },
  "amount": 10000
}

The transfer will instantly simulate the bank transfer process and complete with the appropriate status based on the external account’s test pattern.

Testing Cross-Currency Quotes

When creating a quote with an external account destination, the account number suffix determines the payment outcome after quote execution:

Suffix	Behavior
002	Quote execution failed
003	Long payment — completes after approximately 6 minutes
004	Counterparty delivery failed
005	Receiving bank returned payment (completes then transitions to failed)
006	User cancellation
007	Payout and refund failed
Any other	Successful payment

Creating Quotes with Test Accounts

When creating quotes with test external accounts, first create an external account with a test account pattern, then reference it in the quote:

# Step 1: Create the external account with a test pattern
POST /customers/external-accounts

{
  "customerId": "Customer:123",
  "currency": "EUR",
  "accountInfo": {
    "accountType": "EUR_ACCOUNT",
    "iban": "DE89370400440532013003",
    "beneficiary": {
      "beneficiaryType": "INDIVIDUAL",
      "fullName": "Test User"
    }
  }
}

# Step 2: Create the quote using the external account ID
POST /quotes

{
  "source": {
    "sourceType": "ACCOUNT",
    "accountId": "InternalAccount:abc123"
  },
  "destination": {
    "destinationType": "ACCOUNT",
    "accountId": "ExternalAccount:..."
  },
  "lockedCurrencySide": "SENDING",
  "lockedCurrencyAmount": 100000
}

The IBAN ending in 003 triggers the slow payment test pattern.

Executing Quotes in Sandbox

For quotes from an external account source, execute as in production via /quotes/{quoteId}/execute. The sandbox will:

Instantly process the currency conversion
Apply the test behavior based on any external accounts involved
Update transaction statuses immediately (no waiting for bank processing)
Trigger webhooks for state changes

For quotes with real-time funding (no source account), use the /sandbox/send endpoint to simulate the inbound payment. Reference the quote by ID and specify the funding currency:

POST /sandbox/send

{
  "quoteId": "Quote:019542f5-b3e7-1d02-0000-000000000006",
  "currencyCode": "USD"
}

currencyCode must match the quote’s funding-source currency. currencyAmount is optional — when omitted, the amount is derived from the quote.

Testing Webhooks

All webhook events fire normally in sandbox. To test your webhook endpoint:

Configure your webhook URL in the dashboard
Perform actions that trigger webhooks (transfers, quote execution, etc.)
Receive webhook events at your endpoint
Verify signature using the sandbox public key

You can also manually trigger a test webhook:

POST /sandbox/webhooks/test

{
  "url": "https://your-app.com/webhooks"
}

Common Testing Workflows

Complete Payout Flow Test

Here’s a complete test workflow for a USD → EUR payout:

Create customer and internal accounts (via regular API)

Fund customer’s USD internal account:

POST /sandbox/internal-accounts/InternalAccount:customer-usd/fund
{ "amount": 100000 }  # $1,000

Create a test external EUR account:

POST /customers/external-accounts
# Use default account number for success case

Create and execute a quote:

POST /quotes
# USD internal → EUR external

POST /quotes/{quoteId}/execute

Verify transaction status and webhooks

Testing Error Scenarios

Test each failure mode systematically:

# 1. Test insufficient funds
# Create external account ending in 002
POST /customers/external-accounts { "accountNumber": "000000002" }

# Attempt transfer-in - should fail immediately
POST /transfer-in

# 2. Test account closed
# Create external account ending in 003
POST /customers/external-accounts { "accountNumber": "000000003" }

# Attempt transfer-out - should fail immediately
POST /transfer-out

# 3. Test timeout scenario
# Create external account ending in 005
POST /customers/external-accounts { "accountNumber": "000000005" }

# Attempt transfer - should pend then fail after ~30s
POST /transfer-in
# Check status immediately - will show PENDING
GET /transactions/{transactionId}
# Wait 30s, check again - will show FAILED

Global Account magic values

The Grid sandbox accepts a small set of magic values for Global Account flows, so you can exercise the full request shape without standing up Turnkey, WebAuthn, or an OIDC provider. OTP, passkey, and wallet signatures use fixed sandbox-only values. OAuth uses JWT-shaped sandbox OIDC tokens: sandbox skips real IdP signature verification, but still validates the token claims, freshness, credential identity, and verify-time nonce binding. A wrong magic value or sandbox OIDC authentication failure returns 401 UNAUTHORIZED with a reason field that names the specific check that failed. A malformed OIDC JWT can return 400 INVALID_INPUT before authentication starts.

Email OTP code

Pass 000000 as the body otp on POST /auth/credentials/{id}/verify when the credential type is EMAIL_OTP. The sandbox skips OTP delivery and accepts this value as a valid response to the issued challenge.

curl -X POST https://api.lightspark.com/grid/2025-10-13/auth/credentials/AuthMethod:abc123/verify \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -H "Request-Id: 7c4a8d09-ca37-4e3e-9e0d-8c2b3e9a1f21" \
  -d '{
    "type": "EMAIL_OTP",
    "otp": "000000",
    "clientPublicKey": "04f45f2a..."
  }'

Any other code returns 401 UNAUTHORIZED with reason: "Invalid OTP code".

Passkey assertion signature

Pass sandbox-valid-passkey-signature as assertion.signature on POST /auth/credentials/{id}/verify when the credential type is PASSKEY. The sandbox accepts the rest of the assertion as-is and skips the WebAuthn signature check. Passkey reauthentication is a two-step /challenge → /verify flow. The clientPublicKey is sent on /challenge (so Grid can seal the session signing key to your device) — the magic value bypasses the credential check, not the HPKE plumbing, so the public key is still required.

# 1. /challenge with clientPublicKey
curl -X POST https://api.lightspark.com/grid/2025-10-13/auth/credentials/AuthMethod:abc123/challenge \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "clientPublicKey": "04f45f2a..."
  }'

# 2. /verify with the magic signature, no clientPublicKey
curl -X POST https://api.lightspark.com/grid/2025-10-13/auth/credentials/AuthMethod:abc123/verify \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -H "Request-Id: 7c4a8d09-ca37-4e3e-9e0d-8c2b3e9a1f21" \
  -d '{
    "type": "PASSKEY",
    "assertion": {
      "credentialId": "...",
      "clientDataJson": "...",
      "authenticatorData": "...",
      "signature": "sandbox-valid-passkey-signature"
    }
  }'

Any other signature returns 401 UNAUTHORIZED with reason: "Invalid passkey signature".

OAuth (OIDC) token

OAuth does not use a fixed magic token in sandbox. Pass a JWT-shaped OIDC token as oidcToken. The JWT signature segment can be a dummy value, but the payload must look like a real ID token. For POST /auth/credentials with type: "OAUTH", the sandbox token must include:

iss: a supported issuer, such as https://accounts.google.com, accounts.google.com, or https://appleid.apple.com
aud: a non-empty string, or a single-element string array
sub: a non-empty subject identifier for the user
iat: a numeric issued-at timestamp no more than 60 seconds before the request, with 5 seconds of clock skew allowed
exp: a numeric expiration timestamp later than the request time

Grid stores the OAuth credential’s registered identity from iss, aud, and sub. On POST /auth/credentials/{id}/verify, the fresh oidcToken must carry the same iss, aud, and sub as the credential being verified. It must also include nonce equal to sha256(clientPublicKey), where clientPublicKey is the exact hex public key sent in the verify request.

export PUBLIC_KEY="04f45f2a22c908b9ce09a7150e514afd24627c401c38a4afc164e1ea783adaaa31d4245acfb88c2ebd42b47628d63ecabf345484f0a9f665b63c54c897d5578be2"
OIDC_TOKEN=$(node - <<'NODE'
const crypto = require("crypto");

const publicKey = process.env.PUBLIC_KEY || "04f45f2a22c908b9ce09a7150e514afd24627c401c38a4afc164e1ea783adaaa31d4245acfb88c2ebd42b47628d63ecabf345484f0a9f665b63c54c897d5578be2";
const now = Math.floor(Date.now() / 1000);
const b64url = (value) =>
  Buffer.from(JSON.stringify(value)).toString("base64url");

const payload = {
  iss: "https://accounts.google.com",
  sub: "sandbox-user-123",
  aud: "grid-sandbox-oauth-client-id",
  iat: now,
  exp: now + 300,
  nonce: crypto.createHash("sha256").update(publicKey).digest("hex"),
  email: "sandbox-user-123@example.com",
  email_verified: true
};

console.log(
  `${b64url({ alg: "RS256", typ: "JWT" })}.${b64url(payload)}.sandbox-signature`
);
NODE
)

curl -X POST https://api.lightspark.com/grid/2025-10-13/auth/credentials/AuthMethod:abc123/verify \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -H "Request-Id: 7c4a8d09-ca37-4e3e-9e0d-8c2b3e9a1f21" \
  -d '{
    "type": "OAUTH",
    "oidcToken": "'"$OIDC_TOKEN"'",
    "clientPublicKey": "'"$PUBLIC_KEY"'"
  }'

The old literal sandbox-valid-oidc-token is no longer accepted. Use a freshly generated sandbox JWT for both OAuth credential registration and OAuth verification. Production requires a real ID token from your provider and verifies the provider signature.

Wallet signature header

Pass sandbox-valid-signature as the Grid-Wallet-Signature HTTP header on any signed-retry flow:

POST /auth/credentials (add-additional-credential signed retry)
DELETE /auth/credentials/{id} (revoke credential)
DELETE /auth/sessions/{id} (revoke session)
POST /internal-accounts/{id}/export (export wallet)
PATCH /internal-accounts/{id} (update wallet privacy)
POST /quotes/{quoteId}/execute (when source is an embedded wallet)

curl -X POST https://api.lightspark.com/grid/2025-10-13/quotes/Quote:abc123/execute \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 7c4a8d09-ca37-4e3e-9e0d-8c2b3e9a1f21" \
  -H "Grid-Wallet-Signature: sandbox-valid-signature"

Any other header value returns 401 UNAUTHORIZED with reason: "Invalid Grid-Wallet-Signature".

Sandbox Limitations

While sandbox closely mimics production, there are some differences:

Instant settlement: All transfers complete immediately (success cases) or fail immediately (error cases), except timeout scenarios (005)
No real bank validation: Account numbers aren’t validated against real banking networks
Simplified KYC: KYC processes are simulated and complete instantly. You must add customers via the /customers endpoint, rather than using the KYC link flow.
Fixed exchange rates: Currency conversion rates may not reflect real-time market rates.

Do not try sending money to any sandbox addresses or accounts. These are not real addresses and will not receive money.

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

Review Webhooks for event handling
Check out the Postman Collection for API examples
See Error Handling for production error strategies

Documentation Index

​Overview

​Getting Started with Sandbox

​Sandbox Credentials

​Simulating Money Movements

​Funding Internal Accounts

​Testing Transfer Scenarios

​Adding Test External Accounts

​Beneficiary name verification

​Testing Transfer-In (Pull from External Account)

​Testing Transfer-Out (Push to External Account)

​Testing Cross-Currency Quotes

​Creating Quotes with Test Accounts

​Executing Quotes in Sandbox

​Testing Webhooks

​Common Testing Workflows

​Complete Payout Flow Test

​Testing Error Scenarios

​Global Account magic values

​Email OTP code

​Passkey assertion signature

​OAuth (OIDC) token

​Wallet signature header

​Sandbox Limitations

​Moving to Production

​Next Steps

Overview

Getting Started with Sandbox

Sandbox Credentials

Simulating Money Movements

Funding Internal Accounts

Testing Transfer Scenarios

Adding Test External Accounts

Beneficiary name verification

Testing Transfer-In (Pull from External Account)

Testing Transfer-Out (Push to External Account)

Testing Cross-Currency Quotes

Creating Quotes with Test Accounts

Executing Quotes in Sandbox

Testing Webhooks

Common Testing Workflows

Complete Payout Flow Test

Testing Error Scenarios

Global Account magic values

Email OTP code

Passkey assertion signature

OAuth (OIDC) token

Wallet signature header

Sandbox Limitations

Moving to Production

Next Steps