Issuing OUSD-funded cards
Issue cards when customers need to spend a balance at card-accepting merchants. For example, a wallet app could add a customer card whose purchases draw on an approved OUSD funding balance.
A customer card program and cards for your own company’s expenses can be different products, with separate onboarding and eligibility.
Understand the funding model
Section titled “Understand the funding model”The card’s billing currency, the wallet’s funding token and the merchant’s settlement currency are distinct. A card billed in USD is not proof that its funding source can be OUSD.
Card authorization reserves or debits funds according to the program’s rules; capture, reversal and refund are later events. Keep that lifecycle separate from onchain settlement.
Define the requirements
Section titled “Define the requirements”- The approved program type, business countries and cardholder eligibility
- Explicit OUSD support, funding network, wallet model and current card API
- Cardholder identity checks, spending controls, fees and limits
- Funding timing, refunds, disputes and behavior when the balance or allowance is insufficient
Build the card workflow
Section titled “Build the card workflow”- Obtain program access. Confirm the actual funding token and supported environment before building a customer-facing card flow.
- Onboard the cardholder. Complete the program’s required checks and store the returned customer and cardholder references separately.
- Connect the funding balance. Reuse Creating OUSD wallets and Managing OUSD custody to define who controls it. Confirm any onchain spending permission, including its spender and amount limit.
- Create and manage cards with the approved integration. Use the current product documentation and account-specific parameters. A generic stablecoin example is not an OUSD recipe.
- Process the full lifecycle. Reconcile authorizations, captures, reversals and refunds against the funding ledger without counting one purchase twice.
Example: an authorization that changes
Section titled “Example: an authorization that changes”In an illustrative wallet app, a merchant first authorizes a purchase, later captures the final amount, and may refund it. Retain separate event references and reconcile each balance effect according to the program’s funding timing.
Test insufficient funds, insufficient allowance and interrupted requests alongside the happy path. The shared events and reconciliation guide covers retry handling. Provider-specific OUSD card-funding details still need confirmation in the paths below.
References and review
Section titled “References and review”The provider directory and activity sections below link to the official product documentation behind each route. These general workflows are application-design guidance; provider-specific steps, eligibility and asset limits are in those profiles.
Documentation reviewed October 11, 2026. Modified October 12, 2026. No live integration independently tested.