Creating OUSD wallets

Create wallets when users need an address to receive funds or an account that can authorize onchain transactions. For example, a marketplace could provision a wallet for each seller, associate incoming OUSD with that seller, and later let them request withdrawals.

Wallet creation establishes an identity and control arrangement. Funding the wallet and enabling payment services are separate steps.

Choose who controls the wallet

A wallet may be controlled by the user, by your application, or through a custodian. Define who can sign or approve transactions, how access is recovered, and which responsibilities remain with your application.

A wallet address, an internal user ID, a provider customer ID and the OUSD token identifier represent different things. Do not use them interchangeably.

Define the requirements

• The owner or beneficiary and any required identity checks
• The custody model, signing authority, recovery process and spending policies
• The exact chain, accepted OUSD token and provider-supported deposit route
• How repeated or interrupted provisioning requests avoid duplicate wallets

Build the provisioning workflow

1. Enable the chosen wallet product. Complete account setup and any beneficiary onboarding before making creation requests.
2. Bind the beneficiary. Map the provider’s customer reference to your authenticated application user on the server.
3. Select the chain and authority. Configure the owner and supported authorization policies before funding.
4. Create the wallet. Follow the selected product’s documented request. Save the wallet ID, returned address, chain, owner and customer reference.
5. Verify access boundaries. Test that one user cannot read or spend another user’s funds, and check the behavior of interrupted requests.
6. Add funding as a separate flow. Use the service’s accepted route and the official identifiers in Networks and contracts. Never send money to the token contract itself.

Example: one seller, several identities

An illustrative seller record links your internal seller ID to the custodian’s customer ID and the wallet service’s wallet ID. The receiving address belongs to that wallet; the OUSD identifier belongs to the asset on its network. Keep transfer authority alongside the wallet record.

Use Managing OUSD custody for operational controls and events and reconciliation when adding transfers. Generic chain compatibility alone does not verify a provider’s OUSD deposit, custody or redemption service.

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 provides a direct custodial-wallet API with explicit OUSD support on four networks.
• Coinbase: Open Standard lists Coinbase as a wallet integration path but does not identify an OUSD wallet API.
• Mastercard: Mastercard is listed as an OUSD wallet integration path; product-level provisioning details still need confirmation.
• Privy: Privy offers embedded wallets and a separate Bridge-backed custodial route with documented OUSD transfers.
• Visa: VSP offers Wallet-as-a-Service or a connection to your existing wallet provider.