5 things to know before launching a stablecoin card program
A practical guide to launching stablecoin-backed cards with Privy and Stripe
Debbie Soon
|Aug 12, 2026
Cards are quickly becoming a core part of the stablecoin stack. Crypto payment cards processed $759 million in spend in July, up roughly 2.5x from a year ago and from less than $1 million per month in late 2023, according to a16z crypto and Paymentscan. Nearly 9 million purchases were made with crypto cards in July alone.
We're seeing that growth firsthand at Privy. Ramp and Slash are building corporate card programs with programmable controls for business spending, while Squads and Vaultleap pair stablecoin-powered accounts with Visa cards that let consumers spend their balances anywhere cards are accepted.
For users, the experience is remarkably simple: hold stablecoins, then tap or swipe a card to spend. For merchants, since stablecoins are converted into local currency for settlement behind the scenes, it looks like any other card transaction.
Delivering that experience, however, requires coordinating a much more complex financial stack across wallets, funding, card issuing, compliance, fraud, authorization and settlement, as well as operational functions like card fulfillment and user support.
Having worked with teams building these products, here are five things worth knowing before you launch.
1. Cards are a program, not an API
It’s easy to think about cards as another integration: connect to an issuing API, provision a card, and start spending.
In practice, launching a card program requires coordination across an issuing bank or BIN sponsor, a card network like Visa or Mastercard, compliance and KYC providers, wallet infrastructure, authorization and settlement, and your own application.
Each of those parties comes with its own requirements. Depending on your program, you may need to define where and to whom cards can be issued, establish KYC and transaction monitoring processes, set spending and transaction limits, design compliant cardholder onboarding and disclosures, and have elements of your program and user experience reviewed by banking and network partners.
For stablecoin cards, there’s an additional set of considerations: how crypto enters the system, where it’s held, how onchain transactions are monitored and Travel Rule requirements are handled, and how funds move between onchain and traditional card rails. Even something as seemingly straightforward as converting stablecoins into fiat requires decisions around timing, liquidity, pricing, and settlement, all while ensuring the card transaction can be authorized quickly and reliably.
The work doesn’t stop at launch. Operating a card program also means standing up customer support for card-specific issues, from lost or stolen cards to declined transactions, chargebacks, and disputes. Support teams need the right tooling, processes, and training to handle these cases, often within specific network and regulatory timelines.
Before choosing your infrastructure, you need to define the program you want to operate: who you’ll serve, where you’ll launch, how funds will move, what operational responsibilities you’re prepared to take on, and which you’ll leave to your partners.
2. Choose how you’ll fund card spend
One of the most important architecture decisions is how a user’s onchain balance becomes available for card spend.
In a prefunded model, users move stablecoins into a dedicated balance or smart contract before they can spend. This can simplify the funding flow, but requires users to anticipate their spending needs and can leave capital sitting idle.
With just-in-time funding, funds remain in a user's wallet until a card transaction is authorized, then are pulled on demand to cover the purchase. With Privy, that can extend to assets held in DeFi vaults, allowing users to keep funds productive onchain until they're needed for card spend.
Credit introduces another set of tradeoffs. In the US, for example, secured credit programs can require collateral to remain locked for at least 14 days, creating a very different experience from the instant liquidity users expect onchain. How collateral is held and when it can be released therefore become important considerations in designing the card experience.
The right funding model ultimately comes down to liquidity, regulatory requirements, and user experience: where funds live, how much needs to be immediately available for spend, whether capital needs to be locked, and whether users need to manage a separate card balance.
3. Your compliance model shapes your product
Cards are a highly regulated financial product, and your compliance model will influence much of how your program operates. Depending on your issuing setup, you’ll need to establish responsibilities for KYC and ongoing monitoring, determine which users and geographies you can support, and define controls such as transaction and spending limits.
For US consumer programs, requirements under Regulation E can also govern how certain errors and unauthorized transactions are investigated and resolved, including specific timelines and consumer protections. These obligations can extend beyond the compliance team into the product and operations you need to build around the card.
These decisions directly shape the card experience. They can affect who is eligible for a card, what information you collect during onboarding, where cards can be used, and what customers are able to do once they have one.
These requirements are also a major reason card programs can take months to launch, or face unexpected restrictions after they’re live. Issuing banks and card networks may need to review and approve not just the underlying business, but elements of the operating model and cardholder experience, and programs that fall outside those requirements can be restricted or shut down.
Companies should align with their issuing and compliance partners early on the markets, users, and use cases they want to support, then design the card experience around those requirements rather than trying to retrofit them later.
4. Treat authorization as a product surface
Stablecoins don’t just give you a new way to fund a card. They also give you more flexibility in deciding how that money can be spent.
When card authorization is connected to a programmable wallet or account, controls can be enforced at multiple levels. Card-level policies can govern spending limits and merchant restrictions, while onchain policies enable more granular rules around how funds move, who can access them, and what approvals are required.
This is particularly powerful for business and agentic use cases. An organization might give employees different spending permissions based on their roles, while an AI agent could be authorized to spend only within a defined budget or for specific purposes. Privy’s programmable policy engine lets companies encode and enforce these kinds of rules at the wallet level.
Start by defining the conditions under which a transaction should be approved: who can spend, how much, where, and with what approvals. Then make sure your authorization architecture can enforce those rules as the product scales.
5. Build for the financial product, not just the card
Cards rarely exist on their own. The same customers who spend from an account will likely also need to fund it, withdraw from it, transfer money, manage assets, or put idle balances to work.
These capabilities are easier to add when they share the same underlying account infrastructure. Rather than creating separate balances and integrations for each new capability, a programmable wallet can serve as the foundation across funding, payments, cards, and yield. Funds can move between these experiences as needed, including from yield-bearing positions into spend, without requiring users to manage each one separately.
The card you launch today may ultimately become one part of a much broader financial product. Designing the underlying account around what you want to offer next, not just what you need to launch now, gives you much more room to expand over time.
Launching a card program with Privy
Privy’s low-level APIs give developers the flexibility to connect their wallets and accounts to the card infrastructure that works for their business, with several programs live today. But as the examples above show, launching a card program means coordinating much more than an issuing API.
We’re working to bring more of that stack together. Soon, we’ll offer a more integrated path to launching card programs directly through Privy, bringing Stripe Issuing together with the wallet and funding infrastructure needed to power the end-to-end experience. This builds on Stripe’s years of experience in card issuing, with infrastructure that has already supported more than 400 million cards.
Alongside issuing, Privy can provide the rest of the infrastructure needed to build a complete card product, including global KYC, funding and money movement, just-in-time funding from wallets and DeFi positions, and programmable policies for how funds can be spent.
If you’re thinking about launching a stablecoin card program, talk to us. We can help you design the right architecture across funding, authorization, policies, and issuing.
