Accepting stablecoin payments in Brazil means letting a customer pay you in USDC or USDT and deciding, before the money arrives, whether you keep it as dollars or settle it into reais in your company's bank account. Both halves are choices you make once and then encode in a process, and the second half is the one that has rules attached.
This guide is written for the case that actually shows up in Brazil: a business invoicing foreign customers, not a shop taking tokens at a counter. It covers the two models, the settlement decision, the address and network problem, reconciliation, refunds, what the rules ask of you, and when accepting stablecoins is not worth the trouble. If the token itself is new, start with what a stablecoin is.
Two models, and only one of them is common here
Invoice settlement. You send an invoice, the customer pays it in USDC or USDT, and the payment arrives as a transfer to an address you control. This is where almost all real volume sits in Brazil: software companies, agencies, exporters and service firms billing customers abroad who would rather send a token than a wire.
Checkout acceptance. A customer pays at the moment of purchase, with a price quoted in reais and a token amount calculated at the rate of that second. This carries an extra problem that invoicing does not, because the price has to hold long enough for the customer to sign a transaction.
The rest of this guide is about the first model, with a note on the second where the difference matters.
Decide your settlement currency before the first payment
Keeping dollars and settling into reais are different businesses, and the choice is a treasury decision rather than a payments one.
Settle into reais. The provider converts and pays your company's Brazilian account, usually within minutes of the transfer confirming, and your accounting sees an ordinary receipt in reais. This is the right default if your costs are in reais and you do not want to hold a currency position.
Keep dollars. You hold USDC or USDT and convert when you choose. This suits a business with dollar costs or one that wants to time its conversion. What you are holding then matters: Circle publishes USDC reserve holdings weekly along with the mint and redemption flows, and states that a Big Four accounting firm provides monthly third-party assurance that the reserves exceed the tokens in circulation. That is the kind of disclosure to look for before you decide to hold a token rather than pass it through.
Most companies split it, converting a fixed share on receipt and holding the rest. The flow in the other direction, taking reais and producing dollars, runs through a stablecoin on-ramp, and a business with both sides ends up using both.
Give each customer its own destination
The temptation is to publish one wallet address and one bank account and be done. It works until the second customer pays on the same day.
One destination per customer, or per invoice. With tokens this means a dedicated deposit address; with bank rails it means a named virtual account (a local account number issued in the customer's own name), the customer here being your company. Either way the arriving money identifies itself, which is what turns reconciliation into a lookup.
Be explicit about networks. Say which networks you accept for each token, and issue the address per network rather than as a single string. A customer sending on a network you do not credit is the most common way this goes wrong, and it is a design problem on your side before it is a mistake on theirs.
Say which tokens. Accepting USDC and USDT is two decisions, not one, and a customer who holds only one of them needs to know before the invoice is due.
Reconciliation is the actual product
A payment is useful when your finance team can tie it to an invoice without asking anyone. Three things make that work.
The reference: a per-invoice destination, so the arriving amount carries its own answer.
The event: a webhook that tells your system the money arrived, with the sender, the amount, the token, the network and the rail's own identifier, rather than someone refreshing a screen.
The statement: a record that your accountant can read next quarter, showing what arrived, what it converted to, at which rate, and what the conversion cost.
If you settle into reais, the BRL and USDC corridor page shows the live rate for that pair, and the rate that applied to a given payment should appear on the payment, not as a monthly average.
Refunds work differently, so write them down
A stablecoin transfer is final when it confirms. There is no chargeback, no reversal and no issuer to appeal to. That is a benefit on the fraud side and a liability in your refund policy.
Decide in advance whether a refund goes back in the same token to the same address, or in fiat, and who carries the rate movement between payment and refund. Put it in the contract. A customer who paid 10,000 USDC in March and is refunded in reais in June did not receive the same thing they paid, and the time to agree on that is before it happens.
I have watched one version of this go wrong more than once, and it is never the crypto part. A client of ours, a Brazilian agency, took its first stablecoin payment into a single shared address because it was the fastest thing to set up, and for two months it was fine. Then two customers paid within the same hour, one of them short, and the finance lead spent a day reconstructing which of the two had underpaid. They were convinced they had a payments problem. What they had was an addressing problem, and the fix was one destination per customer, which took an afternoon. I bring it up because the instinct when something goes wrong with a new rail is to distrust the rail, and the boring answer is usually that the setup skipped a step that the old rail did for you.
What the rules ask of a merchant
Receiving payment for your own goods and services is not the same activity as operating a payments business. In Brazil the framework for virtual asset service providers is Law 14.478 of December 21, 2022, which defines the services that require authorization, and providing those services to third parties is what triggers it. Taking payment from your own customer does not put you in that position, and converting it into reais does, which is exactly why that leg runs through an authorized provider instead of through you.
Two practical consequences. The conversion into reais will be booked by an institution authorized to operate in the Brazilian foreign exchange market, so ask your provider which institution that is. And the commercial documentation behind the payment, your contract or invoice with the customer, is what supports the operation and will be asked for, so it should exist before the money does.
None of that is tax advice and none of it is a substitute for your accountant, who will have opinions about how a receipt in dollars is recognised.
When accepting stablecoins is not worth it
When your customers are Brazilian. They have Pix (Brazil's instant payment system, run by the Central Bank), it is free or nearly free, and it settles in seconds. Adding a token to a domestic sale is a cost with no benefit.
When your volume is a few small invoices a year. The setup, the onboarding and the process changes are fixed costs, and a couple of wires may genuinely be cheaper.
When your customers cannot pay that way. Some corporate finance departments will not send a token, whatever their engineers think, and a payment method your customer cannot use is not a payment method.
When you need chargeback-style protection on consumer sales. Finality cuts both ways, and a consumer business with disputes may want the card rails it complains about.
Accepting payments on 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, 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.
A Brazilian business collecting on Lumx gets deposit addresses issued per customer and per network, plus named virtual accounts in its own legal name for customers who would rather send a bank transfer than a token. Arrivals emit an event carrying the sender, the amount, the network and the reference, and settlement into reais is a conversion you trigger per payment or by rule, with the applied rate recorded on the payment rather than averaged at month end.
Verified on September 25, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Paul Zoetemeijer on Unsplash.
Can a Brazilian company legally receive payment in USDC?
Receiving payment in a stablecoin from your own customer is a commercial arrangement, and what is regulated is the conversion into reais, which must run through an institution authorized to operate in the Brazilian foreign exchange market. That is the leg your provider is responsible for, and the contract or invoice behind the payment is what supports it.
How fast does the money become reais?
The transfer confirms in seconds to a couple of minutes depending on the network, conversion is immediate when the provider holds reais, and the Pix credit settles in seconds at any hour. For an established destination the realistic figure is minutes from confirmation to the bank account.
What happens if a customer sends on the wrong network?
Recovery depends on whether your provider controls that address on the network the customer used. Publishing the address per network, rather than one string with a note, prevents most of these, and asking a new customer to send a small test amount prevents the rest.
Do I have to accept both USDC and USDT?
No, and you should decide deliberately rather than by default. USDT is more common among customers in some markets and USDC among institutional counterparties, so the answer follows your customer base. Whichever you choose, say it on the invoice along with the networks you credit.
