Crypto payments by country

A payment problem in São Paulo is not the same payment problem as one in Frankfurt. Card decline rates, the cost of moving money across a border, which stablecoin a customer already holds — all of it shifts by market. These country pages describe the honest local picture for accepting crypto: what merchants and their customers actually reach for, where the existing rails strain, and which verticals tend to lead. They do not invent local laws, name banks, or quote statistics, and they never imply halfin is registered in any jurisdiction. Availability is always subject to sanctions and jurisdiction.

Why a country page, and not one generic 'accept crypto' page

Crypto acceptance is often pitched as borderless, and the settlement is — a confirmed on-chain payment looks the same from any country. But the reason a merchant goes looking for it is intensely local. A store in a market with high card-decline rates on foreign issuers has a different problem than a SaaS company trying to collect from customers whose banks block recurring international charges. Both might end up accepting USDT, but they got there for different reasons, and the page that helps them should say so.

So each country page starts from the local friction, not from a feature list. It describes the kinds of payment pain that are common in that market — without naming a specific bank, regulator, tax rate, or law, because those change and we will not invent them — and then shows where a crypto rail genuinely helps and where it does not. The goal is a merchant in that market reading it and recognising their own situation, rather than a template with the country name swapped in.

Everything on a country page is qualitative and non-committal by design. We will say something like 'merchants here commonly price in EUR and settle in stablecoins' or 'cross-border card settlement is a recurring friction point' — statements that are broadly true and carry no specific claim. We will not say a country has a particular licensing regime, a named payment processor problem, or a statistic about adoption. When in doubt, the page says less.

What each country page actually covers

The pages share a shape so you can compare markets, but the content is written market by market, not generated from a form. Read across these five threads and you have the working picture for a market: the existing payment landscape, which crypto assets fit the way people there hold value, the verticals that lead, where halfin slots in, and the compliance and availability caveat that applies everywhere.

• The local payment landscape — the everyday friction merchants describe: card decline rates on foreign issuers, the cost and delay of cross-border settlement, currency volatility against the dollar or euro, or simply customers who prefer to pay from a wallet they already fund.
• Which assets fit — whether customers in that market tend to hold stablecoins (USDT, USDC) or native coins, and on which networks they are cheapest and most familiar. A market that lives on TRC-20 USDT reads differently than one that is EVM-native on Base.
• Which verticals are strong — the kinds of online business that are locally over-represented and most likely to reach for a crypto rail, linked through to the relevant use-case page.
• How halfin fits — the specific primitives that map onto the local problem: fiat-anchored invoicing so prices stay in the merchant's currency, hosted checkout, payouts for paying people abroad, and signed webhooks as the source of truth.
• Compliance and availability — KYB onboarding and AML as process, never a licence, and a clear pointer that whether halfin can serve a given market depends on sanctions and jurisdiction.

The recurring frictions these pages keep coming back to

Across very different markets, the same handful of payment problems show up, which is why crypto acceptance keeps surfacing as an answer. None of these are universal — a country page only raises the ones that genuinely apply there — but they are the threads worth understanding before you read any single market.

Cross-border settlement is the most common. A merchant selling into other countries, or paying contractors and sellers across borders, watches money move slowly and expensively through correspondent banking, with a cut taken at each hop and an FX spread layered on top. A stablecoin payment settles directly between wallets on the network's own timeline, and the merchant prices in their home fiat currency while the customer pays in the asset they hold.

Card acceptance is the second. In some markets a meaningful share of legitimate customers are abroad, on cards that local acquirers decline, or on issuers that block recurring and high-risk charges. Those customers are not fraud — they simply cannot complete a card payment. A confirmed crypto payment sidesteps the acquirer relationship entirely, and because it is final there is no chargeback tail on goods already delivered.

Currency exposure is the third. Where the local currency moves sharply against the dollar, merchants and customers alike gravitate to dollar-denominated stablecoins as a unit they both trust between the moment a price is quoted and the moment it is paid. halfin's invoices lock the conversion rate at activation, so a customer owes a fixed amount and the merchant is not left short by a mid-payment swing.

How halfin maps onto a local payment problem

The product is the same everywhere; what differs is which part of it solves the local pain first. For an inbound problem — customers who cannot pay, or who pay across a border — the lead primitive is invoicing. You create a fiat-anchored invoice in your own currency, redirect the customer to hosted checkout, and they settle in the asset and network they already hold. The rate locks at activation, expiry is enforced, and underpaid or overpaid amounts are handled rather than silently lost. Your server learns the outcome from an HMAC-signed webhook — verify the signature, then act — so the redirect back to your page is cosmetic and the webhook is what flips an order to paid.

For an outbound problem — paying sellers, contractors, affiliates, or refunds across borders — the lead primitives are payouts and balance conversion. Single payouts cover a one-off send with operator review; mass payouts fan out over the payouts API with a per-line idempotency key, so a batch submitted twice does not pay twice. Balance conversion consolidates a spread of incoming assets into the stablecoin you hold reserves in. Static deposit addresses give you a persistent receive address when minting an invoice per payment is overkill, and machine-to-machine settlement moves value programmatically when there is no human-facing checkout in the loop.

None of this is country-specific in the code — it is the same dashboard, the same API, the same hosted checkout regardless of where the merchant or customer sits. The country page's job is to point you at the primitive that matches your market's problem, and to the use-case page that goes deeper for your kind of business.

Compliance and availability — read this before you read a market

A country page describes a market; it does not grant access to it. halfin is payment infrastructure: it collects payments, executes payouts, keeps payment records, and exposes status through dashboard data and signed webhooks. Onboarding involves KYB — verifying the business behind the merchant account — and the platform operates with AML awareness as a process. None of that makes halfin registered, licensed, or regulated in any country, and these pages never imply otherwise.

Whether halfin can actually serve a given market is a separate question from whether the local payment problem is a good fit. Availability is subject to sanctions and to jurisdiction, and that gate sits in front of every country on this index. Before you treat a market as supported, read the restricted-countries notice, which is the authoritative list of where halfin does not operate.

A merchant in any market also keeps its own obligations — its customer onboarding, its tax handling, its counterparty and wallet screening, and any approvals required for what it sells. halfin gives you the payment primitives and the audit trail; the merchant keeps the decisions about who it serves and what it sells. Nothing on a country page is legal, tax, or financial advice.

• KYB onboarding verifies the business behind the merchant account; AML is a process, not a status halfin grants.
• Availability depends on sanctions and jurisdiction — see the restricted-countries notice for where halfin does not operate.
• Country pages carry qualitative local context only: no named laws, banks, regulators, tax rates, or statistics.
• The merchant keeps its own KYC, screening, and tax obligations as the source of truth.

Start with a market

Each country page goes deep on one market's payment picture. Open the one that matches where your business sits, or where your customers are, and you will find the local friction, the assets that fit, the strong verticals, and how halfin maps onto it. If your market is not on the index yet, the underlying product is identical — start from the assets, use-cases, or the developer surface and the country context can come later.