Sandbox Testing

The Grid sandbox environment allows you to test your integration without making real payments. When you set up your account, you can configure production and sandbox API tokens. The sandbox token is specifically for testing and development purposes. It corresponds to a separate platform instance in “sandbox” mode, which can only transact with the sandbox UMA addresses for testing.

Overview

The sandbox environment provides:

A dedicated sandbox platform for testing
Test UMA addresses for simulating payments
Endpoints to simulate sending and receiving payments
All the same webhooks and flows as production, but with simulated funds

Test UMA Addresses

The sandbox provides several test UMA addresses you can use to simulate different scenarios:

UMA Address	Description
`$success.usd@sandbox.uma.money`	Always succeeds, sends USD
`$success.eur@sandbox.uma.money`	Always succeeds, sends EUR
`$success.mxn@sandbox.uma.money`	Always succeeds, sends MXN
`$pending.long.usd@sandbox.uma.money`	Simulates a long-pending payment
`$fail.compliance.usd@sandbox.uma.money`	Simulates compliance check failure
`$fail.payout.compliance.usd@sandbox.uma.money`	Payout fails with `failureReason: COMPLIANCE_REJECTED`
`$fail.payout.accountinvalid.usd@sandbox.uma.money`	Payout fails with `failureReason: ACCOUNT_INVALID`
`$fail.payout.cannotreceive.usd@sandbox.uma.money`	Payout fails with `failureReason: ACCOUNT_CANNOT_RECEIVE`
`$fail.payout.limitexceeded.usd@sandbox.uma.money`	Payout fails with `failureReason: LIMIT_EXCEEDED`

Testing Outgoing Payments

To test sending payments from your platform, follow these steps:

Look up a sandbox UMA address:

curl -X GET "https://api.lightspark.com/grid/2025-10-13/receiver/uma/\$success.usd@sandbox.uma.money" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET"

Create a quote as normal:

curl -X POST "https://api.lightspark.com/grid/2025-10-13/quotes" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "lookupId": "Lookup:019542f5-b3e7-1d02-0000-000000000009",
    "source": {
      "sourceType": "REALTIME_FUNDING",
      "currency": "MXN"
    },
    "destination": {
      "destinationType": "UMA_ADDRESS",
      "umaAddress": "$success.usd@sandbox.uma.money"
    },
    "lockedCurrencySide": "SENDING",
    "lockedCurrencyAmount": 10000
  }'

Instead of making a real bank transfer, use the sandbox send endpoint with the quote ID:

curl -X POST "https://api.lightspark.com/grid/2025-10-13/sandbox/send" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "quoteId": "Quote:019542f5-b3e7-1d02-0000-000000000006",
    "currencyCode": "USD"
  }'

The sandbox will simulate the payment and send appropriate webhooks just like in production.

Testing Incoming Payments

To test receiving payments to your platform’s users, use the sandbox receive endpoint:

curl -X POST "https://api.lightspark.com/grid/2025-10-13/sandbox/uma/receive" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "senderUmaAddress": "$success.usd@sandbox.uma.money",
    "receiverUmaAddress": "$your.user@your.domain",
    "receivingCurrencyCode": "USD",
    "receivingCurrencyAmount": 5000
  }'

This will trigger the same webhook flow as a real incoming payment:

You’ll receive an INCOMING_PAYMENT webhook with status: "PENDING"
Your platform should approve/reject the payment
On approval, you’ll receive another webhook with status: "COMPLETED"

Example Testing Flow

Here’s a complete example of testing both directions of payments:

First, register a test customer:

curl -X POST "https://api.lightspark.com/grid/2025-10-13/customers" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "platformCustomerId": "test_123",
    "customerType": "INDIVIDUAL",
    "fullName": "Test User",
    "birthDate": "1990-01-01",
    "nationality": "US",
    "address": {
      "line1": "123 Test St",
      "city": "Testville",
      "state": "TS",
      "postalCode": "12345",
      "country": "US"
    }
  }'

The response includes the customer’s auto-generated umaAddress, which you can use as the receiverUmaAddress below.

Test receiving a payment:

curl -X POST "https://api.lightspark.com/grid/2025-10-13/sandbox/uma/receive" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "senderUmaAddress": "$success.usd@sandbox.uma.money",
    "receiverUmaAddress": "$test.user@your.domain",
    "receivingCurrencyCode": "USD",
    "receivingCurrencyAmount": 5000
  }'

