How to set up a Bridge virtual account to receive USDC

Bridge virtual accounts are permanent fiat deposit addresses that convert incoming local currency into a stablecoin destination specified by the platform, typically USDC on a chosen chain or USDB held in a Bridge wallet. The deposit instructions resemble bank account details, but incoming funds settle through Bridge’s conversion path rather than as an FDIC-linked account.

Platforms must complete customer onboarding and KYC/KYB approval on Bridge before creating a virtual account. After approval, create the account via Bridge’s API by POSTing to /v0/customers/<customer_id>/virtual_accounts with an Api-Key and a unique Idempotency-Key. Set source.currency to the payer’s fiat (usd, eur, mxn, brl, gbp, cop) and set a concrete destination such as a chain address for USDC or a Bridge wallet for USDB.

The API response returns source_deposit_instructions. For USD those instructions include a Lead Bank routing number and an account number for ACH push and wire. Platforms should pass those fields unchanged to payers and must not substitute an on-chain address into bank payment fields.

Each source currency maps to a local rail: USD supports ACH push and wire, EUR issues a virtual IBAN for SEPA, MXN returns a CLABE for SPEI, BRL returns a PIX BR code, GBP (beta) provides Faster Payments details, and COP (beta) returns a Bre-B key. Virtual accounts are reusable and present local deposit rails to payers.

Bridge emits VirtualAccountEvent states to track deposits. Typical states include funds_received, funds_scheduled, payment_submitted and payment_processed. Events such as in_review, refunded and microdeposit also appear. Reconcile events by deposit_id and store the destination_tx_hash and receipt URL alongside invoice or payout records.

Do not record a bank credit or an ACH funds_scheduled state as settled treasury cash. Treat funds as received only when Bridge reports payment_processed and returns a destination transaction hash or equivalent on-chain receipt.

Bridge supports an optional developer_fee_percent on account creation that lets a platform withhold a conversion fee. Documentation advises disclosing the net USDC expected by the recipient in commercial terms to reduce disputes.

Operational risks include routing funds to a chain or rail your custody cannot redeem, treating in-transit ACH states as final, and overlooking product limits on PIX, Bre-B and Faster Payments. Review the current Bridge corridor documentation for limits and beta restrictions before offering a rail to payers.

Bridge documentation notes that teams already using Stripe Treasury may prefer Treasury when they only need a Dashboard USDC balance. Platforms should use Bridge virtual accounts when they require customer-named local deposit rails that auto-convert into a wallet they control.

Documentation recommends beginning with one corridor, commonly USD ACH/wire or EUR SEPA, creating a KYB-approved customer virtual account to a custody address you already redeem, and running a small $1–$100 test. Only expand corridors and enable developer fees after a test reaches payment_processed and returns a destination transaction hash.