The problem: your reach is global, your card rails are not
Software has no borders, but the card networks that sit under most SaaS billing very much do. A customer in a region your acquirer treats as high-risk gets declined on a perfectly good card. A customer whose bank blocks cross-border merchant charges never completes checkout. A customer in a market where cards are rare or settle through a slow domestic scheme either pays late or gives up. None of these are fraud — they are geography filtered through an issuer's risk model and a processor's coverage map.
For a self-serve product the cost is invisible and large. You see the signups that converted; you do not see the trial that ended at the payment step because the card bounced. The customer who could use your product, wanted to pay, and could not is indistinguishable in your funnel from someone who lost interest. You optimize the onboarding flow and never touch the actual leak, which is the payment instrument.
Crypto removes the issuer from the path. A stablecoin transfer does not ask a bank in another country for authorization — the customer signs a transaction from a wallet they control, on a chain that settles the same way for everyone. There is no acquirer coverage map, no cross-border decline code, no domestic-scheme delay. The question stops being "will this customer's card work here" and becomes "does this customer hold a stablecoin" — and in the markets where cards fail most, the answer is increasingly yes.
- Cross-border card declines are an issuer risk decision, not your fraud — and you rarely see them.
- A self-serve funnel hides the leak: a bounced card looks like a lost lead.
- Stablecoin settlement has no acquirer coverage map and no cross-border decline path.
- In the markets where cards work worst, stablecoin wallets are most common.
How halfin fits: stablecoins in, fiat-anchored prices, the same invoice
You do not run a second pricing model for international customers. You bill them the way you bill everyone — one fiat-anchored invoice. Send the amount in your home currency, say USD 49, and halfin quotes the equivalent in the stablecoins and native assets you accept and locks that rate at activation. A customer in any country is shown a concrete token amount and a payment window; the price they settle is the price you booked.
Because the invoice is anchored in fiat rather than denominated in a token, the customer's location and their choice of asset never touch your accounting. Your pricing page stays in dollars or euros, your revenue reporting stays in fiat, and a USDC payment from one market reconciles against the same USD figure as a USDT payment from another. The fiat anchor is what makes "global" cheap to operate — you are not maintaining a price book per currency, per region, or per asset.
The customer pays through hosted checkout or a checkout you render yourself, halfin applies the per-chain confirmation threshold and credits the deposit reorg-aware, and your server receives an HMAC-signed webhook the moment the invoice resolves. Verify the signature, then grant access. That confirmation event — not the customer's country, not the asset, not a card authorization — is the single signal that a global payment landed.
| Where cards struggle | What the customer does instead | What halfin gives you |
|---|---|---|
| Issuer declines a cross-border charge | Pays USDC or USDT from their own wallet | No issuer in the path — the transfer either confirms on-chain or it does not |
| Card scheme is slow or absent in the market | Settles on a chain that finalizes the same way everywhere | Per-chain confirmation, then a signed webhook — no domestic-scheme delay |
| Local currency adds FX and a price book per region | Pays a dollar-denominated stablecoin | One fiat-anchored invoice; you reconcile against the figure you billed |
| High decline rate quietly caps a region | Completes payment with a wallet they already hold | The leak closes at the instrument, not in the onboarding funnel |
Why stablecoins, and which ones the global path leans on
For a global SaaS bill the asset of choice is almost always a dollar-denominated stablecoin, not a volatile native coin. The reason is the same one that makes fiat-anchored invoicing work: the number on the invoice and the number that lands on-chain are the same kind of number — dollars — so a customer in any market is paying a price they understand, and you are reconciling against the figure you booked.
USDC suits USD-native and EVM-first customers — US businesses, on-chain teams, treasuries that already hold a dollar stablecoin. halfin accepts it on Ethereum as an ERC-20 token, on Base for low-cost settlement, and on Solana. USDT carries the broadest reach in the markets where cross-border cards fail most often; halfin accepts it on Tron (TRC-20), on Ethereum (ERC-20), and on Solana. Offering both, across those networks, means a customer almost anywhere can settle on a chain and an asset they already use rather than acquiring something new just to pay you.
A single invoice can present the networks and assets you support, and the customer settles in whichever they hold — the fiat anchor is unchanged regardless of their choice. You are not building a separate flow per asset or per chain; you are letting one invoice draw from the real supported surface.
- Bill in fiat, settle in a dollar stablecoin — the customer pays a price they understand.
- USDC on Ethereum, Base, and Solana for USD-native and EVM-first payers.
- USDT on Tron, Ethereum, and Solana for the broadest cross-border reach.
- One invoice presents the supported assets; the fiat anchor never changes with the choice.
Creating a global invoice is the same call you already make
There is no separate international endpoint and no per-region configuration to learn. A customer in another country is billed with the same fiat-anchored invoice as a customer down the street: send the fiat amount and currency, let halfin quote and lock the payable asset amount, and present the result. The customer's geography lives entirely in their wallet and their network choice, not in your integration.
The request below creates one invoice against the public REST API. Pass an idempotency key so a retried request — a flaky connection from a distant region is exactly when retries happen — returns the existing invoice instead of issuing a duplicate. The amount is a string, because monetary values are strings end to end, and the currency is your fiat anchor. The exact response shape lives in the docs and the @halfin/sdk-merchant types.
# Same invoice for a customer in any market.
# amount_fiat + fiat_currency anchor the price in dollars;
# the customer settles in USDC, USDT, or a native asset.
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",
"deferred": true,
"description": "Pro plan — acct_8821",
"idempotency_key": "signup-acct_8821"
}'
# halfin locks the rate at activation and returns an invoice you
# present via hosted checkout or render yourself. Track it through
# the signed invoice.paid webhook. See docs.thehalfin.com for the schema.What changes operationally when payments go global
Selling worldwide on crypto changes a few habits, and it is worth naming them so the move is deliberate rather than surprising. The biggest one is that access follows confirmation, not a charge attempt. There is no optimistic "card authorized, provision now and capture later" — you provision when the invoice.paid webhook arrives, after the chain's confirmation threshold. For most SaaS that delay is seconds to minutes and entirely acceptable; design the onboarding copy to set the expectation rather than implying instant access.
The second is that a non-payment is an expired invoice, not a decline. A customer who starts checkout and never sends funds leaves an expired invoice behind, which your dunning logic treats as a non-conversion: a reminder, a grace period, a nudge to try a different asset. Because the issuer is out of the path, the failure modes you inherit from cards — random declines, soft declines you retry, chargebacks weeks later — are not the failure modes here.
The third is collection: payments arrive across several stablecoins and chains, and you will not always want to hold the exact mix you receive. Balance conversion lets you consolidate into a target asset — for example a single stablecoin — without moving funds off-platform, so a globally diverse inflow does not turn into a treasury-management chore. Compliance does not relax because the customer is abroad: KYB onboarding and AML awareness are process, not a status, and any market-specific obligations your software business carries remain yours.
- Provision on the verified invoice.paid webhook, not on an authorization — set the expectation in onboarding.
- A non-payment is an expired invoice handed to dunning, not a card decline to retry.
- No issuer in the path means no chargebacks and no soft-decline retry loops.
- Balance conversion consolidates a diverse global inflow into the asset you want to hold.
Where this leads next
Global acceptance is the recurring SaaS path with the geography taken out of the payment instrument — so the place to start is the same invoicing primitive, called once per cycle, anchored in fiat with the rate locked at activation. From there, decide on a checkout surface and wire the webhook before anything that grants access, because that signed confirmation is the only authoritative proof a cross-border payment landed.
If most of your international demand is dollar-stablecoin, the USDC asset page covers the networks and the reconciliation story in detail. The SaaS hub ties the full recurring-billing lifecycle together — usage-based plans, developer payouts, and treasury — for when global acceptance is one part of a larger billing setup rather than the whole of it.