In this article
A payment router is a tool that takes one incoming payment and sends each agreed party its share directly, in the same operation, without holding the money in between. It is not a payment processor, a bank, an escrow service, a paying agent, a payroll tool, invoicing software, a wallet or an exchange, and the one criterion that separates it from all of them is custody: a router passes money through, the others hold it, move it on instruction or record it.
That definition has three parts, and each one excludes something. "One incoming payment" means the payer acts once, whatever the number of people behind the deal. "Each agreed party its share" means the division was settled before the money moved, by the parties, not by the tool. "Without holding the money in between" means there is no balance sitting anywhere waiting for a second step: the payment and its division are one event.
The term has a second, older meaning in card payments, where it describes software that picks which processor handles a card transaction. This article is about the first meaning, the multi-party one, and gives the second a short section so the two are not confused.
Worked example detailed further down: one payment of $80,000 divided 70%, 15%, 10% and 5% between four parties.
What does "payment router" mean in card payments?
In card payments, "payment routing" means choosing the path a card transaction takes to be authorised: which processor, which acquiring bank or which card network handles it. Software that makes that choice is sold as payment orchestration or smart routing, and it is sometimes called a payment router. It is a different thing from a multi-party payment router: a card router chooses who processes one payment for one merchant, while a multi-party router divides one payment between several recipients.
The card meaning exists because a merchant of some size rarely relies on one provider. An orchestration layer sits between the checkout and several gateways and acquirers, and decides for each transaction which route to use. Industry guides such as TechRepublic's guide to payment orchestration describe the usual rules: send the transaction to the provider most likely to approve it given the card's issuer and region, prefer the cheaper route when approval rates are similar, and retry through a backup route when the first attempt fails or a provider is down.
Routing is also a regulated notion for debit cards in the United States. The Federal Reserve's Regulation II bars issuers and networks from limiting a debit card to fewer than two unaffiliated networks, and from inhibiting a merchant's ability to direct the routing of a debit transaction over any network the issuer has enabled. When a merchant's software picks the cheaper of the two networks, that choice is commonly called least-cost routing.
How does a multi-party payment router work, step by step?
A multi-party payment router works in four steps: the parties agree their shares, the payer makes one payment, every party receives its share at the same moment, and a record of the division exists. The order matters, because the agreement comes before the money and nothing is left to decide after it.
- The shares are agreedThe parties name every recipient, the destination each one will be paid to, and the share each one receives, usually as a percentage of the deal. The shares add up to the whole payment. On some routers each recipient confirms or signs their own line, so nobody discovers their share after the fact.
- The payer pays onceThe payer receives a single request for the full amount and makes a single payment. The payer does not need to know how the amount is divided, and does not send several transfers to several people.
- Every party is paid at the same momentThe router applies the agreed shares to the incoming amount and sends each recipient its part directly, in the same operation as the payment itself. There is no first recipient and no last one, and no balance stays behind.
- A record existsThe operation leaves one record showing the amount that came in and the amount that went to each destination. Every party can point to the same record, instead of each one holding a separate bank line for a separate transfer.
A router is only as good as the agreement it is given: it executes a division, it does not negotiate one. It can also be built on more than one rail. Some marketplace platforms split a card payment between accounts their payment provider manages, which involves a holding period. An onchain router does the division inside one blockchain transaction, and is the form that meets "not held in between" most literally.
What is a payment router not?
A payment router is not a payment processor, a bank, an escrow service, a settlement or paying agent, a payroll tool, invoicing software, a wallet or an exchange. Each of those does something a router does not do, and three questions separate them first: who holds the funds, who decides who is paid, and whether several parties are paid in one operation.
| Family of tool | Holds the funds? | Decides who is paid? | Pays several parties at once? |
|---|---|---|---|
| A payment processor | Briefly, between capture and payout | No: it pays the merchant | No, one merchant per payment as a rule |
| A bank | Yes, as deposits | No: it follows the account holder's orders | Only as separate or batched transfers ordered by the holder |
| An escrow service | Yes, until the conditions are met | Yes, by applying the escrow instructions | Sometimes, at release |
| A settlement or paying agent | Yes, from receipt to disbursement | It applies a settlement statement or a contract | Yes, as a list of disbursements |
| A payroll tool | Usually, between funding and pay day | No: the employer does | Yes, on a schedule, to employees |
| Invoicing software | No: it issues documents | No | No: one invoice, one payer, one payee |
| A wallet | Yes, it is where the owner's money sits | The owner does | Only if the owner sends several transfers |
| An exchange | Yes, in customer accounts | No: customers trade and withdraw | No: it converts, it does not divide |
| An onchain payment router | No | No: the parties agree the shares beforehand | Yes, in one transaction |
The first column carries most of the difference. Every tool above the last row either keeps money for a period or is the place where money rests. Holding funds is not a defect: it is what lets a bank pay interest, a processor absorb a dispute, an escrow service wait for a condition and a paying agent reconcile a closing. It is also what a router gives up. A router that holds nothing cannot wait, cannot net, cannot refund from a balance and cannot fix a mistake afterwards.
Two further criteria complete the map: whether a payment can be reversed once made, and whether the tool occupies a regulated role. Both vary by country, and the table below states the general pattern only.
| Family of tool | Can the payment be reversed? | Regulated role? |
|---|---|---|
| A payment processor | Yes: refunds and card disputes | Yes, under payment law and card network rules |
| A bank | Depends on the rail: some transfers can be recalled or disputed, a completed wire generally cannot | Yes, licensed and supervised |
| An escrow service | Before release, funds can go back to the payer under the instructions | Often licensed or bonded, depending on the place and the type of deal |
| A settlement or paying agent | Until disbursement, the agent can correct or withhold | Usually a regulated or licensed profession, or a bank or trust company |
| A payroll tool | A pay run can sometimes be corrected or recalled within the rail's limits | Operates under employment and tax rules, and payment law where it moves money |
| Invoicing software | Not applicable: an invoice can be cancelled or credited, the payment follows its own rail | Generally not for the documents, yes for any payment service attached |
| A wallet | No for an onchain transfer once confirmed | Depends on who holds the keys: custody providers are regulated in many countries |
| An exchange | Internal trades are final; withdrawals follow the rail used | Yes in most countries that regulate the activity |
| An onchain payment router | No: the transaction is final | Depends on the country and on the design; holding no funds does not by itself settle the question |
What does each of those tools do that a payment router does not?
Each of the eight tools exists for a job a payment router does not attempt: accepting cards, keeping deposits, holding money against a condition, closing a transaction, paying employees, billing, storing value or converting it. A router can sit next to any of them. It replaces none of them.
A payment processor lets a business accept cards and other consumer payment methods. It authorises the payment, manages fraud screening, handles refunds and disputes, and pays the merchant on a payout schedule. A router does none of that: it accepts no card and has no dispute process. The difference comes down to who the money goes to, one merchant in one case and several agreed parties in the other.
A bank keeps money safe, lends, and moves it on its customer's order through wires, local transfers and cards. It will send ten transfers if you order ten, but the money rests in your account between the receipt and the orders. A router has no accounts.
An escrow service holds money on behalf of two parties until stated conditions are met, then releases it, or returns it if they are not. That holding period is the service, and it is exactly what a router lacks. The two are not substitutes: a deal that needs someone neutral to hold the price while a title, a domain or an inspection clears needs escrow, and a router cannot provide it.
A settlement or paying agent, and in property the closing or settlement agent, receives the funds of a transaction, checks them against a settlement statement or a paying agency agreement, pays off what must be paid off, and disburses the rest to each party entitled to it. The agent carries professional duties a tool does not: verifying identities, clearing liens, reconciling the figures, keeping trust accounts. In corporate deals a paying agent does the same for shareholders or bondholders.
A payroll tool calculates what each employee is owed for a period, withholds taxes and contributions, files the corresponding returns and pays net wages on a schedule. A router calculates nothing beyond applying agreed shares to an amount, and files nothing.
Invoicing software produces the documents of a sale: the invoice, its numbering, its tax lines, its reminders, and the ledger of what is paid and unpaid. A router issues no invoice and keeps no receivables ledger.
A wallet is where a person or a business keeps money it controls, whether that is a balance in an app or the keys to onchain funds. A wallet sends where its owner tells it to. A router is not a place to keep anything, although the recipients of an onchain router each need a wallet to receive their share.
An exchange converts one asset into another and keeps customer balances while it does so. A router does not convert, quote a price or hold a balance.
What does "onchain" add to a payment router, and what does it require?
Onchain, a payment router divides the payment inside one blockchain transaction, which is final once confirmed and visible to every party. What it requires is that the payer can pay onchain and that every recipient can receive onchain.
A blockchain transaction is a single operation that either happens entirely or does not happen at all. When the router is a program on the blockchain, the incoming payment and the outgoing shares are parts of that same operation. There is no moment at which the full amount has arrived and the shares have not left, so there is no balance for anyone to hold, freeze, lose or redirect.
Three properties follow:
- One event. Either every recipient is paid or nobody is, and the payer keeps the money. A partial outcome, where two parties are paid and the third is waiting, cannot occur.
- Final. A confirmed transaction is not reversed by a bank, a card network or the router. Nobody can pull a share back after the fact.
- Visible to all parties. The transaction is recorded on a public ledger. Each recipient can see their own share arrive and can see that the other shares were sent in the same transaction, without asking anyone for a statement.
The requirements are just as concrete. The payer needs a way to pay onchain, in an asset the router accepts. Every recipient needs a destination they control, checked before the deal, because a share sent to a wrong destination is not recoverable through the router. The parties need to be comfortable being paid in that asset, and to handle their own conversion to bank money if they want it. Invoices, tax reporting and any checks a profession requires stay with each party.
What can a payment router not do?
A payment router cannot hold money against a condition, reverse a payment, calculate shares that were not agreed, pay more recipients than its limit, or issue invoices and tax forms. These five limits follow from the definition, and each one points to the tool that does the job.
It cannot hold money against a condition. "Pay the seller when the buyer confirms delivery" requires someone to keep the money while the condition is open. A router pays at once or not at all. Conditional release is the work of an escrow service or, in a closing, of the settlement agent.
It cannot reverse a payment. There is no refund button and no dispute desk, because there is no balance to refund from. If a refund is owed, the party who received the money sends it back as a new payment.
It cannot calculate shares that were not agreed. A router applies percentages or amounts it is given. It does not know that a referral was promised verbally, that a commission tier changed last month or that one party's share is net of an advance. Those calculations belong upstream, in the agreement, the commission plan or the settlement statement.
It cannot pay more recipients than its limit. Every router has a ceiling on the number of recipients in one operation, set by its design and, onchain, by how much one transaction can carry. A distribution to several hundred holders is a job for a paying agent or a mass-payout tool, or it has to be done in several operations.
It cannot issue invoices or tax forms. The record a router leaves proves that a payment was made and how it was divided. It is evidence for the file, not an invoice, a payslip or a tax return. Each party still bills, books and declares its own share with its own tools.
What does one payment to four parties look like, before and after?
On one payment divided between four parties, a router reduces four money movements to one and removes the period during which one party holds the others' money. The worked example below uses invented parties and round figures to show it.
Take a consulting engagement billed at $80,000 to one client. Four parties are entitled to a part of it under their own agreement: a lead consultant at 70%, an engineering firm at 15%, a surveyor at 10% and the introducer who brought the client at 5%.
| Party | Agreed share | Amount on $80,000 |
|---|---|---|
| Lead consultant | 70% | $56,000 |
| Engineering firm | 15% | $12,000 |
| Surveyor | 10% | $8,000 |
| Introducer | 5% | $4,000 |
| Total | 100% | $80,000 |
Without a router, the usual arrangement is that the client pays the lead consultant the full $80,000, and the lead consultant then sends three transfers of $12,000, $8,000 and $4,000. With a router, the same four shares are agreed first and the client's single payment reaches the four parties directly.
| Point compared | Collected by one party, then forwarded | Routed |
|---|---|---|
| Payments made by the client | 1 | 1 |
| Onward transfers | 3 | 0 |
| Money movements in total | 4 | 1 |
| Other parties' money held by the lead consultant | $24,000, until forwarded | $0 |
| Money held by the tool | Not applicable | $0 |
| When the last party is paid | When the lead consultant sends the last transfer | At the same moment as the first |
| Proof that everyone was paid | 4 separate bank records, held by different people | 1 record showing all four shares |
Nothing in the first column is improper: collecting and forwarding is how most shared fees are paid, and it works when the parties trust each other. It creates a dependency, since three parties wait on a fourth while $24,000 of theirs sits in that party's bank balance. The routed column removes the dependency at a price: the four shares must be final before the client pays, and nothing can be adjusted afterwards except by a new payment. The amounts owed are identical in both columns.
When is a payment router useful, and when is it not?
A payment router is useful when one payment belongs to several parties whose shares are known before the payment, and it is of no use when there is a single recipient, when the shares are not yet known, or when the money has to wait for a condition. The choice depends on those three facts about the deal, not on the tool.
By situation:
- One recipient. No router is needed. A bank transfer, a card payment through a processor or an invoice with a pay button does the whole job.
- Several recipients, shares fixed, nothing to wait for. This is the router's case: a commission shared between co-agents, a fee shared between firms, a sale price shared between co-owners, a referral paid alongside the main fee.
- Several recipients, but the money must wait for a condition. Use an escrow service or a settlement agent. If the release itself then has to be divided between several parties, a router can carry that final step, but it does not replace the holding.
- Many recipients paid on a schedule, with tax withholding. Use a payroll tool for employees, or a mass-payout tool or paying agent for holders and contractors in large numbers.
- Customers paying by card, with a right to a refund. Use a payment processor. If the proceeds then have to be divided, that is a second question, answered by a platform split or by a separate distribution.
- Shares that depend on a calculation not yet done. Finish the calculation first. A router has nothing to execute until the shares are final.
- Parties who cannot or will not receive onchain. An onchain router does not fit. A bank-based distribution through whoever collects the money is the workable route.
Where does Shaka fit among payment routers?
Shaka is one example of an onchain payment router: one payment comes in and every party is paid their share at the same moment, in one transaction, and Shaka never holds the funds. It is described here as an instance of the family defined above, with the same limits.
Each party's share is set as a percentage of the deal, and each recipient can sign their own share before the client pays, at no cost to the parties. The destinations are fixed and signed before the payment, so the money cannot be redirected at the last minute. The client pays once, through a payment link. The payment is final, every party can see that the others were paid, and the record of who was paid what stays available onchain. A deal has at most 20 recipients.
Where it does not fit follows from what a router is. Shaka is not an escrow service, a payroll tool, a bank or a processor: it does not hold money against a condition, does not reverse a payment, and requires a client who can pay onchain and parties who can receive onchain. A deal with a single recipient, or one whose shares are still under discussion, has no use for it.
What should you ask of any payment router?
Ask four questions of any payment router: who holds the funds, who can change the shares, what proof exists, and what limits apply. The answers tell you whether the tool is a router in the strict sense or a different tool using the word.
Who holds the funds, and for how long? The strict answer is "nobody, at any moment". If the answer is "we hold them for a few days and then pay out", the tool is a processor or a platform with a split feature. That may suit you, but your money is then exposed to that provider for the holding period.
Who can change the shares, and until when? Find out who enters the recipients and percentages, whether each recipient sees and confirms their own line, and whether anything can be edited after the recipients have agreed. The point to settle is whether a single person can alter a destination or a percentage between the agreement and the payment without the others knowing.
What proof exists afterwards? Ask what record the payment leaves, who can consult it, and for how long. A record every party can read independently is stronger than a statement one party forwards to the others. You will still need your own invoice and accounting entry.
What limits apply? Ask the maximum number of recipients per payment, the payment methods or assets accepted, whether there are minimum or maximum amounts, and whether a payment can ever be partial. Ask what happens when something is wrong at the moment of payment: on a strict router the whole operation fails and the payer keeps the money, which is the safe outcome.
