How to on-ramp BRL, MXN, ARS, and COP into stablecoins: Pix, SPEI, Transfers 3.0, and PSE

To on-ramp Latin American currency into stablecoins, the payer sends a local bank payment and the provider converts it: Pix in Brazil, SPEI in Mexico, Transfers 3.0 in Argentina, and PSE in Colombia. Each rail shows the payer something different, needs different payer data, and settles in seconds to minutes. Then USDC or USDT lands in a wallet.

Most writing about stablecoins in Latin America covers the other direction: paying out to a Pix key or a CLABE. This guide covers money coming in, which is where most integrations hit their first surprises.

Key takeaways

• Every rail hands the payer a different instruction: a Pix code, a CLABE, a CVU or CBU, or a payment link.
• Instant rails let the on-ramp check who's paying. Expect to collect the payer's tax ID, and for PSE, their full details.
• Mexican, Argentine, and Colombian pesos are often quoted in whole units only. Centavos can get a payin rejected.
• The on-ramp is funded by the payer's deposit, so there's nothing to pre-fund.
• Choose the token and network for where the money goes next, not for where it came from.

How does a local bank payment become a stablecoin?

The flow is the same in every country. Only step 3 changes.

1. Quote. Your backend asks the on-ramp to convert an amount of local currency into USDC or USDT for a specific wallet. The quote locks the rate and fees for a few minutes and records who is allowed to pay.
2. Create the payment. The on-ramp returns the payment instructions for the rail.
3. The payer pays. From their own bank app, using the Pix code, CLABE, CVU, or link.
4. Match. The on-ramp detects the deposit and matches it to the quote: amount, payer, reference.
5. Convert and deliver. The on-ramp converts the currency and sends the stablecoins on-chain.
6. Confirm. A webhook tells your backend the payment is complete.

Integrating a crypto on-ramp API covers the code for each step. The rest of this page is about step 3, rail by rail.

Which Latin American rails can fund an on-ramp?

Four rails cover BlindPay's payin side in Latin America.

Brazil also has TED, a wire-style rail that's slower than Pix, which BlindPay enables per instance. And US payers have their own set: ACH, wire, and RTP, plus SWIFT into a US virtual account. Those are covered in accepting bank transfers in stablecoins.

How does on-ramping with Pix work in Brazil?

Pix is the Banco Central do Brasil instant payment system. It runs 24/7, settles in seconds, and nearly every Brazilian bank account and wallet app supports it.

For an on-ramp, the payer gets a Pix code: a "copia e cola" string or a QR code that already carries the amount and the recipient. They paste it into their bank app, confirm, and it's done.

What to know:

• Payer allowlist. BlindPay Pix quotes take pix_allowed_tax_ids, the CPF or CNPJ numbers allowed to pay. They're validated against the Receita Federal check digits when the quote is created, so a mistyped CPF fails immediately instead of at the bank.
• Waiting window. A Pix payin usually lands within minutes. BlindPay waits up to 30 minutes, runs a reconciliation check, and only then marks it failed.
• Large amounts. For BRL into USDT of $5,000 or more, you can request an OTC quote (is_otc: true), priced through BlindPay's OTC desk. OTC quotes expire in 10 seconds and wait for the deposit until 23:59 São Paulo time. A deposit that never arrives adds a $100.00 penalty to the billing fee, so only quote OTC when the payer is ready.

How does on-ramping with SPEI work in Mexico?

SPEI is Mexico's interbank transfer system, run by Banxico. Like Pix, it runs around the clock and settles in seconds.

The payer gets an 18-digit CLABE and transfers to it like any other account. There's no QR code and no payer allowlist on the quote, which makes SPEI the simplest of the four to integrate.

The trap is centavos. On BlindPay, a sender-side SPEI quote must be a whole number of pesos: request_amount has to be a multiple of 100 in minor units, or the quote fails with request_amount_must_be_a_whole_currency_unit. If you quote from the stablecoin side instead, the peso amount is rounded down to a whole unit for you.

How does on-ramping with Transfers 3.0 work in Argentina?

Transfers 3.0 is the Banco Central de la República Argentina framework that made transfers interoperable between banks and wallet apps. The payer sends pesos to a CVU (a wallet account), a CBU (a bank account), or an alias.

On BlindPay, two rules apply:

