How to set up a payment link a repeat client can reuse

There is a particular kind of friction that only surfaces after a working relationship matures. The project is good. The client is reliable. Communication is easy. And yet, every single billing cycle, both sides go through the same low-grade bureaucratic ritual: a new invoice is assembled, routed through email, opened late, forwarded to someone in accounts payable, and eventually paid — after a delay that neither party planned for but both have come to expect.

An invoice sitting in an email attachment gets opened late, downloaded never, and paid even later. Freelancers billing $2,000+ (AUD ~3,100) projects lose five to fourteen days of cash flow waiting for clients to find the PDF, figure out how to pay, and finally submit payment. For a repeat client relationship — a monthly retainer, a quarterly deliverable, a recurring creative brief — that delay is not a billing problem. It is a structural one. The payment mechanism is being rebuilt from scratch every single time, even though the underlying agreement has not changed.

This article is about solving that. Specifically, it is about how to configure a payment link that a repeat client can reuse across multiple billing periods, one that does not require re-invoicing, re-routing, or any manual coordination on either side. It is also about what happens when that payment link needs to settle funds across more than one party simultaneously — a collaborator, a subcontractor, a studio split — and why the architecture of that settlement matters as much as the link itself.

Why most payment links are built for single use

Payment links come in three types: single-use links that expire after one transaction, reusable links for repeat fixed-price sales, and recurring links for subscription-style billing. The vast majority of freelancers and small creative studios default to the first type, usually because their invoicing software generates a new link with each invoice. That is often the right choice for one-off projects with variable amounts. But for repeat engagements with agreed monthly or quarterly rates, it introduces unnecessary overhead.

Agency retainers break because they are pricing agreements rather than payment mechanisms. While the model promises predictable income, late manual invoicing, delayed payment detail collection, and unchecked scope drift recreate the cash flow chaos of project billing. The insight here is subtle but important: a fixed retainer agreement is, by definition, already resolved. The amount is known. The schedule is known. The only thing that changes month to month is who remembers to act on it first. A reusable payment link removes that dependency entirely.

A reusable (permanent) link is a single link you can share multiple times, often useful for recurring donations, repeat customers, or social media profiles. In a freelance context, that definition stretches naturally to cover monthly retainers, quarterly audits, ongoing design cycles, or any engagement where the fee is predetermined and the client relationship is established. The link lives in an email signature, a project management thread, or pinned in a shared Notion workspace. When the billing date arrives, the client uses it. No attachment, no chasing, no confusion about where to send the funds.

The complication that most reusable links ignore

A reusable link that simply collects payment and deposits it into one account solves the friction for the simplest version of a freelance arrangement. But a large proportion of real-world repeat engagements involve more than one party receiving a share of the incoming amount.

Consider a few scenarios that are genuinely common:

The studio split. Two creative directors run a shared consultancy and bill a client together. Each month the client pays a retainer. Each month, one of the two directors receives the full amount and manually transfers the other party's share — after it clears, after they remember, after they have enough liquidity in the account to move it. The split is agreed. The execution is still manual every single time.

The lead-and-subcontractor model. A copywriter holds the client relationship and brings in a strategist for half the work. The agreed rate is $8,000 (AUD ~12,400) per month: $5,000 (AUD ~7,750) to the copywriter, $3,000 (AUD ~4,650) to the strategist. The client pays once. The copywriter becomes, effectively, a payment intermediary for their own collaborator — absorbing the delay, the administrative burden, and the relational awkwardness of being owed money you are then supposed to pass on.

The fractional team. A product consultant assembles a rotating cast of specialists — a UX researcher, a data analyst, a brand designer — on a per-engagement basis. The client is billed a project rate. Each specialist has a predetermined share. The consultant's ability to pay those specialists promptly and correctly affects their willingness to show up for the next engagement.

In each of these scenarios, the payment link solves only the first step: getting money in. The distribution step is left entirely to manual process, personal discipline, and trust. Managing payments manually consumes time and introduces errors and delays, affecting business efficiency and partner trust. Split payments solve this by automating the allocation of funds from a single transaction to multiple stakeholders.

What is missing from most reusable payment link setups is the ability to define, in advance, who receives what share of every incoming payment — and to execute that distribution at the exact moment the payment arrives.

What a properly structured reusable payment link looks like

A well-designed reusable link for a repeat client has three characteristics that are worth stating explicitly.

First: the amount is fixed and agreed upon before the link is ever shared. This seems obvious, but it is violated constantly. When the amount is variable — when scope creep or hourly billing means the number changes — a reusable link is the wrong tool. A reusable link works precisely when the commercial arrangement is already settled. Monthly retainer. Quarterly package. Fixed per-deliverable rate. If both parties know the number before the billing period opens, the link can be set once and reused indefinitely.

