Stablecoin payout feature copy: launch it without crypto jargon

Stablecoin payout feature copy is the text a fintech writes on its own screens for a payout that runs on a stablecoin, from field labels to status messages. It describes what the sender and the recipient get, in local currency, by rail and with a time, and mentions the stablecoin once, only where a user's question needs it.

The screens belong to your app. The rail underneath is a stablecoin API, covered in what a stablecoin API is, but nobody needs the word to finish a payment.

What should payout copy say instead of crypto jargon?

It should name the outcome the user can check: the currency, the account, the rail and the time. Every crypto term on a payout screen has a plain version that is also more specific.

Jargon on a payout screen, and the line that replaces it

Each line on the right carries something the user can verify. The wider frame is in what stablecoin banking is.

On Lumx, a destination holds the recipient's account details and the relationship to your customer (supplier, employee, relative or self), so the form fields in the right column map to real inputs. For Brazil, the recipient is registered with a Pix (Brazil's instant payment system, run by the Central Bank) key, typed as a CPF (the Brazilian individual taxpayer ID) or another key type. Mexican payouts go to a CLABE (the 18-digit Mexican bank account number) over SPEI (Mexico's interbank transfer system, run by Banxico).

Words for the funds and the account

Call the money by what the user can do with it. A sender sees "Available to send", not "USDC balance", and a recipient sees the amount in their own currency.

For a USD account, write the way a bank statement does: "Account number", "Routing number", "Pay in by ACH or wire". A named virtual account (a local account number issued in the customer's own name, explained in what a named virtual account is) supports that wording honestly.

Two phrases are off limits. Do not call the account "a bank account at" your payments provider, or write "settles through a bank". The provider is custodial infrastructure, not a bank.

On Lumx, a virtual account is a fiat account issued by a banking partner in the customer's name, one currency per account, and a USD account supports ACH, Fedwire and SWIFT on the same account. See named virtual accounts for the product.

How fast can the copy say money arrives?

As fast as the slowest step on that rail, per rail, never one claim for the whole product. A single "arrives in minutes" line is true for Pix and wrong for ACH.

Speed lines per rail, from the Lumx docs read on November 1, 2026 (COP from Lumx's confirmed rail facts and the central bank limit)

Say "usually": the docs call their timelines processing targets. And when a cut-off exists, tie the time to the sender's clock: a USD payment started at 4:00 PM in São Paulo misses the 3:00 PM Eastern cut-off, so the screen should compute the date.

The Colombian ceiling is the Banco de la República limit of 1,000 UVB per Bre-B (Colombia's instant payment system) payment, COP 12,110,000 in 2026. A larger invoice goes by ACH Colombia, with no time claim until you have your own data.

On Lumx, SEPA routing between the two SEPA schemes is automatic and you always send the rail as SEPA, so the line above is the only place your user meets the difference. The cut-off table is in the docs, and global payments shows the rails by currency.

Rate and fee lines before the user confirms

The confirm screen needs three numbers in plain view: the rate, the fee, and what the recipient gets. Marketing must never show a better number than this screen.

Rate and fee strings, with the field behind each. The fee and lock amounts are illustrative, not Lumx prices

Show your own fee as its own line, because a fee buried in the rate reads as a wider spread. The stack is in how stablecoin payout pricing works. When the lock runs out, replace the button instead of silently refreshing: "Your rate expired. Get a new rate".

On Lumx, a floating rate is a reference with no lock, and a locked rate returns an exchange rate id plus an expiry for 30 seconds, 1 minute or 5 minutes, with a fee on the longer two. The partner fee is yours, in basis points, a flat amount or both. Lumx does not deduct a fee from the amount that reaches the recipient on a Pix, SPEI or Bre-B payout, so "Recipient gets" can be literal, although the recipient's own bank may charge them.

Status messages for each stage of a payout

A status message says what is happening to the money in the sender's terms and stops before it promises a result it cannot see. Map each status to one line.

Off-ramp statuses and the line for each

"Sent" is the honest final word: the docs treat an off-ramp as complete once funds leave the banking partner, so "Received" can be false when you print it.

On Lumx, each of these statuses fires a webhook such as offramp.trading or offramp.success, so your app updates the line without polling. The success receipt carries the amounts, the exchange rate and the fees, so the receipt screen reads from it, not from the request.

Error and hold messages

An error line tells the user what to do next, and the API usually says which case you are in. Write one string per error code, and the generic one last.

Error codes on transaction creation, from the Lumx docs, and the line for each

Name CPF and CNPJ (the Brazilian company taxpayer ID) in that string, because "tax ID" alone sends users to the wrong field. For a hold, avoid the word reject: a held payment is waiting for an answer, and "Under review" plus the one thing needed is accurate and calmer. The usual causes behind a rejected payout are in why stablecoin payouts get rejected.

I recommend writing the failed and under-review strings before the success screen. The success copy writes itself, while the other two decide whether a sender trusts the next payment. A failed state that says only "something went wrong" moves the work to your support inbox.

On Lumx, an RFI (request for information, a compliance question that pauses something until it is answered) exists at three levels. A customer RFI fires customer.rfi and an account RFI fires account.rfi, and the statusReason lists the documents at issue, so those lines can name the document. A transaction hold is different: compliance contacts you by email or Slack, usually asking for the relationship between sender and receiver and the purpose of the payment, and today there is no webhook or API event for it. An API flow for transaction RFIs is planned for between the end of 2026 and the first quarter of 2027. So the line for a held payment asks for context, not a file: "Under review. We may need to know who Marina is to you and what this payment is for". And because the docs warn that a transaction with no reply within 24 hours may be refunded to the sender, say so on the screen: "Reply within 24 hours or the payment may be returned to you".

Where the stablecoin gets one sentence

Mention it once, in a how-it-works section or the FAQ. Two versions work.

> Short: "Your payment travels as a dollar stablecoin and arrives as local currency in the recipient's bank account."

> Why: "Pix, SPEI and Faster Payments run every day of the year, so a payment on those rails can land on a weekend."

Check the line against your own flow: "you never hold it" is false if any user can keep a stablecoin balance in your app. Speed and cost claims need data from your own payouts. For coverage, point to the coverage page instead of printing a country count.

Whether special promotion rules apply to your copy depends on what users can do. An app where users send dollars and recipients receive local currency reads as a payment product. An app where users buy, hold or sell stablecoins is a different product, and the rules on how you may advertise it depend on the market. This post does not cite a rule: send counsel the final strings per market and a diagram of who holds funds at each step.

Write each string in the reader's language and keep the rail's own term: a Brazilian recipient sees "Chave Pix", a Mexican one "CLABE". To test the copy, ask a few users what each stage and error line means and what they would do next.

On Lumx, every customer gets a custodial wallet that holds stablecoin between on-ramps and off-ramps, but your app decides whether the user ever sees a stablecoin amount. Hiding it is a product choice you make, and the compliance review above is yours.

When plain copy is the wrong choice

Plain copy is wrong when the user moves the stablecoin themselves: a treasury team withdrawing USDC to an external address needs the network name and the token, because the wrong network loses the funds. It is also wrong when it hides a cost or a required disclosure.

What these strings look like on Lumx

Lumx does not ship your screens: your app writes every string above.

Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.

Take a Brazilian payout from your app. The sender's customer is approved after KYB (know your business, the verification of a company and its owners), the recipient is a destination with a Pix key and a relationship such as supplier, the quote screen reads a locked rate, and the status line follows the offramp webhooks.

The build side is in how to integrate a stablecoin API.

Methodology and sources

We read these Lumx docs on November 1, 2026 and checked them again on November 2: Transactions, Cut-off times, Exchange rates, Partner fees, Accounts, Destinations, Wallets, Webhooks, Errors, RFI and Coverage. The Bre-B ceiling is from the Banco de la República Circular Reglamentaria Externa DSP-465, Asunto 18, numeral 3.2 (sheet of March 31, 2026). Sample figures and names in the strings are illustrations.

Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Dmitrijs Safrans on Unsplash.