Accepting Payments Is Half the Job: How to Run Crypto Mass Payouts
Taking a deposit is the easy part. The customer opens a checkout, pays from their own wallet, and your system gets a webhook. Mass payouts are where an operation starts to creak: hundreds of players, traders or partners waiting for their money at the same time, a spreadsheet of addresses, someone in finance copying and pasting until late on a Friday, and a support queue filling up with “where is my withdrawal?”
This guide is for operators who already accept crypto, or plan to, and now have to send money back out at volume. It covers why payouts fail before payments do, what a manual payout run really costs, how mass payouts work when they run through the same API as payments, and the controls that keep a batch of a thousand transfers from turning into a thousand tickets.
Why payouts break before payments do
A payment and a payout look like mirror images. In practice they carry very different risk.
When a customer pays you, they start the transaction, they choose the coin, and they sign it with their own wallet. If they make a mistake, the problem is mostly theirs. When you pay someone, every transfer is your decision and your liability. A wrong address, a wrong network or a duplicate send costs you money, and on-chain transfers can’t be pulled back once they confirm.
Payouts also carry your reputation in a way payments don’t. A player forgives a slow deposit page. They don’t forgive a withdrawal that sits in “pending” for three days. Regulators pay attention too. The UK Gambling Commission banned reverse withdrawals for all online gambling from 31 October 2021 (Bird & Bird summary), so players can no longer be nudged into cancelling a pending withdrawal and gambling the money instead.
Partners are just as sensitive. In iGaming affiliate programmes, monthly payouts on NET15 terms are the most common setup, and programmes that reconcile by hand “routinely need a week and pay late” in heavy months, according to Track360’s 2026 payment terms benchmarks. The same report puts a bank or SWIFT transfer at $15–40 per payment. For a programme paying a few hundred affiliates, that is a noticeable line in the budget before anyone has even checked the amounts.
What a manual payout run looks like
Most teams don’t plan a manual process. It grows on its own. Ten withdrawals a day are easy to send from a wallet app. At two hundred a day, the same routine turns into a part-time job, and at two thousand it becomes a department.
A typical manual run goes like this:
- Someone exports approved withdrawals from the back office into a spreadsheet.
- Finance checks whether the wallet holds enough of each coin on each network.
- Each address is copied into a wallet, the amount is typed in, and the transfer is signed.
- The transaction hash is pasted back into the spreadsheet or the CRM.
- Support answers the people whose payout went missing, arrived on the wrong network or never left.
Every step has its own way of failing.
| Step | What goes wrong | What it costs |
|---|---|---|
| Export and approval | Old data, duplicates, a withdrawal approved twice | Double payment, often unrecoverable |
| Balance check | Not enough USDT on the right network | The run stops halfway, the rest wait a day |
| Copying addresses | Wrong address, lookalike address, wrong network | Lost funds, a support case, sometimes a dispute |
| Recording hashes | Missing or mismatched records | Hours of reconciliation at month end |
| Support | Users asking for status with no live data | Tickets, angry messages, lost customers |
Copying addresses deserves special attention. In December 2025 a crypto trader lost almost $50 million in USDT to an address poisoning attack: the attacker seeded the victim’s transaction history with an address that matched the real one’s first and last characters, and the victim copied it from the history for the main transfer (The Block). A finance assistant pasting 300 addresses on a Friday evening is exactly the target this attack is built for.
The time cost is easy to underestimate. Traditional accounts payable gives a useful comparison. Ardent Partners’ 2025 benchmarks put the average cost of processing one invoice at $9.40, against $2.78 for the best performers, with exception rates of 22% versus 9% (via WEX). The difference between those two groups is mostly automation. Crypto payouts follow the same logic: the cost sits in human handling and in exceptions, far more than in the transfer itself.
Who needs mass payouts
Any business that pays many people regularly ends up needing mass payouts. The most common cases:
- iGaming operators paying out player withdrawals around the clock, often with weekend peaks.
- Forex brokers and prop trading firms sending client withdrawals and trader profit splits.
- Affiliate and partner programmes paying commissions on a monthly or weekly cycle.
- Marketplaces and creator platforms settling with sellers, freelancers and authors in different countries.
- Companies paying contractors and remote staff, where crypto payroll replaces slow international bank transfers.
What these businesses have in common is a large number of recipients, many of them abroad, and an expectation of speed. A bank wire to forty countries is slow and expensive. A stablecoin transfer costs the same and takes about as long whether the recipient is in Lisbon or Lagos.
Payments and payouts in one API
Many businesses start with one provider for incoming payments and handle outgoing money separately: an exchange account, a hot wallet, sometimes a second processor. It works until volume grows. Then the money has to move between systems before it can be paid out, and reconciliation means matching records from two or three sources.
Running both directions through one API removes most of that friction. With Speend, the same merchant balance that receives customer payments funds your payouts. There is one set of API credentials, one webhook format, one dashboard and one AML policy for money coming in and going out. Funds from deposits don’t need to be withdrawn to an exchange and sent back to a payout wallet, so there is no extra transfer to pay for or wait on.
For developers the payout call is short. You send POST https://api.speend.io/payout/create with five required fields:
order_id, your own unique ID for the payoutcurrency, for example USDTnetwork, for example TRON or SOLamount, at least the equivalent of 7 USDaddress, the recipient’s address on that network
{
"order_id": 100245,
"currency": "USDT",
"network": "TRON",
"amount": 250,
"address": "TXk...recipient"
}The response returns the payout’s uuid, its current status and an is_final flag. The full reference is in the Payouts API documentation.
How a payout moves through Speend
Each payout goes through a fixed set of statuses. Knowing them is what lets your system show a player or partner an honest answer instead of “processing”.
| Status | What it means | Final |
|---|---|---|
| REQUESTED | The request is accepted | No |
| AWAITING_CONFIRMATION | The amount is above your approval limit and waits for a person to confirm it in the dashboard | No |
| ON_QUEUE | Approved and queued for sending | No |
| ON_QUEUE_CONVERSION | Currency conversion before sending, when the payout needs it | No |
| ON_NETWORK_QUEUE | The transfer is being broadcast and confirmed on-chain | No |
| SUCCESS | Sent and confirmed on the blockchain | Yes |
| CANCELED | Cancelled | Yes |
| FAILED | An error during processing or sending | Yes |
| AML_FAILED | Rejected by the AML check of the recipient address | Yes |
You don’t need to poll for every change. Speend sends a webhook when a payout enters the queue and when it reaches a final state: process, success, cancel, fail or aml_fail. Each webhook carries a sign field, which your server checks with the separate payout key before trusting the status. The webhook URL is set in the dashboard, so make sure it’s filled in before the first live run.
A mass payout run in 7 steps
There is no magic in mass payouts through an API. A batch is a list of individual payouts, each sent as its own request. What makes it safe is the discipline around those requests. Here is a process that holds up at thousands of transfers a day.
1. Build the list from your own ledger
Take approved withdrawals or commissions from your back office, not from a spreadsheet someone edited. The source of truth for who gets paid and how much should be the same system that recorded the balance.
2. Give every payout a unique order_id
This is the most important line in the integration. Speend treats order_id as an idempotency key: if a request repeats an existing order_id, the API returns the original payout and does not create a second one. A network timeout followed by a retry then can’t turn into a double payment. Use the ID of the withdrawal in your own database and never reuse it.
3. Validate addresses and networks before sending
Check the address format for the selected network and confirm the network matches the coin. Speend rejects invalid and blacklisted addresses at creation, but it’s cheaper to catch mistakes on your side, where you can ask the user to correct them. Store each recipient’s address in their profile and pay to that, never to an address copied from a transaction history. Our guide on USDT on TRC-20 vs ERC-20 helps when choosing default networks, and this explainer covers what happens when funds go to the wrong one.
4. Check the balance covers the whole batch
If the balance is short, the API answers “insufficient balance” and the payout isn’t created. Compare the batch total with your balance before you start, and keep a buffer for network fees. A run that stops in the middle is worse than one that starts an hour later.
5. Send the requests and record the uuid
Send payouts at a steady pace, store the returned uuid next to your order_id, and mark each withdrawal as “sent to processor” in your system. From this moment the user can see an honest status.
6. Approve large payouts by hand
Payouts above your limit stop at AWAITING_CONFIRMATION until someone confirms them in the dashboard. This gives you a second pair of eyes on the transfers that matter most, while small, routine mass payouts go through without waiting.
7. Reconcile with webhooks and close the loop
Update each withdrawal when its webhook arrives, and notify the recipient when the status is final. For edge cases, ask the API directly with payout/getStatus. One example: if a payout is cancelled while it waits for confirmation, no cancel webhook is sent, so a scheduled status check catches it.
Controls that keep mass payouts safe
Automating mass payouts removes manual errors. It also means a wrong rule can repeat a thousand times in a minute, so a few controls are worth setting up before volume grows.
Screen the people you pay as well as the people who pay you. According to Chainalysis, illicit addresses received at least $154 billion in 2025, and stablecoins accounted for 84% of that volume, even though illicit activity stayed below 1% of all on-chain transactions (The Block). Sending funds to a sanctioned or high-risk address can create a compliance problem for you even if the recipient is your own customer. Speend checks recipient addresses as part of the payout flow, and a payout that fails that check ends with AML_FAILED. More on how this works in our explainers on KYT and AML in crypto.
Keep payout credentials separate. Speend signs payout webhooks with a dedicated payout key, separate from the main key used for payments. Give access to the payout key to as few people and services as possible, and rotate it if someone leaves the team.
Set approval limits that match your risk. A casino might let payouts under $1,000 go straight through and send larger ones to a manager. A broker might set the line lower for new clients. Agree on the limit with your Speend manager so it fits your flow.
Pick default networks for mass payouts on purpose. For USDT, networks differ in fees, speed and how widely they’re supported by your users’ wallets. Offering two or three networks covers most recipients. Offering ten multiplies the chance of a wrong-network mistake.
What changes in numbers
An illustrative example. An online casino processes 2,000 crypto withdrawals a week. Done by hand, each payout takes around three minutes once you count checking, copying, signing and recording the hash. That is about 100 hours a week, or two and a half full-time people doing nothing else, plus the errors that come with tired eyes.
With mass payouts through the API, the same 2,000 transfers run from the back office automatically. People handle only the exceptions: large amounts waiting for approval, failed address checks and the occasional recipient who entered the wrong network. If 3% of payouts need attention, that is 60 cases a week instead of 2,000.
The affiliate side looks similar. A programme paying 150 partners by SWIFT at $15–40 per transfer spends $2,250–6,000 a month on bank fees alone. Paying the same partners in USDT replaces that with a network fee per transfer, which on low-cost networks is usually a small fraction of a bank wire, and the money arrives the same day instead of after several business days.
Common mistakes with mass payouts
- Using a new random
order_idon every retry. This switches off idempotency and opens the door to double payments. - Trusting a webhook without checking its
sign. Anyone who learns your callback URL could otherwise mark payouts as paid. - Leaving the webhook URL empty in the dashboard. Webhooks sent with no URL set are lost, and your system never learns the final status.
- Retrying a
FAILEDpayout blindly. Check the reason first; a fresh attempt needs a neworder_idonly after you know the first one didn’t go through. - Funding the payout balance at the last minute. Keep enough on the balance for the next batch.
FAQ
Is there a separate bulk endpoint for mass payouts?
No. Each payout is its own API request. Your system loops through the list and sends them one by one, and the order_id keeps every request safe to retry.
What is the minimum payout amount?
The equivalent of 7 USD per payout. The same minimum applies to every transfer in mass payouts.
What happens if the same payout is sent twice?
If both requests use the same order_id, Speend returns the original payout and does not create a second one.
Can a payout be stopped?
A payout waiting for confirmation in the dashboard can be cancelled. Once it’s on the network, it can’t be reversed, like any on-chain transfer.
What if the recipient’s address fails the AML check?
The payout ends with the AML_FAILED status and the funds aren’t sent. Ask the recipient for a different address and contact your Speend manager if you need details about the case.
How long does a payout take?
It depends on the queue and the network. A payout is complete once the blockchain confirms it, and confirmation speed differs between networks. The exact status of every payout is always available through webhooks and payout/getStatus.
Can I pay out in a coin I don’t hold on the balance?
When a payout needs a conversion, it goes through a separate ON_QUEUE_CONVERSION step before sending. Ask your manager which pairs are available for your account.
Can I still send payouts by hand?
Yes. Payouts can be created manually in the dashboard as well as through the API. Manual sends are handy for one-off transfers, while mass payouts are better left to the API.
Where to start
Count how much your current payout process takes: payouts per week, minutes per payout, bank fees, and the share of support tickets that start with “where is my money”. Then look at what changes when mass payouts run through the same integration you already use to accept payments.
If you’d like to see how that would work for your business, contact the Speend team. A dedicated manager will help you set up payouts, approval limits and webhooks, and run the first test batch with you.
