Global creator payments without bank rails

Your roster does not live in one country. A creator in São Paulo, one in Lagos, one in Manila, one in Berlin — and the moment you pay them through bank rails, every one of those locations becomes a different problem: a different correspondent chain, a different cut-off time, a different per-wire fee, a different reason a payment bounces back three days later. On-chain, the geography stops mattering. A stablecoin payout to a wallet in Manila is the same operation as one to a wallet in Berlin: same call, same asset, same settlement, no bank between you and the creator. This page is about that reach — why paying creators globally on-chain removes the rails, the FX exposure, and the waiting that bank payouts impose.

Bank rails make geography the problem; on-chain doesn't

When you pay a creator through the banking system, you are not really paying the creator — you are handing money to your bank and asking it to find a path to theirs. For a domestic payee that path is short. For an international one it runs through correspondent banks, each taking a fee and a day, each able to reject the payment for a reason you only learn about after it has bounced. Multiply that by a roster spread across dozens of countries and your payout run is no longer one job; it is dozens of country-specific jobs with dozens of failure modes.

The costs are not only money. A wire to one country clears next-day; to another it sits over a weekend and a local holiday. One corridor needs an IBAN, another a SWIFT/BIC, another a local clearing code you have to collect and validate per creator. A payment that fails returns days later, often with the fee already deducted, and now you owe that creator a correction on top of the original amount.

An on-chain payout collapses that. There is one rail — the chain — and it does not care which country the wallet's owner sits in. You send a stablecoin to an address; it settles by that chain's rules; the creator has the funds. Paying São Paulo costs the same operationally as paying Berlin, because there is no correspondent path to route and no local banking cut-off to wait for. The unit of work is identical for every creator on the list, which is exactly what makes a global roster tractable.

Stablecoins are the unit your global roster actually wants

Cross-border reach is only useful if the thing you send holds its value between the moment you send it and the moment the creator spends it. That is why the asset for global creator payments is usually a stablecoin, not a volatile native coin: a creator paid in USDT or USDC receives a dollar-denominated amount that does not move against them while it confirms or while they decide what to do with it.

The choice of network matters as much as the choice of asset, because the creator pays the cost of receiving on a high-fee chain. The same USDT exists on Tron, on Ethereum, and on Solana; USDC on Ethereum, Base, and Solana. Paying a small creator balance as ERC-20 USDT on Ethereum can mean a network fee that is a meaningful fraction of the payout, whereas the same amount as TRC-20 USDT on Tron or SPL USDC on Solana arrives with negligible cost. For a roster of many small payouts, picking a low-fee rail is not an optimisation — it is the difference between a creator receiving their earnings and receiving their earnings minus a chunk of gas.

halfin pays only on rails with a real on-chain gate, so the matrix below is the actual surface you choose from, not an aspirational list. You decide, per creator or per region, which asset and network to send on; halfin processes that send and reports settlement.

• Pay a dollar-denominated amount that doesn't drift while it confirms — stablecoins, not volatile coins.
• Choose the network per region so the creator isn't eaten by gas: Tron or Solana for low-fee stablecoin payouts.
• USDT on Tron / Ethereum / Solana; USDC on Ethereum / Base / Solana — the rails with a real gate.
• Native coins are available when a creator asks for one specifically.

Settlement is paced by the chain, not by a banking calendar

The slowest part of an international bank payout is rarely the money — it is the calendar. Cut-off times, weekends, and local holidays decide when a wire actually moves, and a payment initiated Friday afternoon for a creator abroad can be a Tuesday-arrival in practice. On-chain, settlement is paced by block production and confirmation depth, which run continuously and ignore the working week entirely.

halfin marks a payout settled when it has held on-chain to that network's confirmation threshold — crediting is reorg-aware, so the status you reconcile against reflects a transaction that actually stuck, not one that was merely broadcast. Different chains finalise on different timescales, and that is a real lever: a creator who wants their money quickly is better paid on a fast-finalising rail than on one with deep, slow confirmations. You are choosing settlement timing as a property of the network, not waiting on a counterparty bank's internal schedule.

What you do not get — and should not promise a creator — is an instant, irreversible transfer the second you click send. A payout is final when the chain's confirmations back it and halfin's signed completion event says so. That is still days faster than a cross-border wire for most rails, and crucially it is final on a schedule you can predict from the network, rather than one you discover when the funds show up.

