The Brazilian payment landscape, and where it gets thin
Domestically, Brazil is well served. Instant account-to-account transfers and local cards handle the bulk of everyday commerce cheaply and fast, and for a business selling to Brazilian customers in the local currency there is often no reason to reach for anything else. Brazil is also a heavy crypto-using market by any measure, so a wallet is not an exotic thing to ask a customer for.
The friction is at the borders of that domestic system. The local instant-transfer rail is built for in-country payments; it does the wrong job, or no job, when the counterparty sits abroad or holds dollars on-chain. Cross-border card acceptance carries its own drag: international cards decline more often, expose the merchant to currency conversion the customer feels, and bring chargebacks that can land weeks after the goods have shipped. For a Brazilian store reaching customers outside the country — or a foreign-facing platform collecting from Brazilians — that decline-and-conversion tax is a real loss of conversions, not a rounding error.
This is the widely reported reason BRL-to-USDT has become a practical corridor for cross-border value: a dollar-pegged token held on-chain moves across borders without depending on a card network or a remittance rail, and it lands as a stable dollar amount on both sides. That is the gap a crypto rail fills, and it is why Brazilian merchants with any cross-border flow commonly settle in stablecoins even when they still price for local customers in the local currency.
Which assets fit a cross-border Brazilian business
For payments that cross a border, the asset that fits best is the one whose value does not move between checkout and confirmation. Dollar-pegged stablecoins — USDT and USDC — are the common case: the customer pays a stable amount, and the merchant receives a stable amount, with no exposure to a swinging market in the minutes a payment takes to confirm. halfin anchors each invoice to your fiat figure and locks the quote when the invoice activates, so an order owes a fixed crypto amount even if the asset's price drifts while the customer is paying. You can anchor an invoice to USD for an international order or to your local currency for a domestic one — the rate lock works the same way either side of the border.
Where the customer holds those stablecoins decides the network. USDT settles on Tron, Ethereum, or Solana; USDC on Ethereum, Base, or Solana. In Brazil, Tron-based USDT is widely held because its transfer cost is low and predictable, but a merchant does not have to pick one rail — you enable the networks your customers actually use and let each customer pay on the chain they already hold funds on. Bitcoin remains the option for customers who prefer to pay in BTC, with the same fiat-anchored invoice and the same reorg-aware crediting before a payment counts as settled.
On your side, a mixed inflow does not have to stay scattered. Balance conversion consolidates what arrives — USDT on one chain, USDC on another, a little BTC or SOL — into the asset you want to hold as your reserve, automatically on a policy you set or manually when you decide to rebalance. A business that wants to sit mostly in a dollar stablecoin to settle with foreign suppliers can do that without managing each balance by hand. Balance conversion moves between assets you hold; it is not a way to sell crypto for cash.
- Anchor an invoice to USD for an international order or to your local currency for a domestic one; the rate locks at activation, so the customer is not exposed to price movement mid-payment.
- USDT on Tron, Ethereum, or Solana — Tron USDT is widely held in Brazil; USDC on Ethereum, Base, or Solana.
- Bitcoin for customers who pay in BTC, same fiat-anchored invoice and confirmation rules.
- Balance conversion consolidates a mixed inflow into the reserve asset you choose to hold — asset-to-asset, not a cash off-ramp.
Verticals that reach for this in Brazil
The businesses that pull hardest toward a crypto rail in Brazil are the ones where money already crosses a border or where international cards leave conversions on the table. None of these are exotic — they are ordinary online businesses hitting the cross-border, chargeback, or acquirer-risk edges described above.
Cross-border e-commerce is the broadest case: a Brazilian store selling to customers abroad — or a foreign store selling into Brazil — wants to stop losing orders to declined international cards and the conversion customers notice at checkout. Digital-goods and SaaS sellers want final settlement for something delivered instantly that cannot be shipped back when a card later reverses, especially when the customer is in another country. Exporters, agencies, and freelancers want to collect from foreign clients without the drag and delay of traditional remittance. And higher-risk segments that card acquirers treat cautiously still need a reliable way to get paid that does not hinge on keeping an acquirer relationship intact.
- Cross-border e-commerce and marketplaces selling beyond Brazil or into it, where international card declines and conversion cost real conversions.
- Digital goods, software, top-ups, and subscriptions — instant, final settlement for things with nothing to ship back if a card payment later reverses.
- SaaS and subscription businesses billing customers outside Brazil, where machine-to-machine settlement moves value without a human-facing checkout in the loop.
- Exporters, agencies, and freelancers collecting from foreign clients without slow or expensive remittance rails.
- Higher-risk and underserved verticals that card acquirers treat cautiously but that still need a reliable way to get paid.
How halfin fits the existing setup
halfin sits alongside what a Brazilian business already runs; it does not replace your local accounting or the domestic flows that work. You create an invoice anchored to your price, redirect the customer to the hosted checkout page — which handles the wallet, the network choice, the QR code, and live status — and wait for one HMAC-signed webhook before you treat the order as paid. The on-chain detail stays on halfin's side; your order system keeps its existing shape.
For automated commerce — a subscription platform, a billing service, a system that pays another system — machine-to-machine settlement moves value programmatically without a checkout page in the loop. Static deposit addresses give you a persistent receive address when you would rather hand out one address than mint an invoice each time. On the outbound side, single payouts cover a one-off send with operator review, and mass payouts batch many destinations into one idempotent run — submitting the same batch twice does not pay twice — which is what a marketplace settling sellers across borders, or a platform paying foreign suppliers, needs.
Treat the customer's redirect back to your success page as cosmetic and the signed webhook as authoritative: a customer can pay and close the tab before the redirect fires, but the webhook still arrives. Always verify the signature before acting on it. If you ever need to return funds, refunds run as a first-class flow against the original invoice rather than an ad-hoc manual send.
- Create an invoice anchored to your price; the rate locks at activation and expiry is enforced.
- Hosted checkout handles wallet, network, QR, and live status — no on-chain code on your side.
- A signed webhook is the source of truth for marking an order paid; verify the HMAC first.
- Mass payouts settle many cross-border destinations in one idempotent batch; refunds run against the original invoice.
curl -X POST https://api.thehalfin.com/api/v1/invoices \
-H "X-API-Key: $HALFIN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"amount_fiat": "120.00",
"fiat_currency": "USD",
"idempotency_key": "order-BR-60934"
}'
# The fiat amount anchors the order; the customer settles in the
# crypto asset they pick on the hosted checkout page returned in
# the response. Redirect the customer there, then verify the
# signed invoice webhook before releasing the order. See the full
# request and response schema at docs.thehalfin.com.Compliance and availability — a rail, not a licence
A Brazilian business taking crypto still owns its own obligations. halfin is payment infrastructure: it collects payments, executes payouts, keeps payment records, and exposes status through dashboard data and signed webhooks. It does not take over the merchant's customer onboarding, its bookkeeping, its tax handling, or any approval the goods or services themselves require under local rules. Nothing on this page is legal, tax, or financial advice, and halfin makes no claim to be registered or licensed in Brazil or anywhere else.
Onboarding to halfin involves KYB — verifying the business behind the merchant account — and the platform operates with AML awareness as a process. The travel rule, which concerns information that travels with certain transfers, is a concept to understand as you design flows, not a certificate halfin issues. The practical pattern for a Brazilian merchant is to keep your own customer checks, your own counterparty and wallet screening, and your own record of which order each invoice and payout belongs to; halfin gives you the payment primitives and the audit trail, and you keep the decisions about who you serve and what you sell.
Availability is subject to jurisdiction and sanctions screening, and some places are out of scope regardless of demand — see the restricted-countries note for where halfin cannot operate. If your business is based in Brazil and sells to customers at home and abroad, the relevant question is which networks and assets your customers actually use, and how you want incoming balances to settle.
- KYB onboarding verifies the business behind the merchant account.
- AML awareness is a process, not a status halfin grants — and halfin is not 'licensed' in any country.
- Keep your own customer checks, screening, and per-order records as the source of truth.
- Availability is subject to jurisdiction and sanctions screening; see the restricted-countries note.