Sending payouts from OUSD

Send payouts when your application needs to deliver funds to a person or business. For example, a marketplace could pay a seller from an OUSD-funded balance while letting the seller receive an approved stablecoin or money in a bank account.

Start with the recipient’s required asset and destination. Funding a payout with OUSD does not mean the recipient receives OUSD.

Understand the two sides

A payout has a source debit and a destination credit, potentially with conversion between them. A network and token identifier are part of a wallet destination; a ticker alone is insufficient.

A submitted transaction is also different from settlement. Decide which provider state or chain confirmation establishes recipient delivery for your product.

Define the requirements

• The recipient, their eligibility, and their bank account or wallet destination
• The source asset, recipient asset, supported route, fees, limits and expected timing
• Who approves the payment and how funds are reserved before submission
• How failures, returns, delayed delivery and uncertain outcomes are handled

Build the payout workflow

1. Onboard and verify the recipient. Keep your user ID, the provider’s recipient ID and the payment destination distinct.
2. Validate the route. Confirm the exact source and destination assets, country or network, and account permissions. Check wallet identifiers against Networks and contracts.
3. Present the payment for approval. Show the source debit, recipient amount and asset, fees and destination. Own-account transfers and payments to third parties may have different requirements.
4. Reserve funds and submit once. Persist a payment record and stable idempotency key. A timeout leaves the outcome unknown; first retrieve the original payment instead of creating another.
5. Track delivery and reconcile. Match the provider reference, fees and recipient credit. Release a reservation only after the outcome is established.

Example: paying a marketplace seller

An illustrative payment record could contain an OUSD source balance and a USDC recipient amount. Show both currencies in the payment history. Keep the state as submitted until the chosen route supplies delivery evidence; route a failed or returned payment to review.

Use payment events, retries and reconciliation for reliable processing. Creating OUSD wallets covers provisioning if the recipient needs a new wallet.

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.

Available providers

• Bridge: Bridge Transfers can deliver OUSD or another supported destination asset; check each route direction.
• Mastercard: Open Standard lists Mastercard for sending funds, but does not specify an OUSD payout API or network matrix.
• Privy: Privy documents custodial OUSD transfers, including an OUSD-on-Tempo example. This is a wallet-to-wallet transfer, not a bank-payout API.
• Stripe: What reaches the recipient? Treasury can fund payouts from OUSD, but the documented external assets are supported fiat, USDC or USDC.e. Native OUSD recipient delivery is not established by this product guide.
• Visa: VSP supports OUSD transfers; the wallet arrangement determines where they are executed.