Crypto payouts for gambling affiliates and iGaming partner programs

Gambling affiliates send traffic to whoever pays on time, in full, and without a frozen bank account in the middle of the month. That last part is where iGaming programs get stuck: the rails that work for a SaaS affiliate program — bank wires, cards, PayPal — routinely refuse gambling-related flows, so crypto isn't a nice-to-have, it's the only rail that reaches the whole publisher base. The first version of crypto payouts is a person sending transfers one wallet at a time from a revenue-share export, which works until the run dies on row 240 and nobody can say who was already paid. halfin replaces that with idempotent batch payouts: stage the whole publisher list, give each line its own idempotency key so a retry never double-pays, approve once, and reconcile against a per-recipient result that ties back to a real transaction hash. The vetting and the decision to pay stay inside your program — halfin executes the approved instruction and leaves the audit trail.

Why iGaming affiliate payouts break the normal rails

A gambling-affiliate program looks like any other affiliate network on paper — publishers earn commission for the players they send, the program pays on a cycle — but the payment side behaves completely differently. Banks, card networks, and consumer wallets classify gambling-adjacent flows as high-risk and decline, hold, or freeze them, often after the relationship is already running. A US-style ACH or a SEPA transfer that's routine for a software affiliate becomes a support ticket and a closed account for a betting affiliate, and the publisher feels it as a late or missing payout.

So crypto is the default rail in iGaming affiliate marketing, not the experimental one. Publishers expect to be paid in USDT, USDC, or a native asset to a wallet they control, and they have low tolerance for friction: a partner who pays reliably in stablecoin keeps the traffic, and one who pays late or partially loses it to a competitor by the next cycle. The operational problem is that the program's affiliate platform already knows exactly what each publisher earned — it's the moving of money out that stays a manual, end-of-cycle, error-prone event.

halfin is the payment layer under that flow. It does not become your affiliate tracker, your anti-fraud engine, or your commission ledger — those stay the systems of record for which players and conversions are valid and what each publisher is owed. halfin takes the approved payout instruction your platform produces, executes it on-chain across the assets your publishers actually hold, and returns signed status your finance and partner-ops teams can reconcile. The niche is high-risk; the payment mechanics are made boring on purpose.

Idempotent batch payouts so a publisher is never paid twice

The expensive failure in any large payout run is the silent double-pay, and it's worse in iGaming because the volumes are high and the funds are final the moment they're on-chain. A send times out and returns ambiguously — the transaction may already have landed even though your script never saw the confirmation — and a naive retry pushes a second payment. You discover it when treasury reconciliation comes up short or a publisher quietly keeps the overpayment, and there's no clawback.

halfin removes the ambiguity. Every payout carries a caller-supplied idempotency key, and re-submitting the same key returns the original payout instead of creating a new one. Derive the key deterministically from your own records — typically the affiliate account id joined with the payout period — so the same publisher in the same cycle always maps to the same key, and a retry from the top of the batch converges on exactly one payout per recipient. That single property is what turns a brittle hand-rolled loop into a payout run you can safely interrupt and re-run.

Partial failure is treated as the normal case, not an exception. Some lines get rejected up front — a wallet address a publisher pasted wrong, an amount below a chain's dust threshold, a currency the destination can't receive — and those are reported per-line so the rest of the batch still goes through. You fix the rejected rows and re-submit the whole file; the lines that already succeeded are no-ops, and only the corrected ones execute. No single bad row blocks two hundred good ones, and there's no spreadsheet column tracking 'paid / not paid' by hand.

• Each payout line carries currency, amount (as a string), destination wallet, and its own idempotency_key.
• Re-submitting a key returns the original payout — timeout retries and worker restarts never double-pay.
• Rejected lines are reported per-recipient; the rest of the batch still settles.
• Re-run the whole revenue-share file after a crash; succeeded lines are no-ops, only the gaps execute.

Approval stays human even when staging is automated

iGaming payout runs are large and recurring, which is exactly the situation where you want the programmatic path and the human control point kept separate. halfin does that by default: a payout doesn't move funds the instant the API is called. Each one enters a pending-approval state and is released from the dashboard, so the run your platform POSTs is a proposal, not an irreversible action.

