# How to set up recurring payments onchain

How ongoing recurring payments work onchain, how to arrange repeat collection, and how it compares to a card subscription.

---


## How to set up recurring payments onchain
If you run on retainers, monthly advisory fees, phased disbursements, or any engagement where money moves on a schedule rather than all at once, you already know that the back half of the payment problem — actually collecting — rarely runs as cleanly as the deal itself. Recurring payments in traditional rails carry a quiet operational tax: cards expire, ACH batches clear on a two-day lag, and a client who agreed to everything in writing can still reverse a charge weeks after you delivered. Onchain recurring payment infrastructure has matured to the point where it solves most of those frictions directly, but it works differently from a card mandate — and understanding that difference is the whole game. This article explains how onchain recurring payments actually work, where they fit into a deal professional's payment stack, and what you need to configure before the first cycle runs.

## The core problem: blockchains are push-only by default

Start with the architecture, because everything downstream depends on it.

Cryptocurrency networks like Bitcoin use a push-based system, meaning only the payer can create and sign a transaction to move funds out of a wallet. That is not a bug — it is a deliberate security property. No one can reach into your wallet and take money without your key. By contrast, pull-based payments, common in bank and card networks, let a merchant draw funds directly from a payer's account after an initial authorization.

The problem for anyone running a subscription or retainer model is obvious. Not many cryptocurrency systems were built to support scheduled transactions. There's no native autopay function on Ethereum or Bitcoin. So to make recurring crypto billing work, you need to layer in infrastructure — usually through smart contracts or purpose-built automation tools.

That infrastructure layer is where the interesting mechanics live, and where professionals need to understand what they're actually configuring.

## Push versus pull: why it matters for retainers and advisory fees

If you work in M&A advisory, commercial real estate, or business brokerage, your payment structure is rarely a single event. A retainer can be a single up-front sum or a series of periodic payments. In a retainer-based compensation model, clients pay an upfront fee to the agent or brokerage to secure ongoing real estate services over a specified period. This retainer fee covers various services, from consultation and strategic planning to day-to-day property management or market analysis. The cost is typically agreed upon in advance and may be paid monthly, quarterly, or annually, depending on the terms of the agreement.

Most M&A advisors charge up-front fees, sometimes called a retainer, in addition to a success fee. Some may also charge a monthly retainer. On a deal priced at $15 million with a six-to-twelve month engagement timeline, monthly retainer payments are working capital that funds the engagement. Chasing them manually every cycle — invoicing, following up, waiting for wire confirmations — is a distraction that earns you nothing and costs real time.

The card pull model solves this problem in consumer billing. Pull payments streamline recurring transactions by automating the payment collection process, eliminating the need for manual intervention or authorization from the payer. But one major drawback of pull payments is the risk of chargeback fees. Since these payments are initiated by your business, often for recurring subscriptions or ongoing services, customers may dispute them if they forget about the charge or struggle to cancel. This type of "friendly fraud" can result in costly chargebacks, even when the payment was entirely legitimate.

Onchain recurring payments replace this dynamic. In crypto subscriptions, payments are irreversible once confirmed on the blockchain. Stablecoin transfers are final on confirmation. There is no chargeback in the card-network sense, no 60-180 day dispute window, no scheme to file a claim with. For a professional whose fees are governed by a signed engagement letter, that finality is exactly the right behavior.

## How the smart contract authorization actually works

The mechanism that makes pull payments possible onchain is a pre-authorized spending approval. The payer signs once, granting a smart contract permission to withdraw a defined amount at defined intervals. After that, execution is automatic.

A customer authorizes a smart contract to pull a specific amount of crypto from their wallet on a recurring basis, and payments are then executed automatically, without manual approval each time.

Key parameters include an "allowance" — say, $10,000 per month — and a maximum spend limit covering the full engagement. Setting these correctly is crucial. For example, if both limits are set to the same value, the subscription will fail after the first charge because the lifetime limit is immediately exhausted.