Second: the distribution logic is encoded in the link itself, not in a spreadsheet that someone updates afterward. This is the structural leap that most freelancers have not yet made. The split between parties — 70/30, 60/40, a fixed amount to one party and the remainder to another — should be configured as part of the payment infrastructure, not decided anew each time a payment arrives.

Split payments are the allocation of funds from a single transaction to multiple parties based on predefined rules. When those predefined rules are embedded at the point of payment routing, every payment that comes through the link triggers the same outcome: the agreed shares land in the agreed wallets or accounts simultaneously, without a human in the chain making a judgment call.

Third: settlement is final at the point of transaction, not pending some downstream process. This is the dimension that traditional payment infrastructure handles poorly. Credit card payments, ACH transfers, and wire networks each introduce holding periods, reversal windows, or settlement timelines that mean the money that has "arrived" is not yet truly available to the parties who earned it. A payment marked as received on Tuesday may not be spendable until Friday. For a subcontractor waiting on their share, that difference is material.

How shaka.deal handles the routing layer

This is where the architecture of shaka.deal becomes directly relevant. Shaka.deal is a B2B onchain payment router built on Ethereum. When a deal is configured — parties, amounts, shares — and a payment comes in, the router distributes the total to every configured party simultaneously, in a single transaction, with finality.

The mechanics matter here. There is no custody step. Shaka routes funds; it does not hold them. The moment a client executes a payment through a configured deal link, the preset shares leave in the same transaction. The studio partner's 40% does not wait for the lead freelancer to initiate a separate transfer. The subcontractor's fixed amount is not contingent on the lead clearing their own bank account first. The routing logic that was agreed when the deal was set up executes at the same instant the client pays.

A freelancer can embed a link right in the email footer or project management chat, directing the client to pay in USD-pegged stablecoins. Funds arrive settled and spendable; no merchant-account hold times apply. For repeat engagements structured through shaka.deal, that link is the deal itself — it does not need to be regenerated each billing period, because the routing configuration is persistent. The client uses the same link in month two that they used in month one. The outcome is identical: preset shares, one transaction, simultaneous payout, final settlement.

Onchain payment finality also removes a category of uncertainty that is easy to underestimate. When a payment settles onchain, it is settled. It cannot be reversed or unwound after the fact. That certainty is meaningful for multi-party arrangements: the subcontractor, the studio co-founder, the design collaborator — each of them can plan around payment as confirmed rather than payment as pending. They do not need to wait to find out if the lead has forwarded their share, because the share arrived at the same moment as everyone else's.

Setting up the link: a step-by-step walkthrough

Let's work through a concrete scenario to make this practical.

The arrangement. A brand strategy consultant — call her Marta — works with a communications agency on a monthly retainer. The agency is the client. The retainer is $6,000 (AUD ~9,300) per month. Marta works with a research analyst, Tom, who handles qualitative synthesis and earns a fixed $1,800 (AUD ~2,790) of the retainer each month. Marta keeps $4,200 (AUD ~6,510). Both Marta and Tom want payment on the first business day of each month.

When the deal terms change

A reusable link's durability depends on the stability of the underlying arrangement. When the terms change — a rate increase after six months, a shift in the subcontractor split, a new third party joining the engagement — the deal needs to be updated to reflect the new configuration. In shaka.deal, that means creating a new deal with the updated parameters and sharing the new link with the client.

This is not a limitation; it is the correct behavior. A payment link that routes according to outdated terms is a liability. The update cycle — create new deal, share new link, retire the old one — is a lightweight process that also creates a natural moment to confirm the new commercial terms with the client in writing before the next billing period opens.

Collecting payment methods at signing prevents the friction of onboarding from delaying the first invoice. The same logic applies here: agreeing on the deal structure and sharing the link before the engagement begins means that when the first billing date arrives, there is nothing left to set up. The mechanism is already in place.

The scenario where multiple subcontractors are in play

The two-party scenario above is the simplest version. Shaka.deal routes to every configured party in a single transaction, which means the same architecture scales to arrangements with three, four, or more simultaneous recipients.

Consider a project management consultant who holds a $15,000 (AUD ~23,250) quarterly engagement with a corporate client. The team behind the deliverable includes a data modeler, a workshop facilitator, and a copywriter. Their shares are agreed in the team's internal arrangement:

In a conventional payment workflow, the client pays the consultant. The consultant then initiates three separate transfers — each at different times, depending on their own bank balance and scheduling. Agencies that manage payments manually face delays, errors, and compliance risks. Inconsistent invoices and multiple currencies add friction that slows down delivery and damages freelancer relationships.

