> ## Content Index > Fetch the complete content index at: https://stablecoininsider.org/llms.txt > Use this file to discover other available public pages before exploring further. # How to Send a Modern Treasury Stablecoin Payout (2026) - URL: https://stablecoininsider.org/how-to-send-a-modern-treasury-stablecoin-payout/ - Published: 2026-10-02T06:01:00.000Z - Updated: 2026-10-02T06:12:50.000Z - Description: Send USDC and other supported stables with Modern Treasury: onboard Legal Entities, open stablecoin Internal Accounts, create type:stablecoin Payment Orders to external wallets, and reconcile with webhooks. - Author: Alexandra - Tags: Fintech, Stablecoins 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. 📌 Stablecoin Insider's framing: use this guide when the job is platform-initiated USDC (or USDG/PYUSD/USDT) delivery through Modern Treasury Payment Orders. Use How to Send a Circle Stablecoin Payout when Circle is the payout control plane. Use How to Send a zerohash Stablecoin Payout when the stack is zerohash Modular or Single API Call. Use Column N.A. rails when the bank partner path is Column, not Modern Treasury. Facts below come from Modern Treasury's [Originating a stablecoin payout](https://docs.moderntreasury.com/payments/docs/send-a-stablecoin-payout) guide, [Stablecoins overview](https://docs.moderntreasury.com/payments/docs/stablecoins), [Stablecoin On-ramp](https://docs.moderntreasury.com/payments/docs/stablecoin-on-ramp), [Stablecoin Off-ramp](https://docs.moderntreasury.com/payments/docs/stablecoin-off-ramp), [Provisioning Accounts](https://docs.moderntreasury.com/payments/docs/provisioning-accounts), and [Payment Order webhooks](https://docs.moderntreasury.com/platform/reference/payment-orders). 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. ⚠️ Named downside: this is not a self-serve retail wallet. You need an approved Modern Treasury organization, verified Legal Entities, provisioned USD and stablecoin Internal Accounts, screened wallet Counterparties, and webhook listeners before production payouts. Sandbox Legal Entities activate automatically; production may include manual review SLAs set with your account team. ## 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](https://stablecoininsider.org/how-to-mint-and-redeem-usdc-with-circle-mint/) or [How to Mint and Redeem USDG with Paxos](https://stablecoininsider.org/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](https://stablecoininsider.org/how-to-open-a-bridge-virtual-account-for-usdc/)). For Circle or zerohash payout product shapes, keep [How to Send a Circle Stablecoin Payout](https://stablecoininsider.org/how-to-send-a-circle-stablecoin-payout/) and [How to Send a zerohash Stablecoin Payout](https://stablecoininsider.org/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](https://stablecoininsider.org/how-to-enable-column-na-stablecoin-rails-for-usdc-and-usdt/). ## What a Modern Treasury stablecoin payout is Per the [Originating a stablecoin payout](https://docs.moderntreasury.com/payments/docs/send-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](https://docs.moderntreasury.com/payments/docs/stablecoins) 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](https://docs.moderntreasury.com/payments/docs/stablecoins) page. As documented there: | Stablecoin | Ethereum | Solana | Base | Arbitrum One | Tron | Polygon PoS | Stellar | | ---------- | -------- | ------ | ---- | ------------ | ----------- | ----------- | ------- | | USDG | Yes | Yes | \- | Yes | \- | \- | \- | | USDC | Yes | Yes | Yes | Yes | \- | Yes | \- | | PYUSD | Yes | Yes | \- | Yes | \- | \- | Yes | | USDT | Yes | \- | \- | \- | Coming Soon | \- | \- | 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](https://docs.moderntreasury.com/payments/docs/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](https://docs.moderntreasury.com/payments/docs/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/ 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](https://docs.moderntreasury.com/payments/docs/send-a-stablecoin-payout). ## 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](https://docs.moderntreasury.com/payments/docs/stablecoin-on-ramp) 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](https://docs.moderntreasury.com/payments/docs/send-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": "", "receiving_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](https://docs.moderntreasury.com/platform/reference/payment-orders). 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 | Job | Modern Treasury shape | Operator spine | | ------------------ | ------------------------------------------- | -------------------------------------------------------------- | | Payout (this post) | Payment Order type "stablecoin" | Funded stablecoin IA → wallet Counterparty → completed webhook | | On-ramp | Fund USD → book to stable → stablecoin send | Legal Entity → USD + stable IAs → three Payment Orders | | Off-ramp | Receive stable → book to USD → ACH/wire/RTP | Inbound IPD → book → fiat Payment Order | The [Stablecoin Off-ramp](https://docs.moderntreasury.com/payments/docs/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 | Question | Modern Treasury | Circle payout | zerohash payout | | --------------------------- | ------------------------------------- | -------------------- | ---------------------------------- | | Control plane | MT Payment Orders + Internal Accounts | Circle payout APIs | zerohash Modular / POST /payouts | | Fiat + stable in one ledger | Yes (same primitives) | Circle-centric | Platform float + crypto withdrawal | | SCI operator guide | This post | Circle payout how-to | zerohash payout how-to | 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. 💡 Stablecoin Insider's take: a Modern Treasury stablecoin payout is the right shape when payment ops already lives in Modern Treasury and the job is compliant type:stablecoin credits to screened wallets. The operator spine is Legal Entity activation, stablecoin Internal Account provisioning, Counterparty account\_number\_type routing, integer smallest-unit amounts, and payment\_order.completed as the settlement signal. Still treat irreversible on-chain settlement and network-type mismatches as launch blockers before you put Get paid in USDC behind a production toggle. --- 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. [Read Modern Treasury stablecoin payout docs](https://docs.moderntreasury.com/payments/docs/send-a-stablecoin-payout) Need the Circle parallel for USDC payouts? Use the Circle how-to next. [Send a Circle Stablecoin Payout ](https://stablecoininsider.org/how-to-send-a-circle-stablecoin-payout/) [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.![](https://stablecoininsider.org/favicon.ico)Stablecoin Insider](https://stablecoininsider.org/how-to-send-a-zerohash-stablecoin-payout/) [How to Send a Circle Stablecoin Payout](https://stablecoininsider.org/how-to-send-a-circle-stablecoin-payout/): Sibling guide when Circle is the payout provider. ## FAQ #### What is a Modern Treasury stablecoin payout? A Payment Order with type stablecoin that sends supported stables from a stablecoin Internal Account to an external wallet Counterparty, using the same Legal Entity and webhook primitives as fiat rails. #### Which stablecoins can I send? Modern Treasury's Stablecoins docs list USDC, USDG, PYUSD, and USDT on specific networks (Ethereum, Solana, Base, Arbitrum One, Polygon PoS, Stellar, with USDT on Tron coming soon). Confirm your org enablement before promising an asset. #### How are amounts encoded? As integer smallest units. USDC uses 6 decimals, so 10000000 equals 10.00 USDC per the payout guide. #### How is the blockchain network selected? By the destination wallet's account\_number\_type on the Counterparty External Account (and by requested\_account\_number\_types when provisioning Internal Accounts). #### Can a settled stablecoin payout be returned? No. Modern Treasury's payout docs state on-chain stablecoin transfers cannot be returned once settled. #### What webhook marks success? payment\_order.completed indicates the transfer settled on chain. payment\_order.processing is an optional in-flight signal. #### Do I need a separate crypto vendor? For this product shape, custody and chain infra are abstracted inside Modern Treasury's stablecoin Internal Accounts. You still need MT enablement, Legal Entity KYC/KYB, and screened Counterparties. #### How is this different from Circle or zerohash payouts? Different control planes. Use this guide for Modern Treasury Payment Orders. Use SCI's Circle or zerohash payout how-tos when those providers own the payout API. --- 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.