How to send a stablecoin payout with Modern Treasury

Modern Treasury supports on-chain stablecoin payouts by creating a Payment Order with type “stablecoin.” Operators originate a payout with a POST /payment_orders call using type “stablecoin”, direction “credit”, currency (for example USDC), an originating stablecoin Internal Account ID and a receiving external account ID. Amounts use the currency’s smallest integer units; USDC uses six decimals, so 100 USDC is 100000000 units.

Network routing depends on the Counterparty external account’s account_number_type. For EVM chains use ethereum_address; for Solana use solana_address. The receiving_account nested in the Payment Order response includes account_details and the account_number_type used for routing.

Prerequisites for production use include an approved Modern Treasury organization and API credentials, an activated Legal Entity for each entity that will hold funds, at least one active stablecoin Internal Account provisioned for the desired network, screened Counterparty wallet records with matching account_number_types, and a webhook listener subscribed to Payment Order events. Sandbox Legal Entities activate automatically; production activations can require manual review and SLAs agreed with Modern Treasury.

Typical build flow begins with activating Legal Entities, creating USD and stablecoin Internal Accounts, registering counterparties with destination wallet addresses and matching account_number_types, funding or converting USD to stablecoins if needed, then creating the stablecoin Payment Order and tracking lifecycle webhooks. If funds start as USD, the documented pattern is to fund a USD Internal Account, perform a book transfer to the stablecoin Internal Account with a Payment Order of type “book,” wait for that payment_order.completed event, then send the stablecoin on-chain. Maintain the same smallest-unit convention across book transfers and stablecoin sends to avoid scale errors.

Modern Treasury emits lifecycle webhooks such as payment_order.processing for in-flight signals and payment_order.completed when the on-chain transfer has settled. The documentation states that on-chain stablecoin transfers settled through this rail cannot be returned once payment_order.completed fires. Operators receive a payment_order id in the response and should persist that id for reconciliation and surface on-chain transaction identifiers from completed webhook payloads into ledgers when present.

Supported stablecoins listed in the platform documentation include USDC, USDG, PYUSD and USDT on specific networks such as Ethereum, Solana, Base, Arbitrum One, Polygon PoS and Stellar. Tron support for USDT is noted as coming soon. The control plane does not provide USDT-to-USDC conversions.

The workflow is designed for payments teams, marketplaces, neobanks and payment service providers that already use Modern Treasury for fiat Payment Orders and want the same control plane for wallet payouts. It is not a retail wallet product: issuers that only need minting and redemption, operators that require pull/debit collection in stablecoin, or organizations that cannot complete Legal Entity KYB/KYC and wallet screening should use different product shapes or providers. Operators must confirm enablement, supported assets and network routing with Modern Treasury before offering specific payout options in production.