How to Send a Modern Treasury Stablecoin Payout (2026)

Treasury and payout teams already run ACH, wire, and RTP through one payment ops stack. The new ask is the same ledger, same counterparties, and a stablecoin rail that does not force a second crypto console.

The named object is a Modern Treasury stablecoin payout: a Payment Order with type: "stablecoin" that sends USDC (or another supported stable) from a stablecoin Internal Account to an external wallet Counterparty. Modern Treasury keeps Legal Entities, Internal Accounts, Counterparties, and webhooks as the same primitives used for fiat.

Facts below come from Modern Treasury's Originating a stablecoin payout guide, Stablecoins overview, Stablecoin On-ramp, Stablecoin Off-ramp, Provisioning Accounts, and Payment Order webhooks. Field names, status events, network matrices, and amount units are taken from those pages. No invented fees, country lists, or settlement SLAs beyond what those docs state.

Key Takeaways

• Send with POST /payment_orders using type stablecoin, direction credit, and a funded Internal Account.
• Amounts are integer smallest units (USDC has 6 decimals, so 10000000 equals 10.00 USDC).
• Network routing follows the Counterparty wallet account_number_type (for example ethereum_address).
• Track settlement on payment_order.completed; on-chain stables cannot be returned once settled.
• Supported stables include USDC, USDG, PYUSD, and USDT on the networks listed in MT docs.

Who this is for

Use this path if you are a payments, marketplace, neobank, treasury, or PSP team that already (or plans to) run fiat Payment Orders in Modern Treasury and wants the same control plane for stablecoin wallet payouts.

Skip it if you only need issuer primary mint (see How to Mint and Redeem USDC with Circle Mint or How to Mint and Redeem USDG with Paxos). Skip it if your on-ramp is a Bridge virtual account (see How to Open a Bridge Virtual Account for USDC). For Circle or zerohash payout product shapes, keep How to Send a Circle Stablecoin Payout and How to Send a zerohash Stablecoin Payout open as comparison sheets. For bank-native USDC/USDT rails via Column, see How to Enable Column N.A. Stablecoin Rails.

What a Modern Treasury stablecoin payout is

Per the Originating a stablecoin payout docs, you send stables from a stablecoin Internal Account to an external wallet by creating a Payment Order with type: "stablecoin". Example use cases listed there include funding a neobank or exchange wallet and sending stables to an international recipient.

The Stablecoins overview states that Modern Treasury abstracts custody, liquidity, and blockchain infrastructure so operators reuse the same primitives as ACH or wire: Legal Entities, Internal Accounts, Counterparties, and Payment Orders. Send is supported; send is not reversible; pull is not supported for the stablecoin rail in the capability table on that page.

Here's why that matters for operators: you do not invent a second payout product. You extend the same payment_order lifecycle, then listen for the same webhook family when the transfer settles on chain.

Supported stables and networks

Before you create an Internal Account or Counterparty, check the matrix on the Stablecoins page. As documented there:

USDT-to-USDC conversions are not supported per the same page. Confirm your organization's enablement with Modern Treasury before promising a specific asset or chain in product UX.

Prerequisites checklist

• Modern Treasury organization with API key (ORGANIZATION_ID:API_KEY basic auth).
• Approved Legal Entity for each end user that will hold funds (business or individual onboarding).
• At least one active stablecoin Internal Account with the desired currency and requested_account_number_types.
• A Counterparty whose External Account holds the destination wallet and matching account_number_type.
• Webhook endpoint subscribed to Payment Order (and preferably Legal Entity / Internal Account) events.

Recommended build order from the Stablecoin On-ramp guide: onboard Legal Entities → open USD and stablecoin Internal Accounts → register Counterparties → fund/convert/send → subscribe to lifecycle webhooks.

Step 1: Onboard Legal Entities

Every entity that holds funds needs a verified Legal Entity. The on-ramp docs show POST /api/legal_entities with legal_entity_type business or individual, addresses, identifications (for example us_ein), and documents such as proof_of_address. Wait for the activated webhook before opening accounts. Sandbox activates automatically; production may include manual review, so ask your account manager for expected SLAs.

Stablecoin Insider's take: treat Legal Entity activation as a hard gate. Creating Payment Orders against pending entities is the fastest way to burn an engineering day on 4xx responses that look like amount bugs.

Step 2: Provision USD and stablecoin Internal Accounts

After the Legal Entity is active, create Internal Accounts via POST /api/internal_accounts. The Provisioning Accounts and on-ramp guides describe a common pattern:

• Customer USD account: currency USD, legal_entity_id set to the customer's approved entity.
• Organization stablecoin account: currency USDC (or USDG/PYUSD/USDT), legal_entity_id set to your organization's entity, plus requested_account_number_types such as ["ethereum_address"].

The stablecoin Internal Account starts in pending_activation while the address is provisioned. After internal_account.activated, account_details includes the blockchain address for that network. Retrieve it with GET /api/internal_accounts/<id> before you share a deposit address or originate a payout.

Network selection is explicit: requested_account_number_types (or the Counterparty account_number_type) picks the chain. ethereum_address provisions an EVM-compatible address; use solana_address or the matching type for other networks, as called out in the payout guide.

Step 3: Register the wallet Counterparty

Create a Counterparty for the destination wallet with POST /api/counterparties. The on-ramp example registers account_details with account_number set to the wallet address and account_number_type set to the network type (for example ethereum_address).

