In this article
Five kinds of tools let you split one payment between several people: a peer-to-peer payment app, bank transfers made by hand, a card processor with a split payout feature, an invoicing or accounting tool, and an onchain payment router. The criterion that separates them is who receives the client's money first: in most of them the whole amount lands with one person, who then pays the others, and only some of them divide the payment itself.
That criterion matters because the question hides two different jobs. Most "split" buttons in consumer apps divide a bill among the people who owe it: several payers, one recipient. A professional who has just been paid by a client has the opposite problem: one payer, several recipients. A tool built for the first job can be bent to do the second, but it does it by making you the person who collects everything and redistributes it.
This article compares the five families on the same criteria, for a small group: you and two to five other people, such as co-workers on a job, a referrer or a co-seller. Rules on payment services, consumer protection and tax vary by country, so the points below are general information and not legal or tax advice.
Worked example detailed further down: one client payment of $12,000 shared 50%, 30%, 15% and 5% among four people.
What is the difference between splitting a bill and splitting an incoming payment?
Splitting a bill means several people each pay a part of one amount owed, while splitting an incoming payment means one amount received is shared among several recipients. The first has many payers and one recipient; the second has one payer and many recipients, and most consumer "split" features do only the first.
The bill-splitting feature of a payment app works like this: one person pays the restaurant, the landlord or the travel booking, then the app sends a payment request to each of the others for their part. Money flows towards the person who paid. Nothing in that flow sends money outward to several people from a single payment received.
There are two ways to turn a bill-splitting tool towards that job. The first is to send the client one request per person, so that the client makes several payments instead of one. That hands your internal arrangement to the client and multiplies the chances that one payment is late or missing. The second is to receive the whole amount yourself and pay the others afterwards. That is not really a split: it is a collection followed by several ordinary payments, and it is what most small groups do without naming it.
Which kinds of tools can split one incoming payment among a few people?
Five kinds of tools can be used to share one incoming payment among a few people: a peer-to-peer payment app, manual bank transfers, a card processor with a split or marketplace payout feature, an invoicing or accounting tool, and an onchain payment router. Only the last three treat the split as part of the payment, and one of those three does not move any money.
A peer-to-peer payment app is a phone app linked to a bank account or a card, built for payments between people who know each other. It usually offers a "request" button and a "split" button. Nearly everyone already has one. Its split feature is a bill splitter, so for an incoming payment you receive the total and send each share yourself.
Bank transfers made by hand are the oldest method: the client pays your bank account, and you log in to your bank and send each person their part. Every party only needs a bank account, and the split lives in your agreement, not in the tool.
A card or online payment processor with a split payout feature, sometimes called a marketplace or platform feature, lets one account take the client's payment and pass defined portions to other accounts registered under it. Online marketplaces use it to pay their sellers; it accepts cards and automates the outgoing transfers once set up.
An invoicing or accounting tool records who is owed what. It can issue the invoice to the client and attach each person's share to it as a bill. Unless it is connected to a payment service, it moves no money.
An onchain payment router is a program on a public blockchain that takes one payment and sends each recipient their share in the same transaction. The shares are set before the client pays. No one in the group receives the total first.
Who receives the money first, and when is each person paid?
In a peer-to-peer app and with manual bank transfers, one person receives the whole payment and the others are paid when that person sends their share. A card processor with a split feature typically credits the account that runs the payment first and pays the others by transfer from it, while an onchain payment router pays every recipient in the same transaction as the client's payment.
The table below sets out the first three criteria for each family.
| Kind of tool | Who receives the money first | When each person is paid | Who it suits |
|---|---|---|---|
| Peer-to-peer payment app | The person the client pays, in an app balance or a linked bank account | When that person sends each share, one payment per person | Friends and informal groups, small amounts, people who trust each other |
| Bank transfers made by hand | The person whose bank account the client pays | When that person sends each transfer, subject to the bank's processing times | Any group where one person is accepted as the collector and amounts are larger |
| Card processor with split payouts | The account that runs the payment, in most set-ups | When the processor executes the transfers and then pays out to each bank account, on its payout schedule | Businesses that take card payments regularly with the same group |
| Invoicing or accounting tool | Whoever the invoice names; the tool itself receives nothing | When someone makes the transfers by another method | Groups that need clean records and already have a way to pay |
| Onchain payment router | Each recipient directly; no one holds the total | In the same transaction as the client's payment | Groups whose client and members can pay and be paid onchain |
A card processor's split feature exists in several designs. In the design most suited to several recipients, the public documentation of a large card processor describes the mechanism in these terms: the charge is created on the platform's account, the transfers to the other accounts are withdrawn from the platform's balance, and a single charge can be divided among several transfers. The split is automated, but the money still passes through one account, the one that runs the payment.
Who can change the split after the client has paid, and what can each person see?
When one person receives the whole payment, that person decides in practice what the others receive and when, and the others see only what arrives in their own account. With an onchain payment router, the shares and destinations are fixed before the payment, and every recipient can see the whole distribution on a public record.
| Kind of tool | Who can change the split after the client pays | What each person can see | Limits on amounts |
|---|---|---|---|
| Peer-to-peer payment app | The person who received the total | Their own incoming payment only | Sending and receiving limits set by the app, often per transaction and per period |
| Bank transfers made by hand | The person who received the total | Their own incoming transfer only | Transfer limits set by the bank and by the channel used |
| Card processor with split payouts | The holder of the account that runs the payment, until the transfers are made | Their own account under the platform; the account holder sees everything | Set by the processor and by the client's card |
| Invoicing or accounting tool | Anyone with edit rights on the records | Whatever the tool's access rights show them | None: no money moves |
| Onchain payment router | No one: the shares are set before the payment | The whole payment and every share | Set by the router's own rules and by how the client funds the payment |
The first column says where the agreement is enforced: by the collector's good faith, by how an account holder configured the transfers, or by the payment itself. The second cuts both ways. Not every group wants each member to see every share, and a public blockchain record shows the distribution to anyone who looks at the transaction.
What does each kind of tool require for the same $12,000 job?
For one client payment of $12,000 shared among four people, the five families require between one and four payments, and in three of them $6,000 belonging to other people passes through one person's account. The differences come from where the money lands first, not from the arithmetic, which is the same everywhere.
Here is the worked example, with every assumption stated. A client pays $12,000 for one job. The group agreed the shares in advance: you, who brought the job together, take 50%; a first co-worker takes 30%; a second co-worker takes 15%; the person who referred the client takes 5%. In dollars that is $6,000 for you, $3,600 for the first co-worker, $1,800 for the second and $600 for the referrer, which adds up to $12,000. Fees charged by any tool are left out, since they depend on the provider.
| Kind of tool | Payments needed | Who holds the money in between | When the three others are paid |
|---|---|---|---|
| Peer-to-peer payment app | 4: the client pays $12,000, you send $3,600, $1,800 and $600 | You hold $12,000, of which $6,000 is owed to others | When you send each payment, if the app's limits allow the amounts |
| Bank transfers made by hand | 4: one transfer in, three transfers out | You hold $12,000, of which $6,000 is owed to others | When your three transfers arrive |
| Card processor with split payouts | 1 by the client; 3 transfers generated by the processor | The account that runs the payment, then each member's account under it | When the transfers execute and the processor pays out to each bank |
| Invoicing or accounting tool | 0 moved by the tool; the 4 payments above still happen elsewhere | Whoever collected the payment | When someone pays the three bills recorded |
| Onchain payment router | 1 by the client | No one | In the same transaction: $6,000, $3,600, $1,800 and $600 arrive together |
One variant is worth adding for the first two families. If you ask the client to pay each person directly, the client makes four payments of $6,000, $3,600, $1,800 and $600, and no one holds anyone else's money. The price is that the client now runs your distribution for you, has four references to get right, and learns that the referrer received $600.
What does each option cost?
Each family costs something different in kind: a peer-to-peer app and a bank transfer cost mostly your time and sometimes a per-transfer fee, a card processor charges for each payment it processes, an accounting tool charges for the software, and an onchain payment router involves a network fee and whatever the router itself charges. Exact prices vary by provider, country and account type, so the comparison below is qualitative.
A peer-to-peer payment app is often free between personal accounts funded from a bank account, and commonly charges when a card funds the payment, when the account is a business one, or when you want the money moved to your bank at once instead of in the standard time.
Manual bank transfers are free or cheap inside one country on many accounts, and cost more across borders, where a transfer fee and an exchange rate margin can apply to each transfer. The larger cost is the time spent entering and checking each recipient's details.
A card processor charges the account that runs the payment, usually a percentage of the amount plus a fixed sum per payment, and may add charges for the split feature, for payouts or for currency conversion. The group has to decide who bears that fee: taken off the total before the shares are computed, or absorbed by the person who runs the account.
An invoicing or accounting tool is paid for by subscription in most cases. It adds no cost per payment because it makes none.
An onchain payment router involves the network's transaction fee, which is paid by whoever sends the transaction, plus the router's own fee if it has one. The cost that groups overlook is conversion: if the client or a recipient does not already hold the asset the payment is made in, someone pays to convert into it or out of it.
Are there limits on the amounts you can split with a payment app or a bank?
Yes: peer-to-peer payment apps and banks both set limits on how much you can send or receive, and those limits are often what rules a tool out for professional amounts. The limits are set by each provider, change with the level of identity verification on the account, and differ between personal and business accounts.
Peer-to-peer apps were designed for everyday sums between individuals. Their limits are typically expressed per transaction and per week or month, and an unverified account has lower ones. A client payment can exceed what the client's account may send or what yours may receive in the period. Check both sides, and your own sending limit too: you will make several outgoing payments in a row.
A second limit of this family is the purpose of the account. Many peer-to-peer services restrict personal accounts to payments between people who know each other and expect commercial payments to go through a business account, with its own terms and charges. Read the user agreement of the app you intend to use: an account used outside its terms can be restricted, sometimes with a balance in it.
A third point concerns balances. The Consumer Financial Protection Bureau, a United States regulator, warned in a 2023 report that funds stored in payment apps may not be covered by federal deposit insurance in the way a bank deposit is. For a group, the practical reading is simple: money that belongs to three other people should not sit in an app balance longer than it takes to send it on.
Card processors set limits of their own, and the client's card has a credit or spending limit. The more distinctive feature of card payments is that the cardholder can dispute a payment after the fact. In the design described earlier, the documentation of a large card processor states that the platform account's balance is debited for the processing fees, refunds and chargebacks. In other words, if the client disputes the payment after the three others have been paid, the person who runs the account is the one who faces the reversal.
What changes when the whole payment lands in your own account first?
When the whole payment lands in your account first, you become responsible for money that is not yours: you hold it, you account for it, and you carry the consequences if something goes wrong before it is passed on. That is a workable role, and the normal one for a lead contractor who hires the others and invoices the client alone; it should be chosen knowingly instead of by default.
The first consequence is bookkeeping. A payment of $12,000 arriving in your account looks like $12,000 of income unless your records show that $6,000 was collected on behalf of others and paid out. How that is treated for income tax and for sales tax or value added tax depends on the country and on how the group is organised: whether the others invoiced you as subcontractors, whether you acted as an agent collecting for them, whether one invoice or several went to the client. It is easier to settle with an accountant before the first payment than after a year of them.
The second consequence is timing risk, which a written agreement and a fixed payment date reduce but do not remove. Between the moment the client's money arrives and the moment the last share leaves, the amount sits with you. If your account is restricted, if the bank holds the incoming payment for review, or if the client's payment is reversed, the others wait, and they wait on you.
Where does Shaka fit among these options?
Shaka is one onchain payment router: it takes one payment and pays every party their share at the same moment, in one transaction, and it routes the funds without ever holding them. It fits a group that wants the split carried out by the payment itself, and it does not fit a client who can only pay by card or bank transfer.
Each party's share is set as a percentage of the deal, and each recipient can sign their share before the client pays; signing costs the parties nothing. The client pays once, through a payment link. Because the 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 the record of who was paid what stays available onchain; a payment record can be kept for the file. A deal can have at most 20 recipients, which covers a small group with room to spare.
In the $12,000 example, the four shares of 50%, 30%, 15% and 5% would be set and signed first, the client would make one payment, and $6,000, $3,600, $1,800 and $600 would reach the four parties together. No one would hold the $6,000 owed to the three others.
It is also plain where it stops. Shaka is not an escrow service, a bank, a card processor or a payroll tool. A payment that is final is one the group should be certain about before it is made, since the shares cannot be rearranged afterwards. And every party, the client included, has to be able to pay or be paid onchain. Where one of those conditions fails, another family in the tables above is the right one.
How do you choose for a group of two to five people?
The choice depends on four things: how the client is able to pay, whether one person is meant to act as collector, how large the amounts are, and how often the same group works together. No family wins on all four, so start from the situation and read across.
- The client pays by card and the same group works together every month. A card processor with split payouts suits this case: the set-up effort is spent once, the client pays the way they prefer, and the transfers repeat. Agree who runs the account and who bears the fees and any dispute.
- One person hired the others and invoices the client alone. Bank transfers made by hand, backed by an invoicing or accounting tool, suit this case. The lead is the collector by design, the others are paid on their own invoices, and the records match the legal structure.
- Small sums among people who trust each other, now and then. A peer-to-peer payment app is enough, provided the amounts sit inside the app's limits and the account type allows the use. Send the shares the same day.
- Equals on one job, where no one wants to hold the others' money. An onchain payment router suits this case if the client and every member can pay and be paid onchain. If they cannot, asking the client to pay each person directly is the non-custodial alternative, at the cost of four payments instead of one.
- The split itself is settled and the problem is keeping track. An invoicing or accounting tool answers that, alongside whichever payment method the group already uses. Two situations sit outside this article's scope. Paying dozens or hundreds of recipients at once is a bulk payout problem, with tools of its own. And paying employees is payroll, which carries tax withholding and reporting duties that none of the five families handles by itself.
What should you ask about a tool before the group relies on it?
Six questions tell you whether a tool fits your group, and each maps to a criterion in the tables above. Put them to the provider's documentation or support before the first client payment, not after.
- Does it split a bill or an incoming paymentIf the feature sends requests to several payers, it is a bill splitter. You need one that sends money to several recipients from a single payment.
- Where does the client's money land firstIn one person's balance, in a platform account, or directly with each recipient. This decides who is responsible for the money between payment and distribution.
- When is each share usableAsk for the time until the money is in each person's own bank account or wallet, not the time until a transfer is shown as created.
- Who can alter a share after the client has paidThe collector, the account holder, anyone with edit rights, or no one. Match the answer to how much the group wants to rely on a written agreement.
- What limits and account rules applySending and receiving limits per transaction and per period, the verification needed to raise them, and whether the account type permits professional use.
- What happens if the client's payment is reversedWhether the payment method allows a dispute or a recall, and whose balance is debited if the others have already been paid.
A group can combine families: invoice from an accounting tool, be paid through a processor or a router, and keep its agreement in a signed one-page document. What matters is that every member knows, before the client pays, where the money will land and on what day their own share will reach them.
