A payout run looks like a single job — "pay everyone on the list" — until you notice that the list is three different lists wearing one name. Freelancers want predictability. Marketplace sellers want their sales added up correctly. Creators and affiliates want small amounts to arrive without the fee eating them. The rail underneath is the same for all three: one funded wallet, one run, one record. What changes is the design around it. This guide takes the three recipient types in turn, then the controls every run needs regardless of who's on the list.
One list in, a few transactions out. In CPAY, Multisend takes a list of wallet addresses and amounts for a single token and pays them in batches: one transaction for every 200 addresses, so a list of 1,000 recipients becomes five transactions. Fees are estimated before anything is sent, and the final step is confirmed with 2FA. Everything below is about what to do before and around that button.
Recipient 1 — Freelancers & contractors: Few people, fixed amounts, every month
A contractor payout is the easy case on paper and the unforgiving one in practice, because every payment is personal and every mistake is noticed. The list barely changes from month to month, the amounts are agreed in advance, and the people on it are expecting a specific sum on a specific day.
What helps is treating the recipient list as a maintained asset, not a spreadsheet you rebuild monthly. Keep one verified record per payee — address, network, token — and change it only through a documented step (the payee confirms the new address on a channel you already trust). Send a small test payment to any new payee before the first real one. And price the payout in a USD-pegged stablecoin: the contractor knows exactly what they're owed in dollar terms, and you aren't explaining a rate move in a payment query.
One boundary worth stating plainly: who counts as a contractor, what you must report, and what you must withhold depends on jurisdiction. A faster rail changes none of those obligations — it only makes the payout itself quicker. Agree the reporting side with your advisers before the first run.
Recipient 2 — Marketplace sellers: Many people, variable amounts, add them up first
Sellers on a marketplace don't have a salary; they have a stream of sales, refunds and commissions that nets out to a payout. The shape of the problem is different: more recipients, amounts that change every run, and the same seller appearing on several lines because they made several sales.
That last point is where the tooling matters. Multisend gives you a say in what happens to duplicate addresses: keep the first line only, merge balances into a single sum per address, or keep every duplicate. For seller payouts, merging is usually what you mean — one transfer per seller per run, summing their lines — while keeping duplicates is the right answer only when you want every sale to be a separate on-chain record. Choose it on purpose; the default is not a policy.
The remaining design question is timing. Payouts to sellers are usually released after a hold period that covers returns and disputes — a business rule you set, not something the rail decides. Settling fast doesn't mean paying early; it means that once your rules say "release", the money moves in minutes rather than the following week.
A payout is the last step of a long chain of decisions. Make the last step the most boring one. (A rule of thumb, not a quote.)
Recipient 3 — Creators & affiliates: Many people, small amounts, protect the margin
Creators, affiliates and community contributors are paid in small sums, to many people, often across many countries. Two problems dominate. The first is economics: a per-payment fee that's invisible on a $2,000 invoice can swallow a $6 commission. Batching is the answer — per the fee schedule in the documentation, the system fee is a base amount per transaction plus a small increment per address, so the cost per payee falls as the list grows — and so is a minimum payout threshold: commissions accrue until they reach an amount that's worth sending, then go out in the next run.
The second problem is onboarding. A creator needs somewhere to receive the funds, and "send me your wallet address" is where a lot of non-crypto-native recipients stall. If that's your audience, offering a built-in wallet at sign-up removes the step — which is the case for wallet-as-a-service, covered in the WaaS API guide. Either way, collect the address through an authenticated flow and have the recipient confirm it, rather than accepting one pasted into a support email.
Side by side: Three lists, three settings
Before any run: Preflight: catch the list, not the transaction
Once a transfer is confirmed on-chain, it's final. Every control that matters therefore lives before the send button, and most of them are cheap, boring checks on the list itself: every address well-formed, every amount positive, duplicates handled on purpose, and the total matching what your payables ledger says you owe. A short script that runs before anyone opens the dashboard does most of that work:
The two numbers at the bottom do real work. Recipients catches a list that quietly doubled because of a bad join. Total is the figure the approver checks against the ledger — and a mismatch at this stage costs a few minutes, where a mismatch after the send costs a lot more.
The run: Estimate, approve, confirm
With a clean list, the run itself follows the order the dashboard shows. Paste the list in the Addresses with Amounts block, or upload it as a CSV — Show examples in the dashboard demonstrates the exact format. Pick your duplicate policy. Click Next, and the system estimates the system fee, prepares the approval, and estimates the miner fee. You'll see the recipient list, the number of addresses, the number of transactions needed, and your wallet's token balance and balance of the main network currency — the latter matters, because that's what pays the network fee.
Two details save a bad afternoon. The approval step sets an allowance — the maximum amount the contract may send — and that amount persists, so an approval for 100 USDT stays at 100 even if you then estimate 99. And a Multisend run is for one token from one wallet: recipients you want to pay in a different token or on a different network belong in a separate run. If payouts are part of an application rather than a person at a dashboard, the same four steps are available over the API, and the two steps that move funds accept an Idempotency-Key header so a retried request can't pay twice.
Two people, two keys. For anything beyond a pilot, the person who prepares the list shouldn't be the only person who can approve it. Even a small team can split the roles: one prepares and runs preflight, another checks the total against the ledger and holds the 2FA. It adds a few minutes and removes the most common way a payout goes wrong — one person, one tired afternoon, one wrong paste.
After the run: Reconcile, then close the loop
A run returns identifiers for the transactions it sent — one per batch. Store them against the run in your own records, and match every recipient line to a confirmed transfer. Anything unmatched is a short list to investigate that same day. Then tell the recipients: a payout notification with the amount, token, network and transaction reference turns "has it arrived?" from a support ticket into a lookup.
Last, keep the compliance side in view. Screening recipients, handling sanctions risk and meeting the Travel Rule where it applies are programme obligations that sit with you; faster payouts make a documented process more important, not less. The KYC & AML guide lays out who owns which part.
FAQ — Common follow-ups
How many recipients can one run handle?
The system sends one transaction for every 200 addresses, so larger lists are simply split into more transactions — 1,000 recipients means five. Fees scale with the number of addresses and transactions, and they're estimated before you confirm.
Do recipients need a CPAY account?
No — a payout goes to a wallet address, so recipients need a wallet that can receive the token on the network you're using. Whether that's their own wallet or one you provide at sign-up is a product decision; the run itself only needs addresses and amounts.
Can I pay in USDT and USDC in the same run?
A run is for one token from one wallet, so split the list by token and run each separately. The same applies to recipients on different networks. Preflight is the natural place to split the list.
What happens if one address is wrong?
A well-formed but wrong address looks like any other and the transfer is final, which is why the controls sit before the send: format validation, a test payment for new payees, payee-confirmed addresses and an approver who checks the total. Malformed addresses are caught by preflight; wrong ones can only be caught by process.
How do I keep small payouts economical?
Combine two levers: batch payments into fewer, larger runs so fees are shared across many recipients, and set a minimum threshold so tiny balances roll over to the next run instead of being sent at a loss. Merge-balances handling keeps each recipient to one transfer per run.
Ready to run your first payout? The Multisend documentation covers the dashboard flow, and the API reference covers the same four steps over the API. The CPAY team is a call away.
Sources: CPAY Documentation — Multisend, Using API for multisend.