Same call for every country — reach is built into the rail

A global payout run is mechanically the same as a domestic one: a mass payout is a fan-out over the single-payout API, one call per creator, each line carrying its currency, amount, destination wallet, and a per-line idempotency key derived from your run. The idempotency and retry-safety of that loop is covered in depth on the creator-payouts page; the point here is narrower — there is no separate code path, fee table, or correspondent setup for the international lines. A creator in another country is just another row whose destination happens to be a wallet rather than a foreign IBAN.

Because the destination is a wallet address, the per-country friction of bank payouts disappears from your integration: no IBAN-versus-routing-number branching, no per-corridor field validation, no collecting a SWIFT/BIC. Your stack still owns who the creator is, what they earned, and whether they are eligible and screened — that is your system of record. halfin's job starts when you hand it an approved line, and that line looks identical whether the creator is local or on the other side of the world.

Where a creator wants paying in a different asset than your platform collects, balance conversion sits between the held balance and the payout, automatic or manual — so a platform that takes income in one asset can still pay a creator in the stablecoin they prefer, and rebalance its own treasury without a manual desk. The reach, in other words, is not something you build per region; it is a property of sending on a chain instead of through banks.

# A cross-border payout run is the same fan-out as a domestic one:
# one call per creator over the single-payout API. The destination is
# a wallet, so a creator abroad is just another row — no IBAN/SWIFT,
# no correspondent bank, no per-country branch in your code.
while IFS=, read -r creator currency amount destination; do
  curl -sS -X POST https://api.thehalfin.com/api/v1/payouts \
    -H "X-API-Key: $HALFIN_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{
      \"currency\": \"$currency\",
      \"amount\": \"$amount\",
      \"destination\": \"$destination\",
      \"idempotency_key\": \"global-run-2026-06-$creator\"
    }"
done < roster.csv

# currency is the crypto code (e.g. USDT), amount is a string, and
# destination is the creator's wallet on the network you chose for
# their region. Confirm settlement from the payout.completed webhook —
# verify the HMAC signature first. See docs.thehalfin.com for the schema.

FX exposure is a choice you make, not a tax the rails impose

Bank rails fold a currency conversion into every cross-border payment whether you want one or not, at a rate and a spread you do not control and often cannot see until the statement arrives. Paying creators in a dollar stablecoin removes that hidden conversion from the rail: the creator receives a dollar-denominated amount, and any move into their local currency happens on their side, at their choosing, through whatever venue they prefer — not silently inside your payout.

That keeps your own books clean. A platform that prices and accounts in USD can pay a global roster in a USD stablecoin and reconcile every payout back to the dollar figure it intended to send, with no per-country FX line to unwind at month-end. Where conversion genuinely is needed — you hold one asset and a creator wants another — it is an explicit balance-conversion step you can see and audit, not an invisible markup buried in a wire.

None of this is financial advice, and it does not change a creator's tax position in their own country — that remains theirs and their advisor's to handle. What it changes is where the FX decision lives: with you and the creator, deliberately, rather than with a chain of banks taking a spread you never agreed to.

Reconcile the global run the same way you'd reconcile one payment

A run that spans thirty countries should not be thirty reconciliations. Because each payout is its own object with its own state, you read a global run back exactly the way you read a single payment: query the payout, see whether it is pending, completed, or failed, and confirm settlement from the signed webhook rather than from your application logs. A creator in another country is not a special case in your finance process — just another payout id with a signed completion event attached.

Treat the webhook as the source of truth. When a payout settles, halfin emits a payout.completed event; verify its HMAC signature before you mark the creator paid and update your ledger. A settlement is final when that signed event arrives and the chain's confirmations back it — the same rule for the creator in Lagos as for the one in your home market. Your finance and trust-and-safety teams get one uniform record: which run, which creator, which destination, which signed completion, regardless of geography.

• Every payout is its own object — read its state back instead of parsing logs.
• payout.completed is the source of truth; verify the HMAC signature before crediting.
• Final means signed event plus on-chain confirmations — identical rule in every country.
• One reconciliation shape for the whole global run, not one per corridor.