That account_number_type is what routes the later type:stablecoin Payment Order. If you need Base, Solana, or Polygon PoS specifically, register the wallet with the matching type. Docs note that your Modern Treasury account team can help configure network routing during onboarding.

Wallet addresses are validated and screened before payment execution per the payout guide. Do not treat a 201 on Counterparty create as final screening clearance for every future amount; keep monitoring payment_order failures tied to address or compliance rejects.

Step 4: Fund and convert (when the source is USD)

If the Internal Account already holds the stablecoin balance, skip to Step 5. If you are originating from fiat, the on-ramp guide documents three stages:

• Fund USD: pull with an ACH debit Payment Order into the USD Internal Account, or accept a push (ACH credit, wire, RTP/FedNow) as an Incoming Payment Detail.
• Convert with a book transfer: POST /api/payment_orders with type "book", currency USDC, originating USD Internal Account, receiving stablecoin Internal Account.
• Wait for payment_order.completed on the book transfer before sending on chain.

Amounts on Payment Orders use integer smallest units. For USDC with 6 decimals, 10000000 equals 10.00 USDC. Keep that unit consistent across book transfers and stablecoin payouts so you do not off-by-six a production send.

Step 5: Create the type:stablecoin Payment Order

This is the named payout. From the Originating a stablecoin payout page:

curl --request POST \
  -u ORGANIZATION_ID:API_KEY \
  --url https://app.moderntreasury.com/api/payment_orders \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "stablecoin",
    "amount": 100000,
    "direction": "credit",
    "currency": "USDC",
    "originating_account_id": "<STABLECOIN_INTERNAL_ACCOUNT_ID>",
    "receiving_account_id": "<RECEIVING_EXTERNAL_ACCOUNT_ID>"
  }'

In the documented response shape, you get a payment_order id, status (example approved), effective_date, and nested receiving_account.account_details with the destination address and account_number_type. Persist the id for reconciliation.

Direction is credit for sends to an external wallet. Do not invent a debit pull on the stablecoin rail; the Stablecoins capability table marks Pull as No.

Step 6: Track webhooks and reconcile

Subscribe to Payment Order webhooks. The payout guide calls out:

• payment_order.completed: the transfer has settled on chain.
• payment_order.processing: optional signal that the transfer is in flight on the network.

On-chain stablecoin transfers cannot be returned once settled, per the same page. That is the sharp edge versus ACH returns. Design UX and support macros around irreversible settlement, and confirm destination network + address in a dry-run or staging send before production amounts.

For the broader Payment Order lifecycle (including fiat rails), see Modern Treasury's Payment Order webhooks reference. Surface transaction_ids / on-chain identifiers from the completed payload in your ledger when present.

Worked example: 100 USDC on Ethereum

Suppose a marketplace needs to pay a vendor 100 USDC on Ethereum from an already funded organization USDC Internal Account.

• Confirm Legal Entity active and USDC Internal Account status active with an ethereum_address in account_details.
• Create (or reuse) Counterparty Vendor Wallet with account_number = the vendor Ethereum hex address and account_number_type = ethereum_address.
• POST payment_orders with type stablecoin, amount 100000000 (100.000000 USDC), direction credit, currency USDC, originating_account_id = org USDC account, receiving_account_id = vendor external account.
• Store the returned payment_order id.
• Wait for payment_order.completed before marking the vendor invoice paid in your product ledger.
• If the source was USD float, insert the ACH/wire fund + type book conversion and wait for that completed event first.

That amount encoding (100000000 for 100 USDC) follows the 6-decimal rule in the docs. Your organization may also require dual control / approval policies inside Modern Treasury before status advances; confirm those with your account team.

On-ramp vs payout vs off-ramp

The Stablecoin Off-ramp guide mirrors the on-ramp in reverse: share the stablecoin Internal Account address, wait for an Incoming Payment Detail of type stablecoin, book transfer to USD, then originate ACH, wire, or RTP to a bank Counterparty. Keep it on your roadmap if beneficiaries later need fiat cash-out through the same stack.

Modern Treasury vs Circle vs zerohash: pick a lane

On the flip side, do not assume every Modern Treasury customer automatically has stablecoin rails enabled. Confirm product enrollment, supported currencies, and network routing with Modern Treasury before promising contractors a USDC option in production UX.

Who it is not for

Skip this stack when:

• You lack a Modern Treasury contract or stablecoin product enablement.
• You only need issuer mint/redeem, not wallet payouts from an Internal Account.
• You need pull (debit) collection in stablecoin; MT's stablecoin capability table marks Pull as No.
• Your compliance model cannot complete Legal Entity KYB/KYC and wallet screening.
• You need card spend funded by stables rather than wallet payouts.

Building stablecoin payouts on Modern Treasury? Map one sandbox Legal Entity, one active USDC Internal Account, one wallet Counterparty, and one payment_order.completed listener before any production float.

How to Send a zerohash Stablecoin Payout (2026)

Sibling operator guide when the payout control plane is zerohash Modular or Single API Call instead of Modern Treasury.

Stablecoin Insider

How to Send a Circle Stablecoin Payout: Sibling guide when Circle is the payout provider.

FAQ

This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy or sell any financial instrument, and readers should conduct their own independent research or consult a qualified professional.