Affiliate network payouts for iGaming operators

An iGaming affiliate program lives or dies on whether partners get paid the agreed amount, on time, every cycle. The networks that send a casino or sportsbook its players watch settlement closely — a missed run or a duplicate payment is the fastest way to lose the source of your traffic. The hard part is never the headline figure; it is moving money to hundreds of partner wallets, in the asset each one expects, without paying anyone twice when a run is interrupted. halfin mass payouts give an operator that exact discipline: submit the whole affiliate settlement as one batch, give every partner line its own idempotency key, approve once, and reconcile against a clean per-recipient result.

Why affiliate settlement is the run that has to be exact

Player deposits and withdrawals are high-volume and individually small. Affiliate settlement is the opposite: a smaller number of payees, larger amounts, and a counterparty that runs its own books and will notice a discrepancy down to the line. A casino that underpays a network by one partner's commission, or pays a CPA line twice because the run was retried, has not made a clerical error — it has handed the network a reason to redirect traffic to a competitor next month. The money moved is the relationship.

The mechanics make this worse than a single payout. An affiliate run is a list assembled from your tracking data — revenue share, CPA, and hybrid deals, each resolved to an amount and a destination wallet for a given period. Building that list from a spreadsheet and firing transfers one at a time is the failure mode every finance team knows: the script dies partway through, nobody is sure which partners already received funds, and re-running the file risks double-paying everyone who came before the crash. Under the time pressure of payout day, the safe-looking choice is often the one that double-pays.

Affiliate networks also expect to be paid in the asset they nominate, not the one most convenient for the operator. A network settling its own sub-affiliates in USDT on Tron wants USDT on Tron; one running US-facing accounting may need USDC on Ethereum. A settlement model that forces every partner onto one chain produces rejected payments and addresses that cannot receive what you sent — which lands back on your desk as a support thread, not a clean confirmation.

One batch, one key per partner, safe to retry

halfin models an affiliate settlement as a set of single payouts you submit together and reason about as a unit. Each partner line carries a currency, an amount as a string, a destination address, and its own idempotency key. The key is the whole point: derive it deterministically from your own records — the network or affiliate account id joined with the settlement period — so re-submitting the same run reproduces the same keys, and halfin matches each one to the payout it already created instead of issuing a second.

That makes the run safe to retry from the top, every time. If a worker restarts, an RPC connection drops, or someone re-runs the file because they were not sure it finished, the partners already paid become no-ops and only the missing lines execute. The ambiguous timeout — where a request may have landed on-chain even though your client never saw the response — stops being a double-pay risk, because a repeated key returns the original payout rather than creating a fresh one.

Partial failure is treated as the normal case. A malformed address, an amount below a chain's dust threshold, or a currency a destination cannot receive is rejected per line, and the rest of the batch still goes through. You fix the rejected rows from your tracking data and re-submit the whole file; the lines that already succeeded do nothing, and only the corrected ones run. No single bad partner row blocks a settlement to two hundred good ones.

What an affiliate payout line carries

Every partner in a settlement is described by the same small set of fields — the same shape halfin uses for any payout, so an affiliate run and a player withdrawal share one model. Amounts are always strings, never floating-point numbers, so a commission figure is transported exactly with no rounding drift between your tracking ledger and the chain. Pick the currency and network per line, so each network is paid in the asset it actually nominated.

Submitting an affiliate run from your tracking data

There is no separate affiliate or batch endpoint to learn: a settlement run is a fan-out over the single-payout API, where idempotency keys make the loop safe to interrupt and re-run. Resolve commissions for the period from your tracking system into a list of partner, currency, amount, and destination, then submit each line with a key derived from your own records. If the process dies mid-run, you re-run the entire loop — already-created payouts come back unchanged, and only the missing ones are created.

Payouts do not move funds the instant you call the API. Each one enters a pending-approval state and is released from the dashboard, so the run you POST is a proposal, not an irreversible action. Your integration can stage an entire affiliate settlement unattended from your tracking data, and a treasurer still signs it off before anything leaves the balance. The full request and response schema lives at docs.thehalfin.com; the call below shows the per-line shape and the deterministic key.

# Settle an affiliate network: fan out one payout per partner line.
# The key is deterministic, so re-running after a crash pays no one twice.
while IFS=, read -r affiliate 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\": \"affiliate-2026-06-$affiliate\"
    }"
done < affiliate-settlement.csv
# Re-run the same file after an interruption: keys collide, nobody is paid twice.

Settle each network in the asset it nominated

Affiliate networks do not share a settlement preference, and forcing every partner onto one chain means rejected payments and addresses that cannot receive what you sent. One network may settle its own sub-affiliates in USDT on Tron; another may need USDC on Ethereum or Base for its accounting; a smaller partner might take native SOL or BTC. Because each payout line picks its own currency and network, a single settlement run can span all of them, and each partner is paid the way its contract specifies.

Settlement is reorg-aware and uses per-chain confirmation thresholds, so a partner line reported as complete has actually settled to the depth that chain requires — not merely been broadcast. That matters most at the tail of a large run, where you want each partner's status to mean done rather than submitted and hopefully fine. When you collect deposits in one asset but owe affiliates in another, balance conversion handles the treasury side so you are not running an external desk to fund payout day.

• Stablecoins: USDT on TRC-20 / ERC-20 / Solana; USDC on ERC-20 / Solana / Base.
• Native assets: BTC, ETH, SOL, XRP, plus EVM L2 and BSC native tokens.
• Per-line network choice — settle Tron, Ethereum, Base, and Solana partners in one run.
• Balance conversion when you collect in one asset and settle affiliates in another.
• Reorg-aware crediting with per-chain confirmation thresholds before a line reports complete.

An auditable record finance and the network can both close on

Affiliate disputes are settled by records, not by recollection. Every payout in a run leaves a per-recipient result — accepted, rejected, or completed — that your finance team reconciles against the commissions your tracking system resolved for the period. The dashboard gives operators a human view of every payout in the run, while the payout.completed webhook is what your automated treasury logic trusts: verify its HMAC signature, then mark the partner line settled in your own books.

Because the idempotency key is derived from your own ledger, the record ties back to a specific partner and period rather than to an opaque transaction id. When a network queries a line — "we are short on the May run for account 4471" — you have a deterministic key, an on-chain payout, and a signed completion event that resolve the question without a forensic spreadsheet exercise. Reconciliation becomes matching signed events to partner-and-period rows, instead of carrying uncertainty between your tracking data and what actually left the balance.

Responsibility stays cleanly divided. Your platform owns the affiliate program: the deals, the tracking, the commission calculation, the payee list, and the wallet validation for each partner. halfin receives the approved payout instructions, runs the rails, keeps the payment record, and returns signed status. halfin is payment infrastructure, not the operator's affiliate manager — and never a gambling license or a compliance approval for the operation behind the run.