Crypto Batch Payouts for Contractors and Affiliates

Aurpay’s REST API covers payin and payout. It does not include a spreadsheet uploader, a payroll product, or conversion into local currency. Your recipient receives tokens at an address they control, and everything between “here is a list of 300 people” and “300 confirmed transactions” is a batch runner you build. This page is that build.

Two decisions determine whether it works. The first is address integrity: an on-chain transfer to a mistyped address is final. No chargeback, no recall, no support ticket that fixes it. The second is chain selection, and it costs more than most operators expect. We measured the four rails we support on 31 August 2026: a stablecoin transfer cost about $0.02 on ERC-20 and $2.11 to $4.36 on TRC-20, the top of that range applying whenever the destination has never held that token, which for affiliate and contractor payouts is most addresses. Across 300 commissions that is roughly $6 against roughly $1,290 a month, paid by you rather than your customer.

We sell a crypto payment gateway, so weigh the closing recommendation accordingly. The measurements are reproducible from public chain data, and the operational sections apply whichever provider you send through.

What “crypto payout” means here, and what it does not

Outbound payments through a non-custodial gateway move tokens from an address you control to one your recipient controls. On our rails a payout settles in BTC, Bitcoin over Lightning, ETH, USDT on ERC-20 or TRC-20, USDC on ERC-20 or TRC-20, or DAI on ERC-20. That is four chains: Ethereum, Tron, Bitcoin mainnet, and Bitcoin Lightning. Nothing outside that list, because tokens sent on an unsupported network are usually unrecoverable. And a payout is not a bank transfer: your contractor in Buenos Aires receives USDT and arranges their own off-ramp, so if the obligation is denominated in local currency you carry the conversion risk between fixing the amount and their cash-out. Put that in the agreement rather than discover it in a dispute.

Scenario triage: four payout types, four different problems

“Pay people in crypto” collapses four workflows with different shapes. The controls that matter for a $40 affiliate commission are not the ones that matter for a $60,000 supplier invoice.

Payout type	Typical size and cadence	Collect before first payment	Main operational risk	Sensible default rail
Independent contractors and freelancers	$500–$8,000, twice monthly or monthly	Tax form, verified address, agreement stating the payment asset	Tax classification; mis-typed addresses	USDC or USDT on ERC-20; the network fee is negligible at this size
Affiliate and referral commissions	$20–$500, monthly, hundreds of recipients	Verified address, sanctions screening, a program payout minimum	Network fee as a share of a small payment; duplicate accounts	ERC-20 stablecoins, or one batched Bitcoin transaction
Supplier and vendor invoices	$2,000–$250,000, on invoice terms	Invoice, entity verification, address confirmed out of band	Payment redirection — a changed address on a real vendor record	Any supported stablecoin; dual approval matters more than fees
Cross-border staff compensation	Recurring, fixed schedule	Local legal advice first	Many jurisdictions require wages in legal tender	Not a payout problem until counsel has cleared it

The last row is deliberately unhelpful. Wages paid in crypto raise employment-law questions a payment gateway cannot answer, and we do not sell a payroll product. The other three are where a batch payout runner is straightforwardly the right tool.

The engineering: what actually breaks in production

The address book is the system of record, not a text field

Store three fields per recipient, never one: the address, the asset, and the network it belongs to. Ask at onboarding rather than at first withdrawal, when someone is in a hurry and pastes whatever is on their clipboard. A recipient will happily hand you a Tron address when you asked for an Ethereum one.

Validate on save, before the address reaches a batch. Ethereum addresses are 42 characters beginning 0x and carry an EIP-55 mixed-case checksum you should verify rather than merely accept; an all-lowercase address gives no protection and should force a re-type. Tron addresses are 34 characters beginning with T and use base58check, which catches single-character errors; Bitcoin bech32 addresses beginning bc1 catch up to four.

Test transfers, and why their cost depends on the chain

Before the first real payment to any address, send the smallest practical amount and make the recipient confirm receipt in your system. Timestamp the confirmation, mark the address verified, and re-run the loop on any address change. That rule alone closes most payment-redirection fraud.

