Stablecoin Payout Statuses and How to Track Each One by Rail

Stablecoin payout statuses are the named stages a payout passes through between the request and the money reaching the recipient's bank account: the stablecoin moves, it is converted, the local-currency transfer is sent, and the payout ends as a success or a failure. Providers name these stages differently, so map their names before you build a status screen.

A payout is two payments chained together, and most status bugs come from treating it as one. The mechanics are in what a stablecoin off-ramp is. This post covers the labels: what each status means, which ones end the story, which event announces each, and what to look up on each rail when a recipient says the money has not arrived. Lumx facts were read from its documentation on November 1, 2026.

What are the statuses of a stablecoin payout?

Lumx names five off-ramp statuses, in this order: the first three are stages in motion, and the last two end the payout.

Off-ramp statuses in the Lumx API, from the transactions reference and the webhook catalog.

The documented order runs one way, so a stale event such as TRADING after SUCCESS should be ignored. Map the five statuses to sender labels once, in one place: TRANSFERRING_STABLECOIN and TRADING can both read "Sending", and only TRANSFERRING_FIAT earns "On its way to the bank".

On Lumx a payout starts when the off-ramp is accepted. Every change in the table is announced by a webhook and readable through the transactions endpoint, where the status sits in the state object and, on SUCCESS, a receipt adds the amounts and the blockchain transaction hash.

Which webhook event matches which status?

Lumx publishes one event per status for each of its three transaction types, named as the type, a dot and the status in lowercase. Payouts to a bank account are off-ramps, but on-ramp events matter because most payout balances are funded by one. A payout in stablecoin to an external wallet is a transfer, so it follows the three transfer events and has no bank leg and no rail identifier.

Webhook events by transaction type and the status each one announces.

The same word means different things in different rows. TRANSFERRING_FIAT on an on-ramp is money arriving from the payer, and on an off-ramp it is money leaving toward the recipient, so key your ledger on the transaction type and the status together. An on-ramp that is never paid ends as EXPIRED, which is final and is not a failure: a late deposit is refunded on the same rail, and the payer starts a new one. A transfer has three events because it has no conversion and no bank leg.

Each webhook is signed, retried if your endpoint does not answer with a 2xx, and carries a webhook-id header for dropping duplicates. The receiving side is covered in stablecoin API webhooks.

Why a confirmed blockchain transfer is not a finished payout

The blockchain sees only the first leg. When the stablecoin leaves the wallet, that leg is final once the chain confirms it, and a transaction hash exists. The second leg is a local-currency transfer over a bank rail, and it is the one the recipient cares about.

A "paid" screen at the hash is early. On Pix (Brazil's instant payment system, run by the Central Bank) and SPEI (Mexico's interbank transfer system, run by Banxico) the gap is short, and on a USD wire it can be days. At Lumx, SUCCESS means the off-ramp is complete once the funds leave its banking partner. The receiving bank can still hold them for its own review, and on wires, correspondent banks can add days and deduct fees.

For ACH, FEDWIRE and SWIFT, show the sender the settlement window next to the word Sent, taken from payout cut-offs by rail. The corridor view is in what a stablecoin corridor is.

What a held payout looks like, and what an RFI changes

A hold is not a status. The off-ramp list above has five values and none of them is "on hold". The documentation describes a review instead: on-ramps and off-ramps flagged by Lumx's transaction monitoring are held pending review, which prevents fraud and money laundering and protects the banking partners.

The request that comes with a hold is an RFI (request for information, a compliance hold that asks for a document before a transaction clears). Compliance reviews the flagged transaction manually and, if it is not a false positive, reaches out by email or Slack, usually asking about the relationship between sender and receiver, the purpose and the expected outcome.

The clock matters more than the name. If nobody answers within 24 hours, the transaction may be refunded to the sender, so a payout that has stopped advancing is a task with a deadline for someone on your team, not a spinner. With no hold value to key on, the signal is time in the current status: store the timestamp of each event and surface any payout that has sat longer than its rail's window.

Customers and accounts have their own RFI states and webhooks, so keep them out of the payout handler. The reasons a payout is stopped at all, with the error code behind each, are in why a stablecoin payout gets rejected.

How do you track a payout on each rail?

The status tells you the stage. To prove where a payment is, you need the identifier the rail itself uses.

What identifies a payment on each rail, and where it is looked up.

