Stripe makes OUSD its default stablecoin: supported products, networks and eligibility

What changed: a new default, not a mandatory migration

Stripe’s official September 30 announcement makes OUSD the default stablecoin and Tempo the default network. It also says other supported currencies and chains remain available, and existing stablecoin balances do not need to be converted. A default setting and a migration of existing assets are separate matters. This does not justify requiring a team to convert all balances to OUSD.

The announcement date in this article comes from the official page and is precise only to the day. No effective times were obtained for individual products, countries or accounts. October 2 is the date of this verification, not OUSD’s original release date.

Which products are listed as supported, and which are still forthcoming

The announced support includes receiving, holding, sending and spending through Treasury; Issuing card programs; Global Payouts; fiat conversion through Crypto Onramp; and accepting OUSD through Payments. Related Bridge and Privy support is also covered, with further product expansion still underway. Ramp’s stablecoin accounts are described as coming soon and cannot be treated as already available to open. See the product scope and future plans.

The official OUSD documentation requires availability to be checked by product, country, network and release status. “Stripe supports OUSD” therefore does not establish that a particular business can use it in every product. Requirements for payees, payers and platform accounts should also be checked separately.

Check networks separately at the asset and product levels

The official announcement lists four OUSD networks: Base, Ethereum, Solana and Tempo, with Tempo as the default. This describes the asset’s network coverage. How a specific Stripe product receives, sends or settles funds still depends on its current guide. The list does not imply that any cross-chain path is automatically available. See the official network explanation.

Record the product, account country, asset, network and receiving-address type in the existing flow, then compare each with the product documentation. Before transferring assets, confirm that both sides support the same network and currency, and retain the original configuration and verification results. If a page mentions OUSD but its currency table has not been updated, confirm the specific path with the official provider rather than substituting another currency’s requirements.

Fees and rewards: a free operation does not make the entire flow free

The announcement says OUSD minting and burning are fee-free and transaction fees are low and predictable, but it does not give complete figures for every product path. Check conversion, network, payment, card-program and service fees against the actual product and terms you use. Free mint/burn operations do not mean all transactions are free. See the announcement’s fee scope.

Open Standard rewards relate to OUSD activity and balances. The official documentation also requires checking eligibility, availability, terms and risk disclosures. This article does not invent reward rates, fixed returns or a guarantee that any business will receive rewards. Start with the official OUSD documentation and follow the relevant guidance to confirm your participation requirements.

Five checks before business implementation

First, identify whether the goal is customer payments, business holdings, outbound payments, card issuing or fiat conversion, and select the corresponding product. Do not use one announcement as a substitute for every product’s integration requirements. Second, check the business entity, account country, product release status and official eligibility requirements. Third, confirm both parties’ currency, network, settlement asset and address format, and save the existing configuration.

Fourth, list the fees, limits, reward terms and failure-handling process for the specific path, supported by product documentation or written official confirmation. Fifth, use the product’s test environment to validate requests, status callbacks and reconciliation. Only after eligibility and the path are confirmed should actual use be evaluated through the business’s existing approval process. This article did not perform those account tests and does not promise that a test environment covers every risk of a real-money flow.

If a product entry point is missing or access is denied, check product and account eligibility first. Investigate DNS, TLS and connection timeouts separately using the connection failure checklist. Changing networks cannot confer eligibility for a financial product.

What remains unconfirmed, and when to stop

This verification did not confirm activation for any specific business, every country/network combination for each product, complete fee figures or reward eligibility. It also did not test real-money transactions. If the announcement, product documentation, dashboard or terms conflict, record the discrepancy and verification time, pause asset transfers and ask Stripe for clarification instead of guessing the support scope.

Before implementing the flow again, use the current OUSD documentation to reach the target product’s guide. Adjust the relevant flow only after an official update explicitly changes eligibility, networks or status. Without evidence of mandatory migration, retain the existing configuration that has already been validated.