This is a detail worth sitting with. If you are setting up a six-month advisory retainer at $8,500 per month, your per-cycle allowance is $8,500 and your lifetime cap should be at least $51,000. Misconfigure the lifetime cap and the second payment fails silently. The client's authorization is still in place; the contract simply has nothing left to draw.

Recurring delegations let a user authorize a delegate to pull up to a fixed amount on a repeating schedule — say, $500 every two weeks — with the cap resetting each cycle. The user sets the terms, not the merchant. That last point is important for the professional relationship: the client controls the authorization, can revoke it, and can set the ceiling. This is not a blank check. It is a scoped mandate.

Both methods use spend permissions, an onchain tool that lets you grant and revoke spending rights to an application. This mechanism ensures user control, allowing you to cancel permissions at any time.

## The stablecoin question

Recurring payments denominated in native cryptocurrency — ETH, SOL, BTC — create a pricing problem that no retainer agreement can survive long. If you bill $10,000 per month and the asset moves 20% in a week, someone is getting hurt. The market answered this years ago.

To avoid price volatility, most recurring crypto payments use stablecoins like USDC or USDT. This ensures that a subscription priced at $29.99 per month remains consistent, regardless of market fluctuations. These stablecoin-based subscriptions combine the benefits of blockchain speed — settling in minutes instead of days — with predictable pricing for everyday services.

For professionals working in dollar-denominated deals, USDC on a low-cost chain is effectively a dollar-denominated wire that settles in seconds rather than days. Stablecoin settlement on blockchain is near-instant. On Base, a USDC transfer settles in approximately two seconds. Stablecoin settlement is the moment a stablecoin transaction becomes final and irreversible, discharging a financial obligation between two parties. Instead of moving funds through correspondent banks, clearing houses, or batch processing windows, two parties settle directly using a dollar-pegged token on a blockchain. Once the network confirms the transaction, it is done. There is no separate clearing step waiting in the background.

Compare that to an ACH pull, which takes one to three business days to settle and can be reversed during that window. Or a wire, which requires the client to initiate, confirm, and execute on their end for every cycle. The operational efficiency argument for stablecoin recurring payments is not about ideology; it is about reducing friction on both sides of the payment relationship.

## Two models: fully onchain versus scheduled infrastructure

Not all recurring payment systems are built the same way. Understanding the architecture matters when you are deciding what to recommend to your clients.

### Fully onchain model

On-chain recurring payments rely entirely on smart contracts. These contracts automatically execute payments based on the parameters you approved. Each transaction is recorded on the blockchain, ensuring transparency. However, these payments require network gas fees, which can vary. On Layer 2 networks like Base, gas fees can be as low as under $0.01.

In this model, every cycle produces an onchain transaction with a hash, a timestamp, and a block reference. There is no ambiguity about whether a payment happened, when it happened, or how much moved. Onchain transfers are timestamped, irreversible, and transparently and permanently recorded, improving reconciliation and risk analytics.

For a closing attorney managing disbursement schedules, or an advisor whose monthly fee is supposed to come before a client makes any additional capital calls, this audit trail is worth more than the marginal infrastructure complexity.

### Off-chain scheduled model

Off-chain systems handle scheduling differently. In this approach, a payment processor holds scheduling logic in a centralized backend, monitors balances, and pushes individual transactions at the configured intervals. The settlement still lands onchain, but the trigger is centralized.

Your customers authorize recurring payments via their crypto wallets, and the platform collects payments automatically. It sends timely reminders and checks customer wallet balances in advance to ensure a high collection rate.

Subscriptions remain active until the buyer cancels, the mandate is revoked, or if the wallet lacks funds — ensuring a consistent and reliable payment process.

The practical difference for a dealmaker: fully onchain models require the client to sign a smart contract authorization once, after which the code runs autonomously. Centralized scheduling platforms may give you a more familiar interface and handle retries when balances are low, but they introduce a dependency on the platform's uptime and business continuity. For a high-value engagement with a sophisticated client, either model works. For a client who is new to onchain payments, the centralized platform's notification logic and balance reminders reduce the operational friction around failed cycles.