Note what the policy costs. On ERC-20 a verification transfer is about two cents, so verifying 300 affiliates costs $6. On TRC-20 it is $2.11 to $4.36 per address, because a first transfer to an address that has never held that token burns roughly twice the energy of one to an existing holder, so the same exercise costs $633 to $1,308. Operators who default to Tron on the standing “Tron is cheap” advice are the ones who quietly drop verification when that bill arrives.

Idempotency: generate the key before you call anything

The failure to design for is a request that times out after the transaction was broadcast: your runner does not know whether it sent money, and if it retries there is no way to take the second payment back. Derive the key from a stable business fact, not a random value created at attempt time. A period plus recipient plus asset, such as 2026-09-affiliate-14827-usdc, survives retries, restarts, and an operator re-running the file because they were unsure the first run worked. A random identifier generated inside the retry loop is worse than no key: it makes duplicate sends look like distinct payments. Enforce it with a unique database constraint, so duplicates are rejected by the datastore, not by application logic someone can refactor away.

Persist the provider reference and transaction hash against that key as soon as you receive them. On any ambiguous response — timeout, connection reset, 5xx — re-read state by your own key and send only if nothing was sent. The callback side of this loop is the same event handling that reconciles inbound payments; see our guide to payment API webhooks and reconciliation.

Batches are not atomic, so stop treating them as one object

A batch of 300 payouts is 300 independent state machines sharing a submission time. Give each row its own status — queued, submitted, confirmed, failed — and store the hash on the row, not the batch. Recovery means re-running only failed rows, plus rows still in submitted with no hash after a timeout you define, typically 15 minutes on Ethereum. Never re-run the source file.

Bitcoin is the exception: it is output-based, so 300 payouts can be one transaction. Cheaper, but one bad output means rebuilding before broadcast.

Nonce, energy, and why parallelism hurts

On Ethereum, transactions from one sending address are ordered by a sequential nonce. Fire ten sends concurrently from one address and you get gaps, transactions stuck behind a missing nonce, and replacements you did not intend. Either serialize sends through a single worker that assigns nonces itself, or shard across addresses that each serialize. Sharding scales; serializing is sufficient at 300 payouts.

Tron has no nonce but has a resource budget: a TRC-20 transfer consumes energy, and a sender without staked resources burns TRX instead. That produces the two-tier cost above, and it means the sending account needs a monitored TRX balance, not just a token balance. The same is true of ETH on Ethereum. The most common cause of a failed batch is a sender holding plenty of stablecoin and no native asset for the fee. Alert on it before the run, not during.

Approvals, dual control, and the cooling period

Separate two permissions that are usually merged: editing a payout address, and approving a batch. One person should not hold both. The standard fraud is a compromised email account that changes a supplier’s address a week before an invoice is due, and separation of duties is what catches it.

Add a cooling period: a newly added or edited address cannot receive above a defined threshold for 24 hours. Set it near your median commission, so routine affiliate payouts pass while a $50,000 payment to a two-hour-old address stops for a human. Above a higher threshold, require a second approver and confirmation through a channel you already had on file.

Receipts

For every row, store the transaction hash, block height, network, asset, token amount, USD value at broadcast time, and the business reference. The hash is your recipient’s proof of payment, and the USD value is what your tax reporting is built on. Capture it at send time, because reconstructing it later from historical prices is painful and disputable.

What a batch actually costs, by rail

These are our own measurements from 31 August 2026, taken from public chain endpoints rather than from another article. Ethereum was sampled across 1,024 consecutive blocks; Tron at the fixed 100 sun per unit of energy, roughly 65,000 energy to an existing token holder and 130,000 to a first-time address, TRX around $0.3257; Bitcoin at Blockstream’s estimates of 1.072 and 0.40 sat/vB, BTC at $77,992.

Rail	Cost per payout	300 payouts	Fee on a $50 commission
USDT or USDC, ERC-20	~$0.02	~$6	0.04%
USDT or USDC, TRC-20, address already holds the token	$2.11–$2.15	~$639	4.3%
USDT or USDC, TRC-20, first-time address	$4.24–$4.36	~$1,290	8.6%
Bitcoin on-chain, one transaction with 300 outputs	~$0.03 per output	~$7.80 next block; ~$2.90 at a six-block target	0.05%
Bitcoin Lightning	Under $0.01 on a $200 payment	Under $3	Under 0.02%

