Crypto payments for streamers and creator platforms

A creator platform has two payment problems at once. Money comes in from viewers — tips, donations, subscriptions — and money goes out to creators, in long lists, on a schedule, to wallets all over the world. halfin gives you both sides: hosted checkout for the incoming payment, and idempotent mass payouts for the outgoing run, with the same dashboard and the same signed webhooks tying them together.

The problem: paying creators is a list, not a transaction

When a platform pays one vendor, it is a transaction. When a platform pays its creators, it is a list — hundreds or thousands of rows, each a different person, a different amount, often a different country and a different wallet. Bank rails make that list expensive and slow: cross-border fees per row, multi-day settlement, and a payout that fails halfway and leaves you guessing which creators got paid and which did not.

The failure mode that hurts most is ambiguity. A batch job times out, your script retries, and now you cannot tell whether a creator was paid once, twice, or not at all. For a platform whose entire relationship with creators is built on paying them correctly and on time, that ambiguity is the thing you most need to design out.

halfin makes the payout run idempotent line by line. You submit each creator's payout with its own key derived from your run identifier; if a line is retried — by your code, a proxy, or a flaky connection — halfin recognises the key and does not pay that creator twice. Re-running the whole list after a crash converges on exactly one payout per creator, and you read each payout's state back rather than infer it from logs.

How halfin fits the creator-economy money flow

Map your platform onto five stages and a named halfin primitive sits at each one. Money comes in through checkout or a deposit address; the chain confirms it; you pay creators out in a batch; you convert held balances when a creator wants a different asset than they earned in; and your finance team reconciles the whole thing from signed events.

On the way in, viewers pay through hosted checkout — a page halfin renders and watches, so you never build wallet code for a tip jar — or through a static deposit address you hand a creator once for recurring support. Crediting is reorg-aware with per-chain confirmation thresholds, so a payment your platform treats as received has actually settled under that chain's rules, not just been broadcast.

On the way out, single payouts cover the one-off — a manual correction, a one-time bonus, a creator who needs paying off-cycle — and mass payouts cover the weekly or monthly run across your whole roster. Balance conversion lets a platform that collects in one asset pay creators in the one they prefer, and rebalance its own treasury between assets without manual desk work. Every state change emits an HMAC-signed webhook; verify the signature, then update your ledger.

• Incoming tips and donations → hosted checkout or static deposit addresses.
• Confirmation → reorg-aware crediting with per-chain thresholds.
• Creator payout run → idempotent mass payouts (single payouts for one-offs).
• Asset mismatch / treasury → balance conversion, automatic or manual.
• Reconciliation → HMAC-signed webhooks your finance team can trust.

The flows creator platforms build first

These are the recurring jobs a streaming or creator-economy product runs, described in plain operational terms. Each maps onto the primitives above; none requires you to write per-chain wallet code or a confirmation watcher.

Creator payouts are the core run: a scheduled batch that pays your roster their earned balance. You build the payee list in your own system — that is where creator identity, earnings, and wallet validation live — and hand halfin an idempotent batch to execute. The batch is the unit you retry, audit, and reconcile against, so a payment run is something you can re-submit safely rather than a fire-and-forget script.

Subscription monetization and donation checkout are the income side. A viewer subscribing to a creator, or dropping a one-off donation, pays through hosted checkout — the same page handles the QR, the address, the supported networks, and the live status. A donation payment gateway for your platform is, in practice, an invoice plus a checkout URL plus a webhook that tells your backend the tip landed and which creator it belongs to.

Global creator payments and instant creator withdrawals are about reach and timing. Because settlement is on-chain, paying a creator in São Paulo costs the same operationally as paying one in Berlin, and a creator who hits 'withdraw' is paid out as a payout you execute on-chain rather than a bank file that clears next week. Platform revenue share is the same machinery pointed at a split: when income needs to fan out — platform cut, creator cut, sometimes a collaborator cut — that is a mass payout describing the split, with the batch as your record of who got what.

Creator-economy compliance is the boundary that runs through all of it, covered in its own section below: halfin processes the payment rail, your platform owns who your creators are.

Why idempotent mass payouts are the load-bearing piece

Everything else on a creator platform can be rebuilt; a double-paid or silently-missed creator payout damages trust you do not get back. That is why the payout primitive, not the checkout, is the centre of gravity for this use case.

A mass payout in halfin is a run you submit over the payout API, where each line carries its own idempotency key derived from your own run identifier — not N untracked sends you reconcile by hand. If your process dies mid-run and retries, the keys collide and no creator is paid twice. If a single destination is bad, that payout is visible as a failure you can re-issue without disturbing the lines that already paid.

Concretely, a creator-platform payout run looks like the request below: one call per creator, each with an idempotency key tied to your run. Read each payout back, and your reconciliation is the payouts' own state — not a guess assembled from logs.

# A payout run fans out over the payout API: one call per creator,
# each carrying its own idempotency key derived from your run id.
# Re-running the whole loop after a crash is safe — colliding keys
# mean nobody is paid twice.
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\": \"creator-run-2026-06-$creator\"
    }"
done < roster.csv

# Read each payout back to reconcile per-line state, and confirm
# settlement from the payout.completed webhook your server receives.
# See docs.thehalfin.com for the full response schema.

Take tips, donations, and subscriptions without building a wallet

The income side is deliberately small to integrate. You create an invoice with a fiat-anchored amount and the networks you accept, and halfin returns a hosted checkout URL. Send the viewer there and the page owns the rest — the QR code, the deposit address, the network choice, and the live payment status from waiting through confirmed. You write no wallet-connect code and run no confirmation watcher.

Treat the webhook as the source of truth, not the redirect. A viewer can pay a creator and close the tab before the success redirect fires; the signed webhook still arrives, and that is what should credit the creator and update your ledger. Verify the signature first, every time, before taking any business action.

# Create a fiat-anchored invoice for the tip, donation, or subscription;
# the response carries a hosted checkout URL you send the viewer to.
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": "5.00",
    "fiat_currency": "USD",
    "deferred": true,
    "description": "Tip for creator-8841",
    "idempotency_key": "tip-creator-8841-2026-06-10"
  }'

# The viewer pays on the returned checkout URL; your server learns the
# tip landed — and which creator it belongs to — from the HMAC-signed
# webhook. Verify the signature first. See docs.thehalfin.com for the
# full response schema.

Compliance is a boundary, not a feature halfin sells you

Creator platforms carry real obligations — knowing who their creators are, screening for sanctions and wallet risk, and keeping records they can produce later. halfin's role is narrower and it is important to state it plainly: halfin is payment infrastructure that processes the rail. It does not become your compliance program and it does not certify your platform.

halfin onboards merchants through KYB and is built with AML awareness; the travel rule is a real concept your team should understand as your volumes grow. None of that is a license halfin holds or a status it confers on you. The practical division of labour is the same one any serious platform already runs internally:

Keep creator identity, payout eligibility, and wallet validation inside your own stack — that is your system of record for who gets paid. Hand halfin the approved payment instruction; it processes the on-chain rail and returns signed status your finance and trust-and-safety teams can reconcile against. For higher-risk or regulated niches, treat halfin as the payment layer and take legal and licensing questions to your own counsel — this page does not give regulatory advice.

creator-economy compliance, in short, is a flow your platform owns end to end, with halfin processing the money movement underneath it.

• Your platform is the source of record for creator identity and eligibility.
• Screen wallets and counterparties before paying or accepting.
• Keep invoice, payout, and webhook records attached to creator IDs.
• halfin processes the rail and returns signed, auditable status.