## What fails and what doesn't

The failure modes for onchain recurring payments are different from card failures, and they are worth spelling out clearly before you structure an engagement around this rail.

Crypto payments shift how failures are handled. With traditional credit cards, payments can fail due to expired cards or blocked transactions, and chargebacks can lead to fraud risks for merchants. In crypto subscriptions, payments are irreversible once confirmed on the blockchain. Failures typically occur only if there's an insufficient wallet balance or a spike in network gas fees.

There is no "card expired" problem. There is no bank decline. There is no issuer deciding that a recurring charge looks suspicious. The two failure conditions are an empty wallet and, on high-congestion networks, a gas fee spike that makes a small transaction uneconomical. The first you can address with balance monitoring; the second is largely solved by choosing a Layer 2 network for day-to-day recurring billing.

Card expirations trigger involuntary churn. Network declines from issuing banks reject otherwise valid charges. Chargebacks create revenue reversals weeks after settlement. None of those exist in the onchain model. What does exist: if a client revokes the spending authorization before a cycle runs, the payment simply does not execute. That is an explicit revocation, not a silent failure — and it surfaces in your monitoring the same day rather than after a chargeback dispute weeks later.

## Configuring a recurring payment for a professional engagement

Here is what a properly structured onchain recurring engagement looks like in practice.

**Define the schedule parameters explicitly in the engagement agreement.** The amount per cycle, the total number of cycles, the stablecoin denomination, and the network. These should appear in your engagement letter the same way wire instructions do. Monthly retainer of $12,000 USDC, six cycles, on Base or Polygon, collected on the first business day of each month. That specificity protects both sides.

**Have the client sign the spending authorization before work begins.** Approve a one-time wallet signature with details like amount, frequency, and recipient. Payments execute automatically after that. This is the onchain equivalent of a direct debit mandate. The client does it once and the machinery runs. If they have not signed before you begin the engagement, you have the same exposure as if you started a project before a wire cleared.

**Set your allowance parameters correctly.** As noted above, the per-cycle allowance and the lifetime cap are separate parameters. If you are billing $12,000 per month for six months, set the lifetime cap to at least $72,000 — or higher if there is a possibility of extending the engagement. A cap set to exactly the first cycle terminates the authorization on the first draw. A cap set too low creates a mid-engagement payment failure that looks like a client decision when it was a configuration error.

**Choose the right chain for the volume.** For retainers in the $5,000 to $50,000 per month range, a Layer 2 network like Base or Polygon eliminates gas fees as any kind of concern. On Layer 2 networks like Base, gas fees can be as low as under $0.01. On Ethereum mainnet, a single transaction might cost several dollars on a busy day — negligible for large transactions, but noisy on a monthly billing statement.

**Set up balance monitoring.** If you are relying on a centralized billing platform, it will typically do this for you. Platforms that handle this well ensure buyers' wallets have enough funds before each payment due date. If you are running a more custom setup, the client should receive an alert when their wallet balance drops below two months of billing coverage. A payment that fails because of an empty wallet is not a dispute — it is a cash flow problem — and the sooner it surfaces, the cleaner it resolves.

## Recurring payments versus one-time payment links

These are not the same tool, and they are not interchangeable. A one-time payment link — the deal-closing disbursement where funds move once to multiple wallets simultaneously — is structurally different from a recurring billing arrangement. The link is an event; the recurring authorization is a relationship.

The professional frictions are also different. One-time disbursements fail because parties are not ready simultaneously, wallets are misconfigured, or splits are contested. Recurring payments fail because of balance problems, authorization expirations, and poorly set lifetime caps. Diagnosing and managing those failures requires different monitoring and different client communication.