Test sending a payment:

# 1. Look up recipient
curl -X GET "https://api.lightspark.com/grid/2025-10-13/receiver/uma/\$success.usd@sandbox.uma.money" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET"

# 2. Create quote
curl -X POST "https://api.lightspark.com/grid/2025-10-13/quotes" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "lookupId": "Lookup:019542f5-b3e7-1d02-0000-000000000009",
    "source": {
      "sourceType": "REALTIME_FUNDING",
      "currency": "MXN"
    },
    "destination": {
      "destinationType": "UMA_ADDRESS",
      "umaAddress": "$success.usd@sandbox.uma.money"
    },
    "lockedCurrencySide": "SENDING",
    "lockedCurrencyAmount": 10000
  }'

# 3. Simulate sending payment
curl -X POST "https://api.lightspark.com/grid/2025-10-13/sandbox/send" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "quoteId": "Quote:019542f5-b3e7-1d02-0000-000000000006",
    "currencyCode": "USD"
  }'

Testing Error Scenarios

You can test various error scenarios using the special sandbox UMA addresses:

Test compliance failures:

curl -X GET "https://api.lightspark.com/grid/2025-10-13/receiver/uma/\$fail.compliance.usd@sandbox.uma.money" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET"
# ... create quote and attempt payment

Test long-pending payments:

curl -X GET "https://api.lightspark.com/grid/2025-10-13/receiver/uma/\$pending.long.usd@sandbox.uma.money" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET"
# ... create quote and attempt payment

Non-existent UMA address:

curl -X GET "https://api.lightspark.com/grid/2025-10-13/receiver/uma/\$non.existent.usd@sandbox.uma.money" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET"
# ... should return 404 Not Found

Each of these will trigger appropriate error webhooks and status updates to help you test your error handling.

Global Account magic values

The Grid sandbox lets you exercise Global Account auth flows without moving real money. Email OTP and SMS OTP use the fixed sandbox code 000000 — HPKE-encrypt that code in the encryptedOtpBundle just like production. Passkey auth can use the same browser WebAuthn ceremony as production, and signed wallet actions can use the same session signing key and Grid-Wallet-Signature stamp as production. OAuth uses JWT-shaped sandbox OIDC tokens: sandbox skips real IdP signature verification, but still validates token claims, freshness, credential identity, and verify-time nonce binding. Sandbox runs real HPKE end-to-end for EMAIL_OTP and SMS_OTP: clients build a real encryptedOtpBundle against the sandbox otpEncryptionTargetBundle and stamp the exact returned payloadToSign string with their TEK keypair. The only sandbox shortcut is the magic OTP code the user “receives” instead of a real email or SMS delivery. Authentication failures return 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 and SMS OTP code

HPKE-encrypt the code 000000 (together with your TEK public key) inside encryptedOtpBundle. The sandbox skips email and SMS delivery but runs real HPKE decryption and signature verification. See Encrypt the OTP code for how to build the bundle. The flow is the same for both EMAIL_OTP and SMS_OTP:

Call POST /auth/credentials/{id}/challenge to get otpEncryptionTargetBundle
Generate a TEK key pair and HPKE-encrypt {otp_code: "000000", public_key: tekPublicKeyHex}. Use the compressed public key (02 or 03 prefix) so the same code works in production.
Submit encryptedOtpBundle to POST /auth/credentials/{id}/verify
Receive 202 with payloadToSign and requestId
Sign payloadToSign with the TEK private key and retry with Grid-Wallet-Signature + Request-Id headers

# First leg — returns 202 with payloadToSign
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" \
  -d '{
    "type": "EMAIL_OTP",
    "encryptedOtpBundle": "{\"encappedPublic\":\"044f631a...\",\"ciphertext\":\"1fa1023390...\"}"
  }'

# Signed retry — returns 200 with AuthSession
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 "Grid-Wallet-Signature: eyJwdWJsaWNLZXkiOiIwMmExYjIuLi4i..." \
  -H "Request-Id: Request:7c4a8d09-ca37-4e3e-9e0d-8c2b3e9a1f21" \
  -d '{
    "type": "EMAIL_OTP",
    "encryptedOtpBundle": "{\"encappedPublic\":\"044f631a...\",\"ciphertext\":\"1fa1023390...\"}"
  }'

