An onchain subscription needs a clear answer to who can move funds, how much they can move and when that authority ends. A customer agreeing to a monthly service may see one authorization screen, while the underlying token approval permits a broader set of movements. The product's promise and the technical permission should be reviewed together before either reaches production.
The operating design also needs to cover a cancelled subscription, a price change, an insufficient balance and a retry following uncertain execution. These are ordinary billing events. Their treatment should be explicit in the authorization process rather than improvised after the first disputed debit. This article examines recurring collection controls, using primary Ethereum standards checked on 7 October 2026.
Distinguish the agreement from the spending permission
A commercial mandate records the service, the billing interval, the pricing terms, the customer's consent and the cancellation process. A technical permission determines what a spender can do with a token balance. Those records are related, but they are not interchangeable. A system can hold a valid spending permission after the commercial subscription has ended.
The ERC-20 standard defines an allowance for a spender and a transferFrom mechanism. It does not define a subscription interval, invoice approval or recurring payment agreement. A collection service built on that mechanism needs additional controls connecting each intended debit to an active bill.
Document the actual spender address and its role. It may be a merchant contract, a service contract or another component. Identify who can change that component's behavior and which controls constrain it. A familiar application name on a screen should not be the only evidence that the customer is authorizing the intended contract.
Store the version of the agreement that supported the initial permission. If pricing or scope changes, record which changes need renewed consent under the product's process. Billing operations should be able to demonstrate that the current charge follows the agreed terms without treating a remaining allowance as blanket approval.
Review the authorization mechanism precisely
Signed approvals can reduce the need for a separate approval transaction, but the details matter. ERC-2612 defines permit with an owner, spender, value, nonce and deadline. Its deadline limits when the signed approval can be submitted. It is not a general expiry date for the allowance created by that approval.
That distinction should appear in the product's review. If the customer is promised that authority expires after a period, the system needs a mechanism that enforces that promise. A short signature-submission deadline does not satisfy it. The payment service might enforce an expiry internally, or a contract might implement additional checks, but reviewers should verify the deployed behavior.
ERC-3009 describes transfer authorizations containing a recipient, amount, validity window and unique nonce. It also specifies an optional cancellation extension. A system using that design should check which functions the selected token implements rather than assuming every compatible-looking token offers identical authorization or cancellation behavior.
One signed transfer authorization is not a complete recurring billing system. The product still needs to decide how future bills receive authority and how changed prices are handled. Keep the authorization scope visible: one payment, a bounded series, or a spender allowance governed by additional controls. The customer experience should communicate the scope the system actually enforces.
Set limits that follow the bill
Define the maximum amount per collection, the relevant billing period and any cumulative limit. A limit stated in the commercial agreement should map to a control in the execution path. If a monthly amount can be collected twice by two independent workers, a per-transaction ceiling alone will not enforce the intended monthly maximum.
Choose how variable bills work. A fixed recurring amount, a capped usage bill and a separately approved invoice each require a different collection rule. Record the source of the calculated amount and the bill version. For usage-based services, the authorization system should receive the approved bill rather than independently guessing the usage total.
Consider the relationship between allowance and funds held. A high allowance can remain in place while the customer's balance grows. The amount visible when the mandate was created may therefore be a poor measure of the authority available later. Assess the permission's scope over its lifetime, including how the spender could use it after an application change.
Our discussion of smart accounts and account abstraction provides context for account-level controls. Whatever architecture the product chooses, reviewers need evidence that the intended limit is enforced at the point where funds can move. A policy written in a dashboard is useful only if execution follows it.
Give cancellation two clear outcomes
Cancellation has a billing outcome and a permission outcome. The customer may cancel future service while leaving a token allowance in place, or revoke an allowance while a final bill remains open. Explain those states separately in the product. Operations should know whether collection has stopped, whether the technical authority is removed and whether any already authorized payment remains executable.
Define an effective cancellation time and the treatment of work already in progress. A bill prepared before cancellation may reach execution afterward. The service needs a controlled decision at that boundary, based on the agreement and the system's state. Record the timing evidence so support can explain which instruction was created and which authority was used.
If revocation requires a network transaction, show its pending and completed states clearly. A click in the application should not be described as completed revocation before the relevant execution evidence exists. If the product offers immediate internal suspension while onchain revocation is pending, identify that separate control and test whether every collection worker respects it.
Provide a recovery route for customers who cannot use the original interface. A permission should not depend on the continued availability of one website for its holder to understand or manage it. Document the supported process in a form that operations and customer support can retrieve during an outage.
Make retries subordinate to one billing intent
Assign each bill a durable collection intent. Link prepared authorizations, provider requests and network submissions to that intent. A timeout, a late event or a manual repair should not create another bill. The system should inspect the existing outcome before it decides whether another attempt is necessary.
Control retries across workers and channels. A scheduled collector and a support agent may each see an unpaid invoice while the first transfer remains pending. Both should reach the same authoritative state before acting. Use locking or equivalent execution controls appropriate to the architecture, with an explicit process to release a stuck intent.
Preserve the distinction between a used nonce and a paid invoice. Nonce protection can prevent reuse of a particular signed instruction. It does not automatically stop two different authorizations for the same bill. Business-level duplicate protection should therefore operate above the individual signature or transaction.
Track the reason for each unsuccessful attempt. Insufficient funds, an expired authorization, revoked allowance, a contract pause and a network submission error lead to different customer messages. A generic failure notice can push the customer into making a second manual payment while an automatic attempt remains live.
Handle upgrades as changes to payment authority
A collection contract upgrade, new spender address or supported-token change can alter the meaning of an existing mandate. Create a change review that covers the agreement, the customer authorization and the execution controls together. Do not assume that because a bill looks unchanged, the payment authority is unchanged.
Record which mandate versions can use each execution component. If an old contract remains callable, determine whether existing permissions remain usable and how the organization stops collections through it. A migration plan should account for active, suspended and cancelled subscriptions, with evidence that the system does not collect through two paths.
Our article on programmable payment exceptions addresses the ownership needed when automation reaches a boundary. In subscriptions, that owner needs authority to suspend collection, investigate the bill and authorize the supported correction. Sending the customer to a technical help desk should not be the entire exception process.
Keep an evidence chain for every debit
A collection record should connect the active mandate, the approved bill, the permission used and the completed transfer. Preserve cancellation events and later corrections alongside it. The record should answer why the payment was permitted, not merely show that a contract accepted it.
Test a cancelled mandate, a changed price, two simultaneous attempts, a delayed submission and an unavailable application interface before expanding the service. Review the result with billing, security and operations together. A recurring payment product earns its operating credibility when those teams can explain and control the unusual bill as readily as the routine one.