• CUIT or CUIL is required. transfers_allowed_tax_id names the tax ID allowed to pay, in the 20-12345678-6 format.
• Whole pesos only. Same rule as SPEI.

Argentina adds one forgiving behavior. If a Transfers 3.0 deposit arrives after the payin was already marked failed, and no stablecoins were sent yet, BlindPay revives the payin and completes it once the sender's tax ID and amount match. Late payers don't automatically mean a refund.

How does on-ramping with PSE work in Colombia?

PSE, Pagos Seguros en Línea, is Colombia's online bank debit, operated by ACH Colombia. Instead of pushing money to an account number, the payer opens a payment link, picks their bank, and approves the debit inside the bank's own site, usually with two-factor authentication.

That redirect means PSE needs more payer data up front. A BlindPay PSE quote requires:

Colombian pesos have a much smaller unit value than the other currencies, so the minimum in raw minor units is higher. Read the minimum from the quote error instead of hardcoding it. And quote whole pesos, as with SPEI and Transfers.

Which stablecoin and network should you deliver to?

Pick the token for the next step and the network for cost and compatibility.

Token. USDT is widely used across Latin America for savings and peer-to-peer trades. USDC is common for business treasury and for settling with US counterparties. USDC vs USDT for payments compares them in depth. Both are redeemable with their issuers: Circle for USDC and Tether for USDT.

Network. On BlindPay, payins can deliver to:

The network is read from the destination wallet, so you choose it when the wallet is registered, not on each quote.

Do you need to pre-fund a Latin American on-ramp?

No. The payer's deposit funds the on-ramp. The provider delivers stablecoins after the pesos or reais land, so neither you nor the provider parks a balance in each country in advance. Pre-funding is an off-ramp and payout question, covered in what no pre-funding means.

What does a full example look like?

A US fintech offers dollar balances to small businesses in Brazil, Mexico, Argentina, and Colombia. Each business tops up its balance from its own local bank account, and the balance is USDC on Solana.

1. Each business onboards through the fintech's signup. The fintech passes the KYB data to the on-ramp API, which registers each business as its own customer.
2. Each business's Solana wallet is registered once.
3. When a business wants to top up, the fintech requests a quote in that business's currency, with payer rules naming the business's own tax ID.
4. The business sees the right instruction inside the fintech's app: a Pix QR code, a CLABE, a CVU, or a PSE button.
5. As each deposit lands, USDC arrives in that business's wallet, and a webhook updates the balance in the app.

Four countries, four rails, one integration, one token on one network. The fintech never opens a bank account in Latin America, and every business that moves money is a verified customer of the on-ramp.

How are fees handled?

Every payin quote shows the market rate, the rate with fees, and each fee line before the payer pays. The cover_fees flag decides who pays: false takes the fee out of the stablecoins delivered, and true adds it to the amount the payer sends. A platform can add its own partner fee on top. Crypto on-ramp fees explained shows how to compare quotes.

Where does BlindPay fit?

BlindPay collects payins over Pix, SPEI, Transfers 3.0, and PSE, plus TED in Brazil and ACH, ACH pull, domestic wire, RTP, and SWIFT in the US, converts them, and delivers USDC or USDT to the wallet on the quote. Delivery can go to an external wallet the customer controls, so the stablecoins never sit with BlindPay, or to a BlindPay-managed wallet (beta), which BlindPay custodies. Payer rules, whole-unit amounts, and waiting windows are enforced by the API, so most mistakes fail at quote time. The same API pays out over local rails when the money needs to go back to a bank.

When BlindPay is the right fit: you collect from businesses or individuals in Brazil, Mexico, Argentina, or Colombia and want stablecoins in a wallet, through one API, with KYC and KYB handled. When it isn't: you need local virtual accounts in Latin America today (BlindPay's virtual accounts are US accounts), or card checkout for retail crypto buyers. See payins and payment methods for the full reference.

What to do next

Pick the one country where most of your payers are and run a single payin end to end on a development instance. Then read why crypto on-ramp deposits fail before you launch, and check the compliance split in who owns on-ramp compliance. For the bigger picture, start at business vs consumer crypto on-ramps.

This article is general information, not legal, tax, or financial advice. Rails, payer requirements, and supported networks change; confirm current details in the docs.