type: "EMBEDDED_WALLET" that participates in the standard Grid customer, quote, transaction, and webhook flows.
Why a Grid Global Account?
- Self-custody. Grid never has unilateral access to move user funds, and neither do you. The customer’s device is the only party that can authorize a transaction.
- Stablecoin-denominated. Balances are held as stablecoins like Brale-issued USDB. Use the standard
/quotesAPI to convert in from fiat or out to any supported Grid bank-account rail (ACH, PIX, CLABE, UPI, IBAN, UMA, …). - Grid-native. You reuse the customer, internal-account, quote, transaction, and webhook primitives you already integrated for Payouts or P2P. The only thing that’s new is an auth + signing layer at the account.
- Built on Bitcoin. Global Accounts run on Spark, a Lightning-compatible Bitcoin L2 that supports instant, low-fee Bitcoin and Stablecoin transfers. You get the benefits of running on Bitcoin, the most neutral, decentralized, and secure network for money.
Payment flow
Grid Global Accounts ride on the same/quotes + /quotes/{id}/execute pattern as every other Grid payment. The only thing that’s different is that outbound transfers need a client signature.
- Incoming funds. Funding an account works like any other internal account. Create a quote with the Global Account as the
destination, execute it, and Grid converts the source currency into USDB and credits the account. No customer approval needed — incoming value is passive. - Outgoing funds. Withdrawals and transfers out require the customer to authorize them on their device. Grid returns a
payloadToSignin the quote’spaymentInstructions; the client signs those bytes with its session signing key and passes the base64 signature as theGrid-Wallet-Signatureheader on/quotes/{id}/execute. Only then does Grid release the funds.
Architecture
Three parties participate in every signed action:
The client never talks to Grid directly. Every request flows client → integrator backend → Grid.
Auth credentials, client keys, and session signing keys
Three distinct pieces of crypto collaborate to authorize actions on the Global Account (withdrawals, credential changes, session revocations, wallet exports, and wallet privacy updates):
The flow is always the same: verify an auth credential → receive a short-lived session signing key → build a Grid wallet signature over the
payloadToSign bytes on the client → pass that signature as the Grid-Wallet-Signature header on the request that actually moves funds or changes account state. This applies to withdrawals, adding or removing credentials, refreshing or revoking sessions, exporting the wallet seed, updating customer email for tied email OTP credentials, and updating wallet privacy.
Prerequisites
You also need:- A platform configured with
USDBin its supported currencies. In sandbox, USDB is enabled by default alongsideUSDandUSDC. - Sandbox or production API credentials with access to the
Embedded Wallet AuthandInternal Accountsendpoints.
Walkthrough
The walkthrough below is the happy path: create a customer, find the auto-provisioned account and its default email OTP credential, fund it, and withdraw to a bank account. Each step shows the HTTP request your integrator backend makes on behalf of the client.1. Create a customer
Create the customer record. A Global Account is provisioned automatically whenever a customer is created on a platform that hasUSDB in its supported currencies — you don’t need to pass it on the customer.
201 Created with the new Customer:... id. In sandbox, the customer is KYC-approved immediately; in production you would now run them through the KYC / KYB flow before any funds can move.
2. Find the Global Account
When a customer is created on a USDB-enabled platform, Grid automatically provisions a Global Account alongside their other internal accounts. Fetch it by filtering the customer’s internal accounts bytype=EMBEDDED_WALLET.
InternalAccount:... id — every auth credential is scoped to it.
3. Find the default email OTP credential
Global Accounts are initialized with anEMAIL_OTP credential tied to the customer email on file. Fetch the auth methods for the account and keep the AuthMethod:... id for the signing step later in this walkthrough.
4. Fund the Account
Global Accounts behave like any other internal account on the way in — incoming funds do not need the customer’s signature. In sandbox, use the sandbox funding endpoint to skip straight to a funded state:amount is in the smallest unit of the account’s currency. USDB has 6 decimals, so 1000000000 is 1,000.00 USDB.
You will receive an INCOMING_PAYMENT webhook when the balance updates. The account now holds 1,000.00 USDB.
5. Add an external bank account
Add the destination the customer wants to withdraw to. This is a standard external account — nothing Global Account-specific.201 Created with the new ExternalAccount:... id.
6. Create a withdrawal quote
Create a quote with the Global Account as the source. Grid returns apayloadToSign in the quote’s payment instructions — this is what the client will sign to authorize the transfer.
lockedCurrencyAmount is in the smallest unit of the locked side’s currency. Here the sending currency is USDB (6 decimals), so 10000000 is 10.00 USDB.
Response:
7. Authenticate and sign
The customer has an outstanding quote with apayloadToSign. Now we need a session signing key to sign it with. With EMAIL_OTP, the client generates a TEK (Target Encryption Key) pair, HPKE-encrypts the OTP code, and uses the TEK private key both to complete login and to sign the quote payload.
1
Your backend requests a fresh OTP
Ask Grid to send a fresh OTP email for the default Response (200):Return
EMAIL_OTP credential. The response includes otpEncryptionTargetBundle for the secure OTP flow.otpEncryptionTargetBundle to the client.2
Client encrypts the OTP and verifies
The client generates a fresh P-256 key pair (the TEK), HPKE-encrypts Response (202):Return
{otp_code, public_key} under otpEncryptionTargetBundle, and sends the encrypted bundle to your backend. In sandbox, use OTP code 000000.Your backend calls verify with the encrypted bundle:payloadToSign and requestId to the client.3
Client signs the verification token and completes login
The client stamps Response (200):The TEK public key is now the session API key. The TEK private key is the session signing key — the client already has it.
payloadToSign with the TEK private key and sends the stamp back to your backend.Your backend retries the same request with the stamp:4
Client stamps the quote payload
The client signs the quote’s
payloadToSign with the same TEK private key. Return the full Grid wallet signature to your backend./challenge + /verify round-trip.
8. Execute the quote
Call/execute with the stamp in the Grid-Wallet-Signature header.
OUTGOING_PAYMENT) as it settles — see Transaction lifecycle.
Where to next
Client keys & signing
Generate the P-256 key pair, decrypt the session signing key, and sign payloads on Web, iOS, and Android.
Authentication
OAuth and Email OTP flows, passkey reauthentication, and the full WebAuthn parameter mapping.
Sessions
List, refresh, and revoke active sessions.
Exporting a wallet
Let a customer take their wallet seed off Grid.