# What tool pays many recipients in one transaction? Six kinds of tools pay many recipients at once. Only the onchain ones do it in one transaction; the rest turn one instruction into many transfers. --- Six kinds of tools pay many recipients at once: a bank bulk payment file, a payroll tool, a mass-payout platform, a card processor's payout feature, an onchain batch transfer tool and an onchain payment router. The criterion that separates them is whether the run is truly one transaction, in which every recipient is paid together or nobody is, or one instruction that produces many separate transfers, each of which can succeed, fail or arrive late on its own. Only the two onchain families are one transaction in the strict sense. The four others accept one file, one approval or one click and then send as many individual payments as there are recipients. That is not a weakness: for a payout to several hundred people, a run in which one bad account number does not stop the other payments is usually what you want. A second distinction matters as much as the first. Five of the six families pay out money you already hold, in your bank account, in a platform balance or in a wallet. The sixth, a router, pays nobody from a pot: it takes one incoming payment and sends it straight to its recipients. The two jobs look alike and call for different tools.
300 paymentsleave the bank when one bulk file lists 300 recipients: one instruction, not one transaction
$4,250comes back to the payer when 4 of 300 payments fail in the worked example, while 296 people are paid
15 dealsis what a router capped at 20 recipients would need to cover a 300-person payout

Figures from the worked example used throughout: an illustrative payout of $240,000 to 300 recipients.

