Sandbox testing

Exercise the Global Account auth, signing, and funding flows without standing up real OTP delivery, WebAuthn, or OIDC providers

The Grid sandbox lets you exercise the full Global Accounts integration — customer creation, account lookup, credential registration, funding, and signed withdrawals — without moving real money or standing up real auth providers. All API endpoints work the same way as in production, but money movements are simulated. OTP uses a fixed sandbox code, passkey assertions and wallet signatures are verified as in production, and OAuth uses JWT-shaped sandbox OIDC tokens with claim, freshness, identity, and nonce checks.

​

Sandbox setup

To use the sandbox environment:

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

In sandbox, customers are KYC-approved on creation, and a Global Account is provisioned automatically alongside any other internal accounts whenever the platform has USDB in its supported currencies.

​

Funding a Global Account

Real Global Accounts are funded by following payment instructions or by executing a quote into the account. In sandbox, you can instantly add USDB to any internal account using the sandbox funding endpoint:

curl -X POST "$GRID_BASE_URL/sandbox/internal-accounts/InternalAccount:abc123/fund" \
  -u "$GRID_CLIENT_ID:$GRID_CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 100000
  }'

This credits the account immediately and fires the standard INCOMING_PAYMENT webhook. Use this to skip straight to a funded state when you’re testing withdrawals.

​

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:

1. Call POST /auth/credentials/{id}/challenge to get otpEncryptionTargetBundle
2. 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.
3. Submit encryptedOtpBundle to POST /auth/credentials/{id}/verify
4. Receive 202 with payloadToSign and requestId
5. 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.

1. Create a WebAuthn credential

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

2. Register the passkey

   Register the passkey with POST /auth/credentials, passing the challenge and attestation returned by the browser.

3. 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.

4. Run the browser assertion

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

5. 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: "[e-mail]",
  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.

​

Webhooks

All webhook events fire normally in sandbox. Configure your webhook URL in the dashboard, perform any signed action, and your endpoint receives the same INCOMING_PAYMENT, OUTGOING_PAYMENT, and account-state events as production.

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

​

Moving to production

When you’re ready to go live:

1. Generate production API tokens in the dashboard and swap them for the sandbox credentials in your environment.
2. Remove sandbox magic values and unsigned sandbox OIDC tokens from your client and server code — production runs the real OTP, HPKE, WebAuthn, OIDC signature, and ECDSA flows.
3. Configure production webhook endpoints.
4. Test with small amounts first.

​

Next steps

• Implementation overview — end-to-end walkthrough of the happy path.
• Authentication — per-credential-type registration and reauthentication flows.
• Webhooks — event handling reference.