Any other code (once decrypted) returns 401 UNAUTHORIZED with reason: "Invalid OTP code".

Passkey WebAuthn ceremony

For new sandbox integrations, use the same WebAuthn calls you plan to use in production.

Create a WebAuthn credential

Generate your own WebAuthn registration challenge and call navigator.credentials.create().

Request a challenge

Reauthenticate with POST /auth/credentials/{id}/challenge, passing the compressed P-256 clientPublicKey (lowercase hex) whose private key becomes the session signing key.

Run the browser assertion

Pass the returned challenge into navigator.credentials.get() using the returned credentialId in allowCredentials.

Verify the assertion

Verify with POST /auth/credentials/{id}/verify, passing the browser assertion and echoing Request-Id from the challenge response.

The sandbox validates the registered credential ID, WebAuthn challenge, origin/RP binding, user-presence bit, assertion signature, and signature counter. A successful verify response returns the session, just like production. The private key matching the clientPublicKey is the session signing key.

# 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": "02f45f2a22c908b9ce09a7150e514afd24627c401c38a4afc164e1ea783adaaa31"
  }'

# 2. /verify with the browser assertion returned by navigator.credentials.get()
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: Request:7c4a8d09-ca37-4e3e-9e0d-8c2b3e9a1f21" \
  -d '{
    "type": "PASSKEY",
    "assertion": {
      "credentialId": "...",
      "clientDataJson": "...",
      "authenticatorData": "...",
      "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 the lowercase hex SHA-256 digest of clientPublicKey, hashed as the exact string sent in the verify request. That string is the compressed public key in lowercase hex: 66 characters starting with 02 or 03.

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

const publicKey = process.env.PUBLIC_KEY || "02f45f2a22c908b9ce09a7150e514afd24627c401c38a4afc164e1ea783adaaa31";
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" \
  -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

For PASSKEY and OAUTH credentials and session refresh, the private key matching the clientPublicKey you supplied is the session signing key. For EMAIL_OTP, the TEK private key you generated for the encrypted OTP flow is the session signing key. Use the session signing key to build a Grid wallet signature over the exact payloadToSign string returned by Grid, then pass that full signature as the Grid-Wallet-Signature HTTP header on signed flows:

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)

This example uses the sample signer in the Grid API repo’s scripts directory. See the scripts README for setup, or replace SIGN with your own Grid wallet-signature implementation.

SIGN="node $(pwd)/scripts/embedded-wallet-sign.js"
STAMP=$($SIGN stamp "$SESSION_PRIV_HEX" "$PAYLOAD_TO_SIGN")

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: $STAMP"

Sandbox validates that the signature is a P-256 signature over the exact pending Grid payload and that the public key belongs to an active sandbox session for the wallet.

Production vs Sandbox

Here are the key differences between production and sandbox environments:

API Tokens: Sandbox tokens only work in the sandbox environment and vice versa
Bank Transfers: In sandbox, you use /sandbox/send instead of real bank transfers
Test UMA Addresses: Special sandbox addresses for testing different scenarios
Money: No real money is moved in sandbox

Always test thoroughly in sandbox before moving to production!

Overview

Onboarding

Managing accounts

Sending & receiving payments

Global Accounts

Platform tools

Overview

Test UMA Addresses

Testing Outgoing Payments

Testing Incoming Payments

Example Testing Flow

Testing Error Scenarios

Global Account magic values

Email and SMS OTP code

Passkey WebAuthn ceremony

OAuth (OIDC) token

Wallet signature header

Production vs Sandbox

​Overview

​Test UMA Addresses

​Testing Outgoing Payments

​Testing Incoming Payments

​Example Testing Flow

​Testing Error Scenarios

​Global Account magic values

​Email and SMS OTP code

​Passkey WebAuthn ceremony

​OAuth (OIDC) token

​Wallet signature header

​Production vs Sandbox

Overview

Test UMA Addresses

Testing Outgoing Payments

Testing Incoming Payments

Example Testing Flow

Testing Error Scenarios

Global Account magic values

Email and SMS OTP code

Passkey WebAuthn ceremony

OAuth (OIDC) token

Wallet signature header

Production vs Sandbox