How to Issue Stripe Stablecoin-Backed Cards with Bridge

Stripe is running a private preview that connects Stripe Issuing to Bridge, Privy and third-party stablecoin wallets so prepaid and debit cards can pull USDC just-in-time at Visa terminals. The integration is available through Stripe sales and requires a Bridge App Install Link to activate Issuing on a connected Stripe account.

Operators create a Bridge Customer to handle KYC and request a cards endorsement. After approval, Bridge returns a stripe_cardholder_id for consumer customers or a stripe_account_id for business customers. Issuers then call Stripe’s POST /v1/issuing/cards endpoint and include a crypto_wallet object to bind the card to a wallet. At authorization the card can pull USDC through Bridge’s onchain flow when required.

Onboarding requires a Bridge developer account and a Stripe account. Bridge provides an App Install Link that associates the two and activates Issuing. Stripe’s published timeline shows sandbox access after signing an addendum, roughly two weeks for production testing with about 10 internal users, and 6-8 weeks from onboarding start to support external customers. After the first call teams receive an Asana board with required documents and deadlines so technical work on chains and fund flows can proceed in parallel.

Cards endorsement requires recent KYC or confirmed information. Bridge’s rules revoke the endorsement if a card is not created within 24 hours, and the Stripe cardholder becomes inactive until the endorsement is re-requested. Operators must plan endorsement requests and card creation to avoid repeated re-submissions.

When creating a card, the issuer submits standard Stripe Issuing parameters plus a crypto_wallet object that specifies the chain, stablecoin currency, wallet type and wallet address. Stripe and Bridge documentation list example chain values such as solana, tempo, base, linea and world_chain, with currency typically set to usdc. A crypto_wallet type of standard identifies a non-custodial wallet that must grant an onchain approval to Bridge’s contract before authorizations will succeed. A crypto_wallet type of bridge_wallet signals funding from a Bridge-custodied wallet and removes the separate onchain approval step for the cardholder.

For non-custodial Solana integrations, Stripe’s docs cite Bridge’s mainnet program id and require an approval against a program-derived address tied to a Bridge-assigned MERCHANT_ID. On EVM chains, Bridge assigns an issuer address and requires an ERC-20 approval. Bridge states that a non-custodial wallet can be linked to only one card at a time, while commercial Bridge wallets can be shared by multiple cards or cardholders under the same Stripe Account connected to a single business Customer.

Commercial programs create a business-typed Bridge Customer and receive a stripe_account_id to act as a Connect subaccount. Operators create authorized cardholders and cards under that subaccount by sending requests with the Stripe-Account header and by accepting required Lead Bank terms for cardholders. Monthly card statements must be produced via the Bridge API; Bridge supports PDF generation and custom templates. KYC and cards endorsement management remain in the Bridge Dashboard. Card lifecycle, authorizations and disputes are managed in the Stripe Dashboard.

Testing should cover authorization flows, webhooks and statements. Bridge validates onchain approvals, sufficient allowance and balances at authorization and then performs the onchain pull just-in-time; failed approval, insufficient allowance or insufficient balance will reject a transaction in addition to normal Issuing checks. Stripe highlights issuing_authorization.created, issuing_authorization.updated and issuing_transaction.created as key webhooks. Operators that require low-latency authorization decisions must coordinate with their Stripe account manager or Bridge, since issuing_authorization.request is not automatically granted for real-time decisions.

The private preview targets crypto-native platforms, wallet providers and fintechs that already run Bridge or Privy or can bring their own wallets and want Visa-rail spend funded just-in-time from stablecoin balances. The option is not suitable for organizations that want Stripe to custody USDC via Stripe financial accounts, for teams that cannot secure private-preview access through Stripe sales, for programs that cannot create a card within 24 hours of endorsement, or for programs that cannot maintain onchain approvals for non-custodial spend.

Operators planning a launch should map the full sequence-App Install Link, Bridge Customer creation and cards endorsement, stripe_cardholder_id or stripe_account_id, POST /v1/issuing/cards with crypto_wallet, onchain approval when type=standard, and webhook handling-before handling live customer volume. Private-preview access, the 24-hour endorsement rule and onchain approval health are practical gating items for any program relying on just-in-time USDC pulls.