The Bitcoin batch line is derived rather than directly measured: each extra output adds roughly 31 vB, so 300 outputs plus an input and overhead is about 9,380 vB, which at the measured rates and BTC price gives the figures above.

Three conclusions follow, narrower than “use the cheap chain”. For high-volume small payouts ERC-20 is currently the cheap rail and Tron the expensive one — the reverse of the received wisdom, because Ethereum base fees have stayed low while Tron’s energy price is fixed in TRX terms. Once payments exceed roughly $500 the network fee stops mattering on any rail, so optimise for the wallet your recipient uses. And Lightning is cheapest on paper but you cannot push to a static address: the recipient must present an invoice per payment, which suits on-demand withdrawals and scheduled batches poorly.

Re-check monthly — these move with ETH, TRX, and BTC prices, not with anything you control. The same figures underpin our comparison of crypto payment gateway fees, where the network fee sits alongside the gateway percentage.

Compliance: what you owe, and to whom

None of this is tax or legal advice, and the rules differ by jurisdiction and by how you classify the person you pay. Below are the obligations most US-based payers hit first, with sources verified 7 September 2026.

Paying US contractors. Paying in crypto does not exempt you from information reporting. The IRS treats the fair market value in US dollars at the date of receipt as the income amount, which is the number your payout record should already hold, per the IRS FAQ on virtual currency transactions. Nonemployee compensation goes on Form 1099-NEC, and the threshold recently changed: the current IRS instructions state that for tax years beginning after 2025 the minimum reporting threshold rose to $2,000, with inflation adjustment from 2027. Most articles on this subject still say $600. Confirm the figure for the year you file rather than trusting either us or them.

Paying non-US recipients. Collect the withholding certificate before the first payment, not at year end. A non-US individual who is the beneficial owner gives you Form W-8BEN; entities use a different form in the same series. Build the step into the onboarding flow that captures the wallet address — chasing it from someone already paid rarely works.

Sanctions screening. Screen the recipient’s name and the address. Since 2018 OFAC has published digital currency addresses as identifying information on the Specially Designated Nationals list, available through the OFAC Sanctions List Service, and the obligation applies whether a payment is denominated in dollars or tokens. Screen at address-add time and again before each batch, since the list changes between runs. An irreversible transfer leaves no remediation afterwards.

Records. Keep the verification evidence, approval trail, withholding certificate, and per-row receipt together, in the same chart of accounts as your inbound payments. Our note on the 1099-DA gap for non-custodial merchants covers why that burden sits with you rather than arriving pre-filled.

Pre-payout checklist

1. Every address has an asset and a network stored with it, and passed checksum validation on save.
2. Every address has a completed test transfer with recipient confirmation on file.
3. No address was added or edited within the cooling period above your threshold.
4. Names and addresses were screened against today’s sanctions list, not last month’s.
5. Tax forms are on file for every recipient who needs one, and the batch was approved by someone who cannot edit addresses.
6. Every row carries an idempotency key of period, recipient, and asset, with a unique constraint enforcing it.
7. The sending address holds enough native asset — ETH or TRX — for the whole batch plus margin, not just tokens.
8. Network cost for the chosen rail is calculated and acceptable at this batch size, sends are serialized per sending address, and the retry path re-reads state by key before sending.

Where Aurpay fits, stated plainly

Our REST API covers payin and payout across the four chains above, with testnet and mainnet environments and a Postman collection. One caveat before you scope the work: the public reference documents the inbound flow in depth while the payout side sits at the overview level, so ask us for the payout reference before you estimate. That is a documentation gap rather than a capability gap.

And to restate the limits: no bulk CSV upload, no payroll product, no conversion to local currency, no chain beyond the four above. A recipient who wants USDT on another network cannot be paid through us, and a specialist payout platform is then the better fit.

What you get is a non-custodial gateway at 0.8% per transaction, funds settling into a wallet you control, no contracts or banking details required, and an API you can drive in both directions. If you pay partners out of revenue you also collect in crypto, that symmetry is the advantage: one address book, one reconciliation, no bank in between. Start with our crypto payment API guide for the inbound half, our breakdown of crypto affiliate commission rates if you are still designing the commissions that feed these payouts, and our gateway fee comparison to weigh the 0.8% against the alternatives.