The problem: the order is fine, the card rail isn't
A store that sells internationally hits three card-rail failures that have nothing to do with whether the customer can pay. The first is the geographic decline: an issuer or acquirer blocks a card because the billing country, the merchant country, or the cardholder's location trips a rule, and a paying customer gets a generic failure with no way to fix it. The second is FX: the customer is quoted in your currency, charged in theirs at the issuer's rate plus a foreign-transaction fee, and the amount that lands in your account is converted again at the gateway's rate — so the figure you booked and the figure you receive drift apart. The third is reach: in some regions the card a customer holds simply does not work for cross-border online purchases at all.
None of these are the customer's fault and none are something your store can fix from its side. You can lose a genuine order to an issuer rule you never see, and you find out only when support gets an email asking why the payment keeps bouncing.
A confirmed on-chain payment removes the rail from the equation. There is no issuing bank deciding whether a cross-border transaction is allowed, no foreign-transaction fee layered on top, and no second conversion at settlement. The customer pays from their wallet; halfin watches the chain and credits the payment under that chain's confirmation rules. Where the wallet physically is does not change whether the transfer goes through.
Price in your fiat, settle in stablecoins, no FX surprise
The reason cross-border crypto works for a store is that the customer can pay in a dollar-pegged stablecoin while you keep thinking in your own catalogue currency. You create a halfin invoice anchored to the order total in USD, EUR, or whatever you price in. halfin computes the payable asset amount from the live rate and locks it when the invoice activates. The customer sees a concrete figure — pay 49.00 USDC — and you reconcile against the 49.00 fiat figure you billed, regardless of where they paid from.
Because the quote is fixed at activation and the invoice carries an expiry, the market move between checkout and confirmation is not your problem or the customer's. They owe the amount they were shown; if the payment window lapses, the invoice expires rather than silently re-pricing, and you re-issue at the current rate. There is no foreign-transaction fee and no settlement-time conversion eating the difference — a stablecoin payment of 49.00 USDC is 49.00 of value when it confirms.
Stablecoins are the practical default here precisely because both sides know the dollar value will not move. A customer paying in USDC or USDT on a network they already hold funds on is making a payment whose value is legible to your finance process the moment it settles, anchored to the fiat number you started from.
- Anchor the invoice in your own fiat currency — the customer's location does not change the figure you book.
- Rate locks at activation; the customer owes a fixed stablecoin amount, with a bounded expiry window.
- No foreign-transaction fee and no gateway re-conversion between charge and settlement.
- A confirmed payment is final under the chain's rules — no issuer geography rule sits between you and the order.
Where the card rail fails and where stablecoins don't
This is the side-by-side a store actually cares about: the same cross-border order, run on a card and run as a halfin invoice. The point is not that crypto is universally better — it is that the specific failure modes that cost you international orders are absent from a confirmed on-chain payment.
| Cross-border friction | On the card rail | On a halfin stablecoin invoice |
|---|---|---|
| Geographic decline | Issuer or acquirer can block the transaction on a country / location rule. | No issuing bank in the path; the wallet pays from anywhere on the network. |
| Currency conversion | Charged in the cardholder's currency, converted at the issuer rate, then again at settlement. | Customer pays a dollar-pegged stablecoin; you booked and receive the same fiat-anchored figure. |
| Foreign-transaction fee | Layered on by the issuer; opaque to the merchant and the customer. | Not present — the customer sends the quoted asset amount, no cross-border surcharge. |
| Settlement finality | Reversible by chargeback weeks after the order ships. | Final once confirmed; returns are deliberate refunds against the original invoice. |
| Reach in under-banked regions | Some cards simply don't work for cross-border online purchases. | Anyone with a wallet on a supported network can pay. |
Pick the network the customer in that region already holds
Cross-border reach depends on letting the customer pay on a rail they actually use where they are. Stablecoin habits cluster by region — USDT on Tron is the low-friction default for a large share of international payers, USDC on Base or Ethereum is common for EVM-native customers, and a Bitcoin holder can pay from cold storage. You enable the networks that match your customers; the customer picks one they already hold funds on at the hosted checkout.
Every option below is a real on-chain gate, and every stablecoin payment settles to the same fiat anchor on your invoice. The reorg-aware crediting and per-chain confirmation thresholds mean a payment shown as confirmed has actually settled under that chain's rules — the international customer is not in a different, riskier flow than a domestic one.
| Network | Stablecoins a cross-border customer can use | Why it shows up internationally |
|---|---|---|
| Tron | USDT (TRC-20) | Widely held low-fee stablecoin rail across many regions |
| Ethereum | USDT (ERC-20), USDC (ERC-20) | EVM-native payers and larger transfers |
| Base | USDC | Low-fee USDC for EVM-native customers |
| Solana | USDT (SPL), USDC (SPL) | Fast, low-fee stablecoin settlement |
| Bitcoin | — (native BTC) | Customers paying from BTC-only or cold-storage wallets |
The integration is the same one you already use for domestic orders
Cross-border is not a separate integration. It is the same invoice-plus-webhook flow your store uses for any order: you create an invoice anchored to the order total, redirect the customer to the returned hosted checkout URL, and wait for the signed webhook before you mark the order paid and release fulfilment. A customer in another country runs through exactly the same path as one next door — the only difference is which network they pick and that no card issuer is deciding whether to allow it.
Treat the redirect as cosmetic and the webhook as authoritative. A customer on a slow connection abroad may close the tab before the success redirect fires; the HMAC-signed webhook still arrives, and that is what should flip the order to paid. Always verify the signature before acting on it. The fiat amount is sent as a string — monetary values are strings end to end, never floats — and the full request and response schema is at docs.thehalfin.com.
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": "49.00",
"fiat_currency": "USD",
"idempotency_key": "order-77310"
}'
# You still price the order in your own fiat currency. The customer
# abroad settles in the stablecoin they hold — USDC, USDT — on a
# network you enable, from the hosted checkout URL in the response.
# Verify the signed invoice webhook before releasing the order.Compliance still belongs to the store
Selling across borders does not move your obligations onto halfin. halfin is payment infrastructure: it collects the payment, applies reorg-aware crediting, records the transaction, and reports status through the dashboard and signed webhooks. It does not take over your customer onboarding, your tax treatment in each market you sell into, or any approvals the goods themselves require where the customer is.
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 an educational concept to factor into how you design cross-border flows, not a certificate halfin issues to you. None of this makes halfin regulated on your behalf or a substitute for your own controls.
If you sell into regions with their own rules, keep your own customer identity checks, your own counterparty and wallet screening, and your own record of which order each invoice belongs to. halfin gives you the payment primitives and the audit trail; the decision about who you serve in which market stays yours.
- KYB onboarding verifies the business behind the merchant account.
- AML awareness is a process, not a status halfin grants for cross-border sales.
- Travel rule is described as an educational concept, never a certification.
- Keep your own per-market KYC, screening, and per-order records as the source of truth.