With a deal configured through shaka.deal, the client uses the deal link for each quarterly payment. All four parties receive their shares in the same transaction. The consultant is not a financial intermediary for their team. They are a project lead who happens to be the person whose name is on the client contract.

Cash flow problems rarely come from unprofitable work. They come from timing — money going out before money comes in. When the distribution of incoming payment is automated and simultaneous, the timing problem dissolves. The subcontractors are not waiting on the lead's cash position. The lead is not absorbing the gap between receiving client funds and disbursing team shares.

Practical considerations before you set up your first deal

Stablecoin denominations. Shaka.deal operates onchain on Ethereum, which means payments are denominated in stablecoins — USDC or equivalent USD-pegged assets are the most common choice for freelance and professional service arrangements. If your client relationship is entirely in fiat, there is a short conversation to have about whether they are comfortable paying in stablecoins. For many B2B clients, particularly those in technology, media, or international trade, this is a non-issue. For clients unfamiliar with the tooling, a brief explainer of stablecoin stability (pegged 1:1 to USD, price does not fluctuate) usually resolves the hesitation.

Wallet hygiene. Every party in a shaka.deal arrangement needs a wallet address. For a two-person studio, this is a five-minute setup. For a four-person team that is new to onchain tooling, there is a small onboarding step. This investment pays off immediately: every subsequent payment cycle requires zero additional setup from anyone.

Updating clients on the new mechanism. For an established client being migrated from a traditional invoicing setup, the transition pitch is simple: "Instead of sending you a new invoice each month, I've set up a payment link you can use every billing cycle. Same amount, same result, less back-and-forth." Most clients respond well to this because the friction reduction is mutual — they do not need to file a new invoice in their payables system each month either.

The administrative dividend of getting this right

The most underappreciated benefit of a properly configured reusable deal link is not the speed of the first payment. It is the cumulative time saved across twelve months of a retainer, or twenty-four months of an ongoing engagement.

A freelancer who delivers a $6,000 (AUD ~9,300) project on the first of a month and receives payment a month later has effectively provided an interest-free loan to their client. Across fifteen to twenty invoices per year, a meaningful share of annual earnings can sit permanently in transit — inaccessible, uninvested, and creating cash-flow pressure that affects every financial decision the freelancer makes.

When the payment mechanism is resolved once at the start of an engagement, the billing cycle becomes genuinely low-maintenance. There is no invoice to prepare, no PDF to attach, no follow-up email to send when the payment is four days late and the client forgot. The link exists. The client uses it. The distribution executes. Every party has an onchain record of every transaction.

Getting paid reliably requires the right payment methods, clear terms, and prompt invoicing. The reusable deal link satisfies all three simultaneously: the payment method is pre-established, the terms are encoded in the deal configuration, and the "invoicing" step is replaced by a persistent link that does not need to be re-sent.

For repeat clients — the accounts that sustain a freelance practice over years rather than quarters — this is exactly the infrastructure worth building once and maintaining carefully. The commercial relationship already has the trust, the communication rhythms, and the established expectations. The only thing that has been missing is a payment mechanism that matches the stability of the relationship itself.

A shaka.deal link, configured with the right parties and the right shares, is that mechanism. The client reuses it. The routing executes. Every party receives their share at the same instant. That is what settlement certainty looks like in practice — not as a concept, but as a repeatable workflow that runs the same way every time, without anyone needing to chase anyone.

Summary: the configuration checklist

Before sharing a reusable deal link with a repeat client, confirm the following:

• Amount is fixed. The deal link works best when the billing amount does not change cycle to cycle. Variable engagements need per-invoice links; fixed retainers and recurring packages are the right use case.
• All parties have wallet addresses. Every recipient configured in the deal needs an Ethereum wallet address. Set this up before sharing the link, not after the first payment arrives.
• Shares are agreed in writing. The deal configuration in shaka.deal is the payment implementation of a commercially agreed split. Confirm the percentage or fixed-amount breakdown with all parties before encoding it.
• The link is pinned somewhere durable. Email threads get buried. Drop the link in a shared workspace, a project channel, or an onboarding document the client will reference at the start of each billing period.
• A process exists for updating the deal when terms change. Rate reviews, team composition changes, and scope expansions are all reasons to create a new deal configuration. Build that update step into the engagement review process so it does not catch anyone by surprise.

The administrative overhead of getting a reusable payment link right is concentrated entirely at the beginning. Once the deal is configured and shared, it works. Billing becomes the moment a client uses a link they already have — and every configured party receives their share, simultaneously, with finality.