# How to receive payment as a two-person business who both need access
When two people run a business together, the question of who receives client payments and how both parties get their share creates real operational and trust problems — here is how onchain payment routing solves it.
---
Two people. One business. One invoice. The moment a client sends money, a question that no partnership agreement fully prepares you for becomes suddenly very concrete: whose wallet does it land in, and how does the other person get their share?
This is not a niche problem. It is one of the most common friction points in small professional businesses — boutique advisory firms, co-founded agencies, joint venture consultancies, real estate brokerages where two licensees split a commission, legal practices with two equity partners, OTC desks operated by two principals. The moment you move beyond a single sole proprietor, you have a distribution problem. And the way most two-person businesses handle it today ranges from clunky to genuinely risky.
This article walks through how that problem actually plays out, what the conventional solutions cost you in time and trust, and why a properly structured onchain payment routing approach — specifically the kind that shaka.deal enables — resolves the core issues in a single transaction.
## The Real Shape of the Problem
Before reaching for solutions, it is worth being precise about what the problem actually is.
A two-person business receives revenue from clients. That revenue needs to reach both parties in proportion to whatever arrangement they have agreed on — equal split, 60/40, a fixed-fee arrangement where one person takes a set retainer and the other takes the remainder, or any other structure. The challenge has three distinct layers:
**Layer one: receipt.** Someone has to receive the money first. In a traditional bank setup, that means a joint account or one person's account is designated as the landing point. A joint bank account gives both parties equal ownership control, but it also introduces risk — each owner has equal authority to act, and jointly held funds can potentially be seized to satisfy a debt collection action against either party. Neither outcome is what a healthy two-person business intends.
**Layer two: distribution.** Once the money arrives, it needs to be divided. In a bank-based workflow, that means one party manually transfers the other party's share. This seems trivial until it happens on the wrong day, until someone is traveling, until a dispute exists about whether the right amount was sent, or until a bookkeeper needs to reconcile four months of these transfers and cannot easily match each transfer back to its originating deal.
**Layer three: certainty.** Both parties need to know, at the moment a client pays, that the distribution will happen as agreed — not "soon," not "when I get a chance," not "pending the bank clearing." The moment one party has to depend on the other to execute a manual transfer, you have introduced counterparty risk inside your own business. That is the friction that strains partnerships and, often enough, ends them.
## How Two-Person Businesses Handle This Today
Most small two-person operations fall into one of a few patterns, each with its own failure mode.
**Pattern A: The designated account.** One person's business account is the landing zone for all client payments. That person then sends the other their share. This is clean for the client — they pay one address — but it means one party is permanently upstream and the other is permanently dependent. The downstream party has no visibility into when payment arrives, no guarantee of timing, and no recourse if the upstream party delays or sends the wrong amount. It also means the upstream party carries administrative burden for every deal. Over time, this asymmetry creates resentment in both directions.
**Pattern B: The joint bank account.** Jointly owning an account introduces security risks: someone might misuse company funds, and if one owner gets into personal financial trouble, a creditor could try to seize the business account to pay that person's debts. Beyond those risks, a joint bank account with two signatories for *outbound* payments can be operationally frustrating — two people need to be available to authorise a payment at the same time, or the bank's threshold rules require one signature for amounts below a cap and two above it. For a small active business, that threshold becomes an obstacle regularly.
**Pattern C: Two separate accounts and manual reconciliation.** Some businesses instruct different clients to pay different accounts. Client A pays Person 1, Client B pays Person 2. At the end of the month, the two people true-up whatever imbalance has accumulated. This sounds pragmatic but becomes a bookkeeping nightmare, and it requires both parties to trust the other's reporting of what came in. It also breaks down entirely on large single-transaction deals where one payment represents a major portion of total revenue.
## Why the Crypto Analogue Has the Same Problems — Until You Design It Differently
Many two-person businesses that operate in or adjacent to crypto markets have moved their client payments onchain. They invoice in USDC or USDT, they accept ETH, they deal in stablecoins. Stablecoins are increasingly being treated as settlement rails rather than trading pairs, stepping into roles historically dominated by correspondent banking networks — and institutions are responding to practical advantages including programmability, fast finality, and clearer cost structures.
But adopting crypto payments does not automatically solve the distribution problem. If you are a two-person business and your client sends USDC to one wallet address, you have reproduced Pattern A in an onchain context. The upstream party still has to manually send the downstream party their share. The downstream party still has no guaranteed timing. The only difference is that the transactions are now visible on a block explorer, which adds transparency but not certainty.
For business settlement, irrevocability is worth more than message delivery, because it is the property that lets you release goods, fund an account, or pay a party without holding your breath. Onchain finality is a genuine advantage over traditional rails. But finality that lands in one wallet and then requires a second manual transfer to reach the other party means you get finality on the first leg and uncertainty on the second.
## What Onchain Payment Routing Actually Does
Shaka.deal is a B2B onchain payment router on Ethereum. The core mechanic is straightforward but meaningful: a payer sends a single transaction to a deal address, and the smart contract routes the full amount to every party in their preset share, simultaneously, in that same transaction. It routes; it never holds funds.
For a two-person business, this matters in several specific ways.
**Both parties get paid at the moment the client pays.** There is no relay race, no interim custody, no one person waiting for the other to execute a manual transfer. The client pays once, the contract routes instantly, and both wallets receive their portion in the same block.
**The shares are preset and immutable for that deal.** Before the client ever sends money, both parties agree to the split — 50/50, 70/30, 55/45, whatever the arrangement is. That split is encoded in the deal. The client's payment triggers it. No human decision is required at settlement time, which means no opportunity for that decision to be made incorrectly, delayed, or disputed.
**Each party controls their own address.** Neither person is upstream of the other. Neither has to trust the other to execute a secondary transfer. The routing happens at the contract layer. Shared control no longer depends on requiring multiple executives to manually authorize each outbound payment — instead, both parties simply receive their share automatically when the deal settles.
**The transaction is final.** Onchain payments, once confirmed, cannot be reversed or recalled. This is categorically different from traditional rails. A card authorization can be reversed for months; a SWIFT message may be acknowledged in hours but only settles once correspondent banks clear it, often one to several business days later. When a client pays a shaka.deal deal address, settlement is complete. Both parties know it. Accounting is straightforward.
## Walking Through a Concrete Scenario
Consider two consulting professionals — call them Alex and Morgan — who operate a joint advisory practice. Their split is 60% to Alex and 40% to Morgan, reflecting their respective roles and overhead contributions. They work on deal-by-deal engagements, with clients paying a single agreed amount per engagement.
**The old workflow** looked like this: clients wire to Alex's business account. Alex reviews incoming payments every few days. When a payment clears, Alex sends Morgan's 40% manually. Morgan gets a Slack message saying "sent your share of the Henderson engagement," checks the next day, sees the transfer, and reconciles it against the project in the accounting software. On a busy month, three or four of these transfers happen, sometimes out of sequence with when they were actually earned. At year-end, the bookkeeper spends hours matching transfers to source deals.
**The new workflow** with onchain routing: before any client pays, Alex and Morgan set up the deal on shaka.deal with the agreed split — 60/40 — and their respective wallet addresses. The client receives one payment address. When the client sends $18,000 USD (~$27,540 AUD at current rates), the smart contract routes $10,800 to Alex's wallet and $7,200 to Morgan's wallet in the same transaction. Morgan does not need to wait for Alex. Alex does not carry a float or an administrative obligation. Both parties see the same transaction on-chain. Reconciliation is one line, not two, because there was one transaction.
The mechanics stay identical whether the deal is $18,000 or $180,000 USD. The client sends once. The contract splits instantly. Settlement is certain.
## The Trust Architecture of a Two-Person Business
There is a deeper point underneath the mechanics. Two-person businesses run on trust — and poorly designed payment workflows quietly erode that trust, even between people who genuinely want to work well together.
When one person is structurally upstream of the other, the downstream person cannot help but wonder whether distributions are fully accurate, fully timely, and accounting for every deal. Even if the upstream person is scrupulously honest, the architecture creates doubt. And where there is doubt, there are eventually conversations that would not have been necessary if the system had been designed more cleanly.
A multisig or routing architecture blocks unilateral action — even if one key is stolen or compromised, funds stay safe. The same principle applies to business distribution design: the best arrangement is one where neither party's goodwill is being tested by the architecture. If both parties receive their share automatically and simultaneously, neither one is exercising discretion over the other's money. The system removes a category of potential conflict entirely.
This is not about distrust. It is about designing a business so that the payment infrastructure reflects the actual ownership structure — not a workaround built on one person being the de facto treasurer for the other.
## The Multisig Question
Some two-person businesses that have researched this space land on multisig wallets as their answer to the shared-access question. A single-signature wallet operates like a standard bank account where one key grants full access; in contrast, a multisig wallet functions like a joint account with added security, requiring multiple approvals for any action.
Multisig strengthens control over shared crypto assets, but has one trade-off: slower approval times. For a two-person business that needs to move quickly — paying vendors, moving operating capital, reacting to a deal closing on short notice — requiring both parties to sign every outbound transaction can become an operational bottleneck. Any one of the copayers can initiate a transaction, but the transaction remains pending until the other parties sign. If one person is in a different time zone, on a plane, or simply not at their desk, payments stall.
Multisig is a strong answer to a different question: how do we prevent either party from unilaterally draining shared treasury funds without the other's knowledge? For operating funds, that is a legitimate concern and multisig is a reasonable control. But for *receiving client payments and distributing them*, multisig introduces unnecessary friction. You do not want to require a second approval to pay yourself your own share of a deal you both agreed to close.
Onchain routing at the point of receipt — using a tool like shaka.deal — handles the distribution side cleanly. The multisig question, if it exists, lives downstream: how do the parties manage their shared operating expenses and retained capital? Those can coexist. The inbound payment router handles distribution. The multisig, if the business uses one, handles shared treasury governance. They solve different problems and do not compete.
## What Settlement Professionals in Two-Person Practices Need to Know
Many of the professionals who handle deal closings — settlement agents, closing attorneys, title companies, OTC desk operators, real estate brokers — work in tight two-person or small-team structures. The mechanics described above apply directly to their workflows.
Consider an OTC desk run by two principals. A client sends a large stablecoin amount to close a deal. The two principals have a pre-agreed split on deal revenue. Today, the typical flow involves one party receiving the payment, confirming the deal is complete, and then manually distributing the other party's take. That manual step is where delay, dispute, and trust erosion live.
With a routing layer, the deal structure is configured before the client pays. The client's single payment triggers simultaneous payout. Both principals see the same block-confirmed transaction. In a multisig or routing structure, all parties are visible on the blockchain, and anyone can check via block explorers when a transaction occurred and who approved it. There is no ambiguity about whether the right amount was sent and when.
For a closing attorney operating with a junior equity partner — a very common structure at small practices — the same logic applies. The client pays the firm. The firm's deal address routes the full amount, simultaneously delivering the senior partner's share and the junior partner's share in a single confirmed transaction. The settlement is not pending the senior partner's goodwill; it is encoded in the deal itself.
For settlement professionals who are already comfortable handling onchain transactions on behalf of clients, extending that infrastructure to their own internal distribution is a small step with a large payoff in operational clarity.
## Setting Up the Workflow in Practice
For a two-person business considering this approach, the practical setup involves a small number of decisions made once, before deals begin.
The setup, decision by decisionEach party keeps their own wallet; the client pays one address
Decide on wallet structureEach party maintains their own non-custodial wallet at their own address. Neither wallet is shared. Neither party has access to the other's private keys. This is the correct starting point — clean separation of individual holdings.
Agree on the split per deal or per deal typeSome two-person businesses have a single fixed split for all deals. Others vary the split based on who originated the deal, who executed the work, or what the deal type is. Shaka.deal allows each deal to be configured with its own shares, so a business can run 50/50 on retainer work and 70/30 on origination-heavy deals without changing the underlying wallet setup.
Give clients one payment addressThe deal address is what the client sees on the invoice. They pay once. The complexity lives in the contract layer, not in the client's workflow. From the client's perspective, it is a straightforward wire to a single address — no different from a bank transfer in practice, with the difference that settlement is final and immediate rather than batch-cleared.
Receive payment with certaintyWhen the client pays, both parties receive their preset share in the same transaction. Both can confirm independently on-chain. There is no dependency between parties on the settlement step.
## The Accounting and Auditability Advantage
There is a secondary benefit that becomes apparent after a few months of operating this way: the records are clean.
Every deal has one transaction. That transaction has one hash. Both distributions — to both parties — appear in that single transaction record. When either party's accountant or tax professional needs to reconcile revenue, each deal maps to one on-chain event, not two transfers that need to be matched and dated separately.
Compare that to the manual-transfer model, where a $50,000 USD (~$76,500 AUD) deal generates: an inbound transfer of $50,000, and then a subsequent outbound transfer of $20,000 to the second party (if the split is 60/40). Two separate transactions with two separate dates, potentially in different reporting periods if the manual transfer is delayed. That complexity, multiplied across every deal in a year, is where reconciliation time is lost.
The routing model collapses that to one event per deal. Settlement compresses from days to seconds, and the dollar balance becomes programmable — meaning a payment can carry conditions and chain into longer treasury workflows. For a two-person business with a good accountant and ambitions to scale, that cleanness compounds over time.
## Getting Started
For two-person businesses already invoicing in crypto — or considering the move — the shift to onchain payment routing is not a technical overhaul. It is a rethinking of where distribution logic lives: not in a manual transfer executed after the fact, but in the deal structure agreed upon before the client pays.
Shaka.deal handles the routing. Each party keeps their own wallet. The client pays once. Settlement is simultaneous, preset, and final.
That is the architecture a two-person business deserves: one that reflects the actual ownership agreement, that requires no downstream manual steps to honour it, and that removes the class of tension that comes from one party depending on the other to execute a transfer that should have happened automatically in the first place.
The question of who receives payment as a two-person business — and how both parties get access to what is theirs — has a clean answer when the payment infrastructure is built to route, not to accumulate.