For professionals who run both a retainer structure and a closing disbursement in the same engagement, the right answer is to use both tools in the right sequence. The recurring billing authorization covers your monthly engagement fees throughout the deal process. The closing disbursement — where everyone who has a stake in the deal's proceeds gets paid simultaneously, automatically, in a single transaction — is a separate event with a separate structure. Shaka handles the latter: the professional configures the deal, sets the recipient wallets and the split percentages, and when the deal closes, every party is paid directly and simultaneously. The recurring retainer was the infrastructure that kept your engagement funded. Shaka is how the final money lands.

## What the authorization lifecycle looks like from the client's side

Clients who have never signed an onchain spending authorization sometimes treat it as a bigger commitment than it is. It helps to walk them through what they are actually agreeing to.

They sign once, from their wallet, authorizing a smart contract to withdraw a specific amount at a specific interval up to a specific total. The authorization is scoped — it cannot be used to withdraw more than the per-cycle amount, and it cannot run past the lifetime cap. Subscription plans let a merchant publish fixed pricing tiers on-chain, with the terms locked in when a user subscribes. Funds are pulled automatically each cycle. If the terms need to change, the old plan is retired and a new one is created, so existing subscribers keep their original terms.

If the engagement extends and you need to add cycles or increase the monthly amount, the original authorization does not stretch to cover the new terms. The client signs a new authorization reflecting the new parameters. This is actually a feature for the professional relationship: any change to billing terms requires an explicit client action. There is no ambiguity about whether a fee increase was authorized.

If the client wants to terminate early, they revoke the authorization from their wallet. The revocation is immediate and permanent. Any cycle that executed before the revocation is already settled and irreversible. Any cycle that had not yet executed will not. This is cleaner than the traditional dispute — the client takes a deliberate onchain action, and the record is unambiguous.

## The tax and record-keeping dimension

Onchain transactions produce a permanent, timestamped, public record of every payment. Unlike ACH or SWIFT, there is no separate settlement step. The transfer is the settlement. Once confirmed on-chain, the payment is final and irreversible. The transaction is recorded on an immutable ledger with a unique hash, timestamp, and any attached memos. This simplifies matching payments to invoices.

For professionals who manage retainers across multiple clients and multiple engagements simultaneously, this matters more than it might seem at first. Every cycle produces a transaction hash you can reference in your accounting. There is no "the wire never arrived" problem and no "the ACH batch is still processing" ambiguity. The payment either confirmed or it did not, and you can verify that from any block explorer in seconds.

USDC settlement produces on-chain receipts with cryptographic finality. These can be fed directly into treasury management systems via API, eliminating manual reconciliation delays. For a brokerage or advisory firm managing multiple retainer relationships, that API integration means your bookkeeping can stay current in near-real-time without someone manually matching wire references to invoices.

## The practical decision: when does recurring onchain billing make sense?

Not every payment relationship needs a recurring onchain structure. If a client pays a single retainer at engagement inception and then a success fee at closing, a payment link handles both moments cleanly without any subscription architecture. Recurring onchain billing earns its complexity when three conditions are present: the engagement runs for multiple months, the monthly amount is material enough that collection delays or reversals create real cash flow exposure, and both parties are comfortable holding and transacting in stablecoins.

For a commercial real estate broker running a six-month tenant representation on a complex 50,000 square foot lease, or an M&A advisor on a $20 million sell-side mandate who charges monthly against a success fee, the recurring onchain model pays for itself in eliminated friction. The retainer model provides agents with a stable and predictable income stream, regardless of the number of transactions completed. This stability is particularly beneficial for agents working with long-term clients or in advisory roles. The onchain version of that model delivers the same stability without the payment infrastructure risk that lives in the traditional version.

The best-run deal practices do not treat payment architecture as an afterthought. They configure it at engagement inception, confirm it before work begins, and let it run in the background while they focus on the deal. Every month the retainer clears without an email or a phone call is a month that capital earned its way to the professionals who earned it — automatically, on schedule, with a permanent record that no one can dispute.