Table of Contents
A Bridge virtual account is a permanent fiat deposit address that converts incoming local currency into a crypto destination you name, usually USDC on a chosen rail.
Open one only after the customer is KYC/KYB-approved on Bridge (a Stripe company). Then POST a virtual account with a source currency and a destination (payment rail, currency, address or Bridge wallet). Share the returned deposit instructions.
Treat payment_processed plus the destination tx hash as cash received, not the bank credit alone.
This guide covers how to open and operate that object. For platform context, see the Bridge review (2026). For cash-out after USDC lands, see how to off-ramp USDC to ACH or wire.
Key Takeaways
- KYC/KYB the customer on Bridge before you create any virtual account.
- Set source.currency and a concrete destination (rail, USDC/USDB, address or Bridge wallet).
- USD accounts issue Lead Bank routing plus account numbers for ACH push and wire.
- EUR, MXN, BRL, GBP, and COP each map to a local rail (SEPA, SPEI, PIX, Faster Payments, Bre-B).
- Confirm receipt on payment_processed and the destination tx hash, not the bank credit alone.
What a Bridge virtual account actually is
Bridge documents virtual accounts as permanent, reusable fiat deposit addresses. Incoming fiat converts and ships to the crypto destination you configured.
A USD virtual account returns U.S. account and routing numbers. An EUR account returns a virtual IBAN for SEPA. MXN returns a CLABE for SPEI. BRL returns a BR code for PIX. GBP (beta) returns Faster Payments details. COP (beta) returns a Bre-B key.
Named downside: the deposit instructions look like a bank account, but redemption and custody follow Bridge's stablecoin path, not FDIC pass-through on that virtual number. Do not sell it to finance as "your FDIC checking account."
Who this is for (and who should skip it)
Use a Bridge virtual account when a fintech, payroll, marketplace, or treasury desk needs named local deposit rails that land as USDC (or USDB in a Bridge wallet) without building each rail yourself.
Skip it when you only need a one-off Circle Mint redemption, a simple venue cash-out, or a self-custody receive with no fiat front door. Those jobs map better to how to get paid in USDC or a processor off-ramp.
Slash is the public scale proof Bridge cites: industry banking for the digital economy, integrated through Bridge, and scaled to $1 billion in annualized stablecoin volume within its first year. Bridge also states the platform has moved tens of billions in stablecoin transactions. Treat those as vendor claims, then verify your own corridor volumes in pilot.
Open checklist (2026)
1. Onboard the customer
Customers must be onboarded and KYC/KYB-approved before you create virtual accounts. No approval, no VA.
Collect the same identity package your compliance stack already uses for USDC payins. Do not invent a lighter path just because the UI shows a routing number.
2. Create the virtual account
POST to https://api.bridge.xyz/v0/customers/<customer_id>/virtual_accounts with your Api-Key and a unique Idempotency-Key.
Set source.currency to the fiat you want the payer to send (usd, eur, mxn, brl, gbp, cop). Set destination to where Bridge should deliver after conversion.
Example from Bridge docs: Ethereum rail, usdc, and a hex address. You can also route into a Bridge wallet and hold USDB when that pattern fits custody.
Optional: developer_fee_percent (Bridge's example uses "1.0" for 1%) so your platform withholds a cut on the conversion. Price that against the commercial invoice the same way you would a processor take rate.
3. Share deposit instructions
Read source_deposit_instructions from the response. For USD, Bridge's documented example includes Lead Bank, routing 101019644, an account number, beneficiary name, and rails ach_push and wire.
Give the payer only those fields. Do not paste an on-chain address into an ACH memo and hope the bank figures it out.
4. Monitor events until payment_processed
Bridge tracks each deposit as a VirtualAccountEvent. Watch for funds_received, funds_scheduled (ACH in transit), payment_submitted, then payment_processed (on-chain final).
Also handle in_review, refunded, microdeposit (verification only, never onramped), plus account deactivation / reactivation.
Reconcile on deposit_id across events for the same bank credit. Store destination_tx_hash and the receipt URL next to the invoice or payout id.
5. Decide what "received" means in your ledger
Bank credit is not treasury cash until the destination balance moves. For AP and AR, match the commercial dollar amount to the final stablecoin amount after developer and exchange fees shown on the event.
If the counterparty still needs dollars in a bank, run a separate off-ramp after USDC lands. See how to off-ramp USDC to ACH or wire.
Fiat rails compared (as of September 2026)
| Source currency | Local rail (Bridge docs) | What the payer sees | Destination example | Notes |
|---|---|---|---|---|
| USD | ACH push, wire | Lead Bank routing + account number | USDC on configured rail / Bridge wallet | Permanent reusable VA |
| EUR | SEPA | Virtual IBAN + BIC | USDC (configured rail) | Modulr Ireland branch in Bridge example |
| MXN | SPEI | CLABE | USDC (configured rail) | Mexico corridor |
| BRL | PIX | BR code | USDC (configured rail) | 1st-party and 3rd-party business payments only |
| GBP | Faster Payments (beta) | Account number + sort code | USDC (configured rail) | Beta |
| COP | Bre-B (beta) | Bre-B key | USDC (configured rail) | Beta; business payments only |
Primary source: Bridge virtual accounts guide. Product framing: Bridge orchestration.
How this differs from a Stripe USDC Treasury balance
Stripe Treasury can hold a USDC stablecoin balance in a financial account, with Bridge acting as custodian of that stablecoin balance (per Stripe docs as of 2026). Funding paths and Dashboard UX differ from a developer-created Bridge VA.
If your stack is already Stripe-native and you only need a Dashboard USDC balance, read Stripe's stablecoins in Treasury path. If you need customer-named local deposit instructions that auto-convert into a wallet you control, stay on the Bridge Virtual Accounts API.
Operational pitfalls
Wrong destination rail. Landing USDC on a chain your custody cannot redeem wastes a day of ops. Confirm native Circle USDC (or the USDB Bridge-wallet path) before go-live.
Treating ACH funds_scheduled as settled. ACH can still fail or land in in_review. Wait for payment_processed.
BRL/GBP/COP constraints. PIX and Bre-B business-payment limits and GBP beta status are product constraints, not suggestions. Read the current Bridge docs for your corridor before promising consumer PIX.
Fee opacity in the commercial quote. If you set developer_fee_percent, show the net USDC the recipient should expect. Silent 1% cuts create dispute tickets that look like depegs.
Related playbooks
Invoice and settle in USDC when the commercial amount is already quoted in dollars: how to invoice in stablecoins.
Pay suppliers after the VA has funded treasury: how to pay suppliers in USDC.
FAQ
How do I open a Bridge virtual account for USDC?
Onboard and KYC/KYB the customer on Bridge, then POST /v0/customers/<id>/virtual_accounts with a source fiat currency and a USDC (or USDB) destination. Share source_deposit_instructions with the payer.
What bank rails does a Bridge USD virtual account support?
Bridge's USD example supports ACH push and wire against Lead Bank routing and account numbers issued in the customer's name.
When should I mark a Bridge virtual-account deposit as received?
Mark it received when you see payment_processed and a destination_tx_hash (or equivalent receipt), not when the bank alone shows a credit.
Should I use Bridge virtual accounts or Circle Mint for fiat in?
Use Bridge VAs when you need customer-named local deposit rails that convert into a wallet destination. Use Circle Mint when you already bank with Circle and want direct USDC mint/redeem as a vetted business.
What is the downside of Bridge virtual accounts?
You inherit Bridge corridor limits, review states, and fee lines, and the VA is not an FDIC checking account. Teams that need only issuer redemption should skip the extra orchestration layer.
Can I charge my own fee on Bridge virtual account deposits?
Yes. Bridge documents an optional developer_fee_percent on create (example "1.0" = 1%). Disclose the net to the counterparty in the commercial terms.
Next step
Pick one corridor (usually USD ACH/wire or EUR SEPA), create one KYB-approved customer VA into a custody address you already redeem, and run a $1–$100 test until payment_processed lands. Only then turn on developer_fee_percent and a second currency.
This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy or sell any financial instrument, and readers should conduct their own independent research or consult a qualified professional.
){kind=link}