How long does a stablecoin on-ramp take? Timing by funding rail

A stablecoin on-ramp takes as long as the payer's bank rail takes to deliver, plus a short conversion step. On BlindPay, Pix, SPEI, Transfers 3.0, and PSE deposits typically settle within minutes. US ACH and wire payins have an arrival window of up to 5 business days. The quote itself only lasts 5 minutes.

This is the on-ramp mirror of how long a stablecoin payout takes. Same question, opposite direction, and the slow part sits in a different place.

Key takeaways

• The on-ramp clock starts when the fiat lands, not when you create the payin.
• Local instant rails (Pix, SPEI, Transfers 3.0, PSE) settle in minutes. US ACH and wire can take up to 5 business days.
• A payin quote lasts 5 minutes. A Pix OTC quote lasts 10 seconds.
• Instant-rail payins fail after 30 minutes without a deposit. A created payin can't be canceled.
• Compliance holds can add up to 30 days. Sandbox auto-completes in about 30 seconds, which is not a production number.

What happens between "pay" and "USDC in the wallet"?

Four steps, and only one of them is slow. BlindPay's payins docs describe the flow as quote, payin, deposit detection, settlement.

1. Quote. You request a payin quote with the amount, payment method, fee setting, and destination wallet. It locks the numbers for 5 minutes (payin quotes).
2. Payin. You create the payin from the quote and show the payer the instructions: a Pix code, a CLABE, a CBU, a payment link, or US bank details with a memo code.
3. Deposit. The payer sends the money. This is the variable part, and it depends entirely on the rail.
4. Settlement. BlindPay detects the deposit, converts it, and delivers USDC or USDT to the wallet you named on the quote.

Steps 1, 2, and 4 are measured in seconds to minutes. Step 3 is measured in whatever the payer's rail allows, plus however long the payer takes to press send.

How long does each funding rail take?

Here are BlindPay's documented windows for payin arrival. The first column comes from the payins reference, the second from the cut-off times reference.

Two notes on reading it. The cut-off reference says its ACH and wire numbers describe the networks in general, not BlindPay's end-to-end ETA, which adds BlindPay's own processing. And TED's 7-day window exists to cover a Friday cut-off with reconciliation the following week.

The local rails are fast because the rails themselves are fast. Banco de México says a SPEI payment should not take more than 30 seconds after approval, and Argentina's central bank describes Transfers 3.0 as transfers credited online in a maximum of 15 seconds. Pix runs around the clock in Brazil.

US bank rails work in batches and business days. The Federal Reserve's FedACH processing schedule runs on fixed transmission deadlines and settlement times, and BlindPay's cut-off reference lists a 9:00 PM ET ACH cut-off and a 3:00 PM ET domestic wire cut-off. Miss it and the transfer waits for the next business day.

Illustrative example: how long does a Monday-evening on-ramp take?

Illustrative example. Two customers start an on-ramp at 6:00 PM local time on a Monday.

Same amount, same minute, a gap of days. The difference is not the stablecoin leg. It is the bank leg that feeds it.

Customer B has an extra option. If the payer misses the 9:00 PM ET ACH cut-off, the arithmetic shifts by one more business day: Monday 9:01 PM behaves like Tuesday morning.

Where does the on-ramp clock actually start?

When the fiat lands. Not when you request the quote, and not when you create the payin.

That matters for your UX copy. "USDC in 5 minutes" is true for a Pix payer who pays immediately. It is false for a Pix payer who opens the code, gets distracted, and pays 25 minutes later. The rail was fast. The human was not.

It also matters for the 5-minute quote window. The quote is about locking numbers, not about delivery. You create the payin inside those 5 minutes; the deposit can come after. Where the exchange rate gets fixed walks through exactly when the rate stops moving on each side.

OTC Pix quotes are the exception. They expire in 10 seconds, and BlindPay waits for the deposit until 23:59 BRT the same day instead of a rolling 30-minute window. If that deposit never arrives, the docs add a flat $100.00 penalty to the quote's billing fee.

What slows an on-ramp down?

Four things, in rough order of how often they bite.

1. The payer. Late payment is the most common delay, and no rail fixes it. Show a countdown and a clear "pay now" state.
2. Cut-offs. ACH, wire, and TED follow business days. A Friday evening transfer can sit until Monday, and longer around holidays.
3. Mismatched details. A Pix from a tax ID that isn't allowed by the quote's payer_rules, or a US transfer without the memo code, can't be matched cleanly. Why on-ramp deposits fail lists the patterns.
4. Compliance holds. A payin can go on_hold for manual review. The cut-off reference says holds can take up to 30 days to resolve.

There's also a funding option in private beta since September 18, 2026: ACH pull, where BlindPay debits a bank account the customer connected through Plaid instead of waiting for a manual transfer. It removes the "payer forgot to send" delay on the US side, and the quote adds a flat $1.00 fee for it.

How should you set expectations in your product?

Promise per rail, not per product. A single "funds arrive in minutes" line is guaranteed to be wrong for someone.

A pattern that works:

• Pix, SPEI, Transfers 3.0, PSE: "Usually arrives within minutes after you pay."
• US ACH and wire: "Arrives within a few business days after your bank sends it."
• On hold: "Under review. We'll update you as soon as it clears."

Drive every status change from webhooks. payin.new fires when the payin is created, payin.update fires when its status or tracking data changes, and payin.complete fires when the stablecoins reach the destination wallet. The payin moves through processing, then completed, failed, or refunded, with on_hold possible along the way. How to integrate a crypto on-ramp API has the full webhook handling.

If you're choosing which rails to offer in the first place, how to on-ramp BRL, MXN, ARS, and COP covers each local rail in detail, and how to read an FX quote explains the rate the payer sees before they pay.

Does the stablecoin leg add time?

Barely. Once BlindPay has the fiat, it converts and sends the stablecoin on the destination wallet's network. That's one on-chain transaction.

The docs add one practical detail: if the delivery transaction gets replaced during a gas spike, BlindPay resolves the transaction that actually landed. The hash you see in tracking_complete can differ from the one you first saw broadcast. Treat status as the source of truth, not a specific hash.

What about the USDC itself? Where on-ramp USDC comes from covers why the stablecoin side is rarely the bottleneck.

What to do next

Create a payin quote on a development instance for each rail you plan to offer, then write one line of arrival copy per rail using the windows in the payins docs. Swap the sandbox's 30-second auto-complete for real numbers before launch.