## Which kinds of tools pay many recipients at once? Six families of tools pay many recipients from a single action by the payer: a bank bulk or batch payment file, a payroll tool, a mass-payout platform, a card processor's payout feature, an onchain batch transfer tool and an onchain payment router. They differ in what moves the money, who holds it beforehand and what the recipient must have in order to be paid. A bank bulk or batch payment file is a list of transfers that you upload to your business banking service or send through your accounting software. You approve the file once, your account is debited, and the bank sends one credit transfer per line through the national or regional clearing system. A payroll tool does the same thing for one specific population, the people who work for you. It calculates each amount, handles the withholding and filings that employment requires, and then pays each person, generally by sending a batch file through a bank on your behalf. A mass-payout platform is built for paying people who are not on your payroll: marketplace sellers, creators, affiliates, survey participants, members of a programme. You fund a balance with the platform, upload or send the list, and the platform pays each person by the method that person chose, such as a local bank transfer, a card or a wallet. A card processor's payout feature belongs to the service that collects card payments for a business. The proceeds of those payments sit in a balance with the processor, and the payout feature sends that balance onward, to the business's own bank account or, in the marketplace version, to the sellers and providers connected to the platform's account. An onchain batch transfer tool is a smart contract that takes a list of wallet addresses and amounts and performs every transfer inside one blockchain transaction. An onchain payment router is also a smart contract, with a different trigger: it acts when a payment comes in, and divides that payment among the recipients set beforehand. ## Is it really one transaction, or one instruction that produces many transfers? A bank bulk file, a payroll run, a mass-payout run and a processor payout are one instruction that produces many transfers; an onchain batch transfer and an onchain router payment are one transaction. The difference is practical, not a matter of vocabulary: in a single transaction all the payments share one fate, and in a set of transfers each payment has its own. The table below applies the same three questions to each family. | Family | What "one" means | Paid at the same moment? | If one payment fails | | --- | --- | --- | --- | | Bank bulk or batch payment file | One file and one approval; one transfer per recipient | No: each credit posts when the receiving bank processes it | The others go through; the failed one is returned | | Payroll tool | One pay run; one deposit per person | Same pay date, not the same instant | The others go through; the failed deposit is reissued | | Mass-payout platform | One upload or one request; one payout per person | No: timing depends on each payout method | The others go through; the amount returns to the platform balance | | Card processor's payout feature | One schedule or one request per connected account | No: each payout follows its own schedule | The others go through; the amount returns to the processor balance | | Onchain batch transfer tool | One transaction containing every transfer | Yes: all in the same block | Usually the whole transaction reverts and nobody is paid | | Onchain payment router | One incoming payment, divided in one transaction | Yes: all in the same block | The whole transaction reverts and the payer keeps the money | Nacha, which writes the rules of the ACH network in the United States, describes the bank mechanism plainly: the payer's bank combines the payment instructions it receives into a file and sends that file to an ACH Operator, which sorts the entries so that each one reaches the right receiving bank. The file is a means of transport. What the recipients receive are individual credits. On a blockchain the unit is different. A transaction either executes completely or does not execute at all, and a contract can perform hundreds of transfers inside that one transaction. The Ethereum documentation states the consequence of a transaction that runs out of gas partway through: every change is reverted, and the fee for the work performed is still paid. ## Do all the recipients get paid at the same moment? All the recipients are paid at the same moment only with the onchain families, where every transfer is part of one transaction recorded in one block. With a bank file, a payroll run, a mass-payout platform or a processor payout, the recipients are paid on the same day at best, and sometimes across several days, because each transfer travels through its own receiving institution. Timing in a bank scheme is set by the scheme, not by the file. According to Nacha, an ACH credit can settle the same day, the next banking day or in two banking days, and Nacha estimates that about 80% of ACH payments settle in one banking day or less. Two people on the same file who bank at different institutions can therefore see their money at different hours, and in some cases on different days. Instant schemes narrow the gap without making the batch a single transaction. The European Payments Council states that a SEPA Instant Credit Transfer makes the funds available in less than ten seconds, on every calendar day of the year. A bank that offers instant transfers in bulk still executes one instant transfer per recipient: the 300 payments of a run arrive within moments of each other, and each one remains a separate payment that can be rejected on its own. A mass-payout platform has the widest spread, because it lets each recipient choose how to be paid. A payout to a wallet balance inside the platform can be immediate, one to a card fast, one to a foreign bank account slower. Same run, different arrival times. ## What happens when one payment in the batch fails? When one payment fails in a bank file, a payroll run or a platform payout, the other payments go through and the failed amount comes back to the payer to be corrected and sent again. When one transfer fails in an onchain batch built as a single all-or-nothing transaction, every transfer is undone and nobody is paid until the list is fixed. Take the worked example of this article, an illustrative payout of $240,000 to 300 recipients: 200 people at $500, 80 at $1,250 and 20 at $2,000. Suppose four entries carry a closed or mistyped account: two at $500, one at $1,250 and one at $2,000. In a bank file, 296 people are paid, $235,750 is delivered and $4,250 returns to the payer, days later in some schemes, each return carrying its reason. Your work is to contact four people, correct four lines and send a second, small file. The same four errors in an onchain batch behave differently, and the direction depends on the kind of error. A mistyped wallet address that happens to be valid is not rejected at all: the tokens arrive at the wrong address and the transfer is final. A transfer that cannot execute, for instance to an address the token contract refuses or to a contract that rejects incoming funds, makes the whole transaction revert in a tool built as all-or-nothing: $0 is delivered, the network fee is spent, and the 296 valid recipients wait for the corrected run. Some batch tools are built the other way and skip a failing transfer, which brings back the partial result of a bank file. Check which design you are using before the first run. ## How many recipients can one run hold? The maximum number of recipients comes from different sources in each family: the bank's or platform's own file limits for bank files, payroll and payouts, the block gas limit for an onchain batch transfer, and the product's own cap for a payment router. Several hundred recipients is routine for the first four families, possible in a few transactions for an onchain batch tool and outside the purpose of a router. Bank schemes are built for volume. A bulk file can carry hundreds or thousands of entries, and the limits a business meets in practice are set by its bank: a maximum file size, a daily value limit on the account, an approval rule above a threshold. Schemes also cap the value of a single payment in some services. Nacha's rules also set a ceiling on the amount of a single Same Day ACH payment, which Nacha has raised over time, so check the current figure with your bank. The European Payments Council states that the SEPA Instant scheme no longer sets a maximum amount at scheme level and that each payment service provider may set its own. Ask your bank for its limits; do not assume the scheme's figures apply to your account. Payroll tools and mass-payout platforms scale with the plan you buy. The practical constraint is not the size of the run but onboarding: every recipient must exist in the system with verified payment details, and often with tax information, before the first payout. A first run to 300 people is mostly 300 onboardings. Onchain, the ceiling is physical. Every transfer consumes gas, and a block can hold only so much. The Ethereum documentation puts a simple transfer of the native currency at 21,000 units of gas, so 300 of them need at least 6,300,000 units before the contract's own overhead, and token transfers such as stablecoins cost more per transfer. Batch tools therefore cap the number of recipients per transaction and split a long list. With a tool that takes, say, 100 recipients per transaction (an illustrative cap), the 300-person payout becomes three transactions. Each one is atomic. The run as a whole is not. A payment router caps recipients for a different reason. It is designed around a deal, with a handful of parties who each agreed a share, not around a list. A router that accepts at most 20 recipients per deal would need 15 separate deals, and 15 incoming payments, to reach 300 people. It does not suit a 300-person payout, and stretching it to fit removes what makes it useful. ## Who holds the money before it goes out? In five of the six families the money sits somewhere before the payout: in the payer's bank account for a bank file, with the provider for most payroll tools, in a platform balance for a mass-payout platform or a card processor, and in the payer's wallet for an onchain batch transfer. With a payment router nobody holds it, because the payment being divided is the one arriving. | Family | What the payer must hold first | Cross-border reach | Record produced | | --- | --- | --- | --- | | Bank bulk or batch payment file | The full amount in the payer's own bank account | Domestic or regional scheme; other countries by individual international transfers | Bank statement and a file report with returns | | Payroll tool | The full amount, collected by the provider ahead of pay day | The countries the provider supports for employment | Payslips, a payroll register and tax filings | | Mass-payout platform | A prefunded balance held with the platform | The countries and payout methods the platform supports | Payout report per recipient; often tax forms | | Card processor's payout feature | Nothing in advance: the balance comes from card payments already collected | The countries where the processor can pay out | Payout report tied to the payments collected | | Onchain batch transfer tool | The full amount in tokens in the payer's wallet, plus the network fee | Any address on the network; converting to local currency is each recipient's task | One transaction hash listing every transfer | | Onchain payment router | Nothing: the incoming payment is the money | Any address on the network; the payer must be able to pay onchain | One transaction showing the payment and every share | A bank file keeps the money in your own account until the debit, under your own bank's protections and limits. The reach is the scheme's: ACH pays accounts in the United States, and the SEPA schemes cover the 41 countries and territories of the Single Euro Payments Area for payments in euros. A recipient outside the scheme is paid by an individual international transfer, with its own cost and delay. Prefunding a platform means the pot leaves your account before anyone is paid. That is the trade for reach: the platform holds balances in several currencies and uses local payout methods in each country, which is what makes it practical to pay 300 people in 30 countries from one list. An onchain batch needs the whole amount in the paying wallet, in the token being sent, plus enough of the network's native currency for the fee. Borders do not exist at the network level, and the question moves to the recipient: each one needs a wallet and, if they want local currency, a way to convert. ## What is the difference between paying out and routing a payment? Paying out means dividing money you already hold among recipients; routing means sending an incoming payment straight to its recipients so that no one holds the pot in between. A batch payout tool starts from a balance and a list, while a payment router starts from a payment that has not yet been made and a set of shares agreed in advance. In a payout the order is: collect, hold, then distribute. Whoever holds is responsible for the pot, for the calculation and for the timing, and recipients are paid when the holder runs the batch. A monthly distribution to members, a contractor run and a rebate campaign are payouts: the money exists before the run and the payer decides when it leaves. In routing there is no holding step. A client owes one amount for one deal, several parties are each entitled to a part of it, and the client's single payment is divided as it arrives. An illustrative case: a client pays $60,000 for a deal with eight parties whose shares are 40%, 20%, 10%, 10% and four shares of 5%. The lead party receives $24,000, the second $12,000, two parties $6,000 each and four parties $3,000 each, for $60,000 in total, in the same transaction as the client's payment. No party received the full amount first and passed the rest on. ## Where does an onchain payment router such as Shaka fit? An onchain payment router fits one case: a single incoming payment that belongs to several parties, up to a small number, who should all be paid at the moment the client pays. It is not a batch payout tool, and it does not fit a distribution to several hundred recipients from money the business already holds. Shaka is one such router. Each party's share is set as a percentage of the deal, and each recipient can sign their share before the client pays, which costs the parties nothing. The client pays once, through a payment link, and every party receives their share at the same moment, in one transaction. Shaka routes the payment and never holds the funds. Because destinations are fixed and signed before the payment, the money cannot be redirected at the last minute. The payment is onchain and final, every party can see that the others were paid, and a payment record can be kept for the file. The limits follow from the design. A deal has at most 20 recipients, so the 300-person payout of this article is outside what the router is for. It needs an incoming payment, so it cannot distribute a balance sitting in your bank account. It is not a payroll tool, a bank, a card processor or an escrow service, and it does none of what those do: no withholding, no filings, no payout to a bank account by a local scheme. A business with a 12-party deal and a client about to pay is in its territory. A business with a member list and a pot is not. ## What does a 300-recipient payout require from each kind of tool? A payout of $240,000 to 300 recipients requires one file and 300 transfers from a bank, 300 onboarded payees from a payroll tool or a mass-payout platform, about three transactions from an onchain batch tool with a cap of 100, and cannot reasonably be done with a router. The table sets out the same job, with the same amounts, in each family. The assumptions are those used earlier, an average of $800 per person across the 300 recipients. Fees are left out because they vary by provider and plan. | Family | What the payer does | Who holds the $240,000 before | When the 300 are paid | | --- | --- | --- | --- | | Bank bulk or batch payment file | Uploads 1 file of 300 lines and approves it once | The payer, in a bank account | Each credit on its own, the same day or over the scheme's settlement days | | Payroll tool | Sets up 300 people, then approves 1 pay run | The provider, from collection until pay day | On the pay date | | Mass-payout platform | Sends 1 funding transfer, then 1 list of 300 payouts | The platform, as a prefunded balance | Each by its own method, from immediately to several days | | Card processor's payout feature | Nothing to send: only works if the $240,000 was collected by card through the processor | The processor, as a balance | Each connected account on its payout schedule | | Onchain batch transfer tool | Signs about 3 transactions of 100 transfers (illustrative cap) | The payer, in a wallet, as tokens | 100 at a time, each group in one block | | Onchain payment router | Not suited: 15 deals of 20 recipients, each needing its own incoming payment | Nobody | Does not apply to a payout from a held pot | ## How do you choose by situation? The choice depends on four things: whether the money is already in your hands or about to arrive, who the recipients are, where they are, and whether one failure should stop the run. No family covers every case, and a business with two kinds of payout often uses two tools. | Situation | Family that fits | Why | | --- | --- | --- | | Suppliers or members with bank accounts in one country or one currency zone | Bank bulk or batch payment file | Money stays in your account until the debit | | Employees, and contractors treated through payroll | Payroll tool | Calculation, withholding and filings come with the payment | | Hundreds of sellers, creators or affiliates in many countries | Mass-payout platform | Recipient onboarding, local payout methods, tax forms | | Sellers on a marketplace whose buyers pay by card | Card processor's payout feature | Payouts are tied to the sales collected | | Recipients who already use wallets, paid in tokens | Onchain batch transfer tool | One transaction per group, same block, public record | | One client payment owed to a few parties of one deal | Onchain payment router | No one holds the pot; all paid when the client pays | ## What should you check before sending a payout run? Before sending a run to many recipients, check the list, the limits, the failure behaviour, the funding and the record, in that order. Most of what goes wrong in a large payout was already wrong in the list, and the tool only reveals it.
Five checks before a run to many recipientsApplied to the illustrative payout of $240,000 to 300 recipients
  1. Reconcile the list to the totalCount the lines and add the amounts before upload: 300 lines, and $100,000 plus $100,000 plus $40,000 equals $240,000. A list that does not sum to the amount you approved has a duplicate, a missing line or a mistyped amount.
  2. Confirm the limits that apply to youAsk the bank or provider for the maximum number of entries per file, the daily value limit on the account and any per-payment ceiling. For an onchain tool, find the recipient cap per transaction and plan the groups: three groups of 100 here, with an illustrative cap of 100.
  3. Know what a failure doesFind out whether one bad entry stops everything or only itself, how a returned payment comes back and how long that takes. In the example, four returns leave $4,250 to resend and 296 people paid.
  4. Fund the right place in timeA bank file needs the amount in the account at debit; a payroll tool or payout platform needs it earlier, by the provider's lead time; an onchain batch needs the tokens and the network fee in the paying wallet.
  5. Decide the record you will keepSave the approved list, the file or transaction reference and the report of returns. Those three documents answer a recipient who says they were not paid, and an auditor who asks how the total was distributed.