For Pix, the end-to-end ID is what a recipient's bank needs when the recipient says the money is missing, and it is the same on both sides of the payment. For SPEI, Banxico's CEP page takes the clave de rastreo plus the date, the beneficiary account and the amount. PSE (Colombia's online bank-transfer network) is a pull rail, so the CUS belongs to the deposit that funds a balance and not to a payout. For SWIFT, the UETR lets you follow a payment across correspondent banks instead of asking each one, and Lumx runs SWIFT in USD only.

Keep the transaction id, which every Lumx webhook and read carries, and attach the rail identifier to the same record: the id is yours to query, and the rail identifier is what the recipient's bank understands. The offramp.success receipt carries the amounts, fees, rate, transaction hash and block explorer link. For the Pix, SPEI or SWIFT reference of a specific payout, ask Lumx with the transaction id.

Lumx's settlement tracking is UETR and MT103 confirmations on every SWIFT payout, per-rail reference on every transfer, webhooks (in that sentence, transfer means any payment movement, not the wallet-to-wallet transaction type). The Brazilian leg is walked through in USDC to a Brazilian bank account, and the pages for USDC to BRL and USDC to MXN show the pair each rail serves.

How long does each stage take?

Only the bank leg has a duration set by the rail. The published timelines are processing targets, not contractual guarantees. Pix and SPEI settle instantly every day, with no cut-off. FEDWIRE settles the same business day if submitted before 3:00 PM ET. ACH takes one to two business days with a 2:00 PM ET cut-off, and SWIFT takes one to five. A request after a cut-off, on a weekend or on a bank holiday waits for the next business day in that rail's jurisdiction.

The full table is in limits and cut-offs by rail. The threshold for "this payout looks stuck" differs on every rail: on Pix, a payout still in TRANSFERRING_FIAT after a few minutes deserves a look, and on a wire the same wait is normal. A payout nobody notices is stuck costs a support ticket from the recipient and, under an RFI, a refund after 24 hours that sends the sender back to the start.

Live rails are on the coverage page, and the legs per country on global payments.

Building the status screen and the ledger behind it

A webhook can arrive late, twice or out of order, so treat the event as a prompt to read the transaction, and mark a payout settled only on what the read returns. Lumx makes up to eight delivery attempts over roughly a day, and failed messages can be retried by hand from the dashboard.

Three rules cover most of the state logic: never leave a final status, ignore an event whose status equals the current one, and never let a timer decide a status. Matching payouts to your books is a separate job, covered in how to reconcile stablecoin transactions.

Status names also move. In October 2024 the first off-ramp status was renamed from PROCESSING to TRANSFERRING_STABLECOIN, and in May 2026 a customer verification status was renamed to RFI. Log an unknown status instead of coercing it, and read the Lumx changelog before each release.

I recommend showing the sender "sent" when the payout reaches SUCCESS and keeping "paid" for the moment the recipient confirms or your own bank data shows the credit, because the status describes the money leaving us and the recipient's bank can still hold it. I would also put every payout older than its rail's window in a daily list for a human, rather than in an alert, because a list gets worked and an alert gets muted. It costs one query and a timestamp column.

When you book a completed payout, read the receipt and not the request: the request holds what you asked for, and the receipt holds what actually applied. To retry a failed payout, create a new one with a new idempotency key, because for 24 hours the same key returns the cached response of the original. The mechanics are in idempotency keys for a stablecoin API.

When a status screen is the wrong place to look

A status is a statement about the platform and no proof about the recipient. When a recipient says the money did not arrive, the recipient's bank can say what happened next, so quote the rail identifier from the table above. A finance team needs the receipt, not the status word. A held payout needs a person to answer the RFI inside 24 hours. And with a handful of payouts a month, the dashboard and a webhook to a shared channel are enough.

What a payout looks like with Lumx

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.

For a payout, the sequence is the one in the first table. The platform debits the customer's wallet, converts, and sends the transfer to a destination registered and verified in advance, and each step emits its event. A payout that fails emits offramp.failed, and the transaction read carries an error object in its state that tells you to contact support. FAILED is final, so send support the transaction id and make a new payout once you have the answer.

On the recipient's bank statement, a Pix payout shows the customer as the payer (effective November 2026), and so do SPEI, ACH, FEDWIRE, SEPA, Faster Payments and SWIFT. A COP payout from a non-Colombian customer shows the banking partner as sender.

Methodology and sources

The Lumx statuses, events, retries, RFI behaviour, cut-offs, settlement definition and changelog entries were read on November 1, 2026 from the Lumx documentation: the transactions page, the webhook reference, the Request for Information page, the SLA and cut-offs page and the changelog, with status enums checked against the API reference for reading a transaction.

For rail identifiers, the clave de rastreo and the CEP service are described on the CEP page at banxico.org.mx, read on November 1, 2026. The PSE CUS (from Descubre PSE), the Pix end-to-end ID (Central Bank of Brazil standards) and the SWIFT UETR (SWIFT gpi) are named without links, because those sources did not load for an automated reader that day, so no format detail beyond the name is stated.

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

Cover photo: Md Rumon Munshi on Unsplash.