That separation matters for a gambling program more than most. Your integration can stage thousands of publisher payouts unattended from the revenue-share export, but whoever owns the treasury still signs off before anything leaves the balance — a treasurer reviews the totals and any rejected lines, then releases the run. The high-throughput staging and the single accountable approval are different actions performed by different actors, which is the control posture a high-risk, high-volume payout flow needs.

Pay each publisher in the asset and chain they actually use

A gambling-affiliate base doesn't share one preferred rail. A publisher running traffic in one region settles in USDT on Tron because the network fee is predictable at volume; another wants USDC on Ethereum or Base for their own accounting; a high-frequency partner prefers Solana for fast, low-cost settlement. Forcing everyone onto one network means rejected payments and addresses that can't receive what you sent. halfin lets each payout line pick its own currency and network, so a single run spans all of them.

Settlement is reorg-aware and uses per-chain confirmation thresholds, so a payout reported complete has actually settled to the depth that chain requires — not merely been broadcast. That matters most at the tail of a large iGaming batch, where you want each publisher's status to mean 'done', not 'submitted and hopefully fine'. Every line resolves to a transaction hash your partner-ops team can hand to a publisher who asks where their commission is.

Submitting a revenue-share run from code

There is no separate batch endpoint to learn: a gambling-affiliate payout run is a fan-out over the single-payout API, where the idempotency key on each line makes the whole loop safe to interrupt and re-run. Take the approved revenue-share or CPA export your affiliate platform already produces, derive a deterministic key per publisher and period, and submit each line. If the process dies mid-run, you re-run the entire file — already-created payouts come back unchanged, and only the missing ones are created.

Wrapping the loop in a retry is correct here rather than dangerous: because each call is idempotent, the second pass converges on exactly one payout per publisher. Amounts go on the wire as strings, never as floating-point numbers, so a value is transported exactly with no rounding drift between your books and the chain. The full payout request and response schema is at docs.thehalfin.com.

# Fan out an iGaming revenue-share run; each line is idempotent.
# revshare.csv columns: account,currency,amount,destination
while IFS=, read -r account currency amount destination; do
  curl -sS -X POST https://api.thehalfin.com/api/v1/payouts \
    -H "Content-Type: application/json" \
    -H "X-API-Key: $HALFIN_API_KEY" \
    -d "{
      \"currency\": \"$currency\",
      \"amount\": \"$amount\",
      \"destination\": \"$destination\",
      \"idempotency_key\": \"revshare-2026-06-$account\"
    }"
done < revshare.csv
# Re-run the same file after a crash: keys collide, no publisher is paid twice.
# Then a treasurer reviews and releases the batch from the dashboard.

Auditable settlement, and where compliance stays yours

Gambling-affiliate programs accumulate payment risk because the old process leaves no trustworthy record — a spreadsheet of 'paid' checkboxes isn't an audit trail, and a bank statement weeks later doesn't tie a line back to a specific publisher and revenue-share period. halfin's settlement leaves a concrete trail: every payout maps to an idempotency key from your ledger, a dashboard record, an HMAC-signed webhook, and an on-chain transaction hash. When a publisher disputes a payment or finance closes the period, the chain of evidence is concrete rather than reconstructed from memory. Point a webhook at your platform so settlement state arrives independently of any API response you might have missed, and verify the signature before you mark a payout complete.

Compliance is handled as a process at onboarding, and it stays the program's responsibility. The program may be licensed to operate in its own jurisdiction; halfin is payment infrastructure, not a license, and nothing here is legal advice. halfin supports KYB onboarding when you become a merchant, applies AML awareness to the payment rail, and treats travel-rule considerations as a process to understand — none of which is a certification halfin holds or grants. The program keeps publisher identity, the decision about which counterparties it will pay, wallet and sanctions screening before funds move, and the regulatory obligations of its own market. Hand halfin the approved instruction, and use the dashboard records and signed webhooks as the settlement evidence.

• Keep your affiliate tracker as the system of record for valid conversions and amounts owed.
• Screen publisher wallets and counterparties before paying out — that decision stays yours.
• Tie every payout to an idempotency key, a dashboard record, a signed webhook, and a transaction hash.
• Treat KYB, AML awareness, and travel-rule as process — never as a license or certification claim.