Recurring payments in cryptocurrency have been one of the most persistent challenges in Web3. Traditional finance relies on tokenized payment methods linked to user accounts — credit cards set up once through Stripe or PayPal, then charged automatically each month. Replicating that model on-chain requires solving three problems simultaneously: how to authorize token spending without repeated user signatures, how to schedule and execute payments reliably, and how to handle failed transactions when a wallet lacks sufficient balance. The combination of ERC-20 allowances, account abstraction, and smart contract subscription logic provides a working answer to all three.
A crypto recurring billing subscription smart contract ties these primitives together into a system where merchants can bill customers periodically, customers retain granular control over what gets spent and when, and the execution happens without constant manual intervention. This guide covers the architecture, implementation details, and operational considerations for building such a system.
Why Native Token Approvals Fall Short
ERC-20 tokens provide a straightforward approval mechanism through approve() and transferFrom(). A user approves a spender’s address up to a certain amount, and the spender can pull funds from the user’s wallet. This works for single transactions but breaks down for recurring billing because approvals are static — they do not expire automatically, cannot enforce time-based limits, and require the user to manually revoke and re-approve if spending caps change.
| Problem | Impact on Recurring Billing |
|---|---|
| No built-in expiration | Users must actively revoke permissions; stale approvals become security risks |
| Flat allowance cap | Cannot enforce daily or monthly spending limits without off-chain tracking |
| Manual signature per transaction | Defeats automation if users sign every charge |
| No retry logic on failure | Insufficient balance means missed payments with no automatic resubmission |
These limitations drove the development of more sophisticated permission models and account-level abstractions that treat spending authority as a programmable, revocable, and time-bound resource rather than a simple boolean approval.
Account Abstraction as the Execution Layer
Account abstraction (EIP-4337) separates transaction validation from key ownership. Instead of an externally owned account signing every operation, a smart account contract validates whether a call should execute based on rules encoded on-chain. This shift enables several capabilities critical for subscription billing.
Smart accounts can batch multiple calls into a single user operation, sponsor gas fees through paymasters, and validate custom authorization logic before execution. When combined with advanced permission standards like ERC-7715, the system gains the ability to grant fine-grained execution rights to a dapp or merchant — permissions that specify exactly which token, how much, and over what time window.
The flow works as follows:
- User grants a session account permission through their smart wallet interface
- Permission metadata includes token address, periodic amount, duration, and expiry
- The session account redeems this permission by calling the DelegationManager contract
- The DelegationManager validates the permission context and allows the transfer to proceed
- Gas is handled independently — either paid by the session account or sponsored by a paymaster
This removes the need for the user to sign individual transactions while preserving cryptographic verification that each charge falls within the granted bounds.
Permission Types for Periodic Transfers
Not all recurring billing scenarios require the same permission structure. The choice depends on whether the merchant needs flexibility to adjust amounts, whether the token is fixed or variable, and how much control the user wants over execution timing.
ERC-20 Periodic Permissions
The most common pattern for subscriptions. The user specifies a token address, an amount per period, and the period duration in seconds. For example, granting 10 USDC per day over a 30-day window gives the merchant a predictable budget without exposing the full wallet balance.
| Parameter | Description | Example Value |
|---|---|---|
| tokenAddress | ERC-20 contract address | 0x1c7D4B196Cb0C7B01d743Fbc6116a902379C7238 |
| periodAmount | Maximum spendable per period (in token decimals) | 10000000 (10 USDC with 6 decimals) |
| periodDuration | Length of each billing cycle in seconds | 86400 (24 hours) |
| expiry | Unix timestamp when permission expires | 1730678400 |
| isAdjustmentAllowed | Whether the spender can modify remaining quota | true |
The isAdjustmentAllowed flag determines whether the merchant or session account can redistribute unused portions of a period across future windows. Setting it to false locks the allocation strictly to the defined period.
Native Token Permissions
For gas-token billing or platforms that operate on chain-native currency, native token permissions work similarly but use ETH or the chain’s base token instead of an ERC-20 contract. The permission structure remains identical — amount, duration, expiry — but the execution path bypasses the token contract and interacts directly with the balance.
Custom Permission Logic
Advanced implementations encode bespoke rules into the permission itself. Examples include conditional triggers (charge only when a specific on-chain event occurs), volume-based discounts (reduce per-period amount after cumulative spending exceeds a threshold), or multi-token budgets (allocate from a pool of different tokens). These require custom DelegationManager implementations or extension modules layered on top of the base permission framework.
Smart Contract Subscription Architecture
The subscription contract serves as the orchestrator between permissions, transfers, and merchant accounting. It does not hold user funds directly — instead, it monitors permission state, schedules execution attempts, and records payment outcomes.
Permission Registry — Stores active permission contexts mapped to user addresses, including period start times, remaining quotas, and expiry timestamps. When a permission is redeemed, the registry updates the consumed amount and checks whether the next period has begun.
Scheduler Module — Runs on-chain or via off-chain relayers to trigger billing events. On-chain schedulers use block-number or timestamp conditions to fire charges. Off-chain relayers monitor the registry and submit user operations when conditions are met.
Payment Ledger — Records each attempted and successful charge, linking it to the permission context used, the transaction hash, and the outcome. Failed charges due to insufficient balance or expired permissions are logged separately so merchants can trigger retries or notify users.
Refund Handler — Processes overpayments or cancelled subscriptions by initiating reverse transfers. Since account abstraction supports batched operations, refunds can be executed alongside other user operations without requiring separate authorizations.
Operational Considerations
Building the system is distinct from running it reliably at scale. Several practical concerns emerge during deployment.
Retry Mechanics — Subscriptions fail when wallets lack sufficient balance. A robust system implements exponential backoff with configurable maximum retry attempts. Failed charges should be recorded and optionally reported through webhooks so merchant dashboards stay accurate.
Permission Revocation — Users must be able to revoke permissions immediately. The DelegationManager contract should support instant invalidation regardless of active periods. Smart wallet interfaces typically surface this as a one-tap revoke button.
Gas Management — Even with paymaster sponsorship, there are cost considerations. Batched user operations reduce per-transaction gas overhead. Scheduling multiple charges within a single user operation window minimizes total network fees compared to submitting independent transactions.
Cross-Chain Deployment — Most recurring billing currently happens on Ethereum L2 networks where gas costs are manageable. Deploying the same subscription logic across chains requires maintaining parallel permission registries and coordinating cross-chain message passing for unified user experiences.
Security Model
The permission-based approach fundamentally changes the attack surface compared to traditional recurring billing. Merchants never custody user funds. They receive authorization to pull specific amounts within defined boundaries, and every execution is cryptographically verified against the granted permission context.
Key security properties:
- No fund custody — Tokens move directly from user to merchant; the subscription contract never holds balances
- Granular authorization — Each permission specifies exact token, amount, and time window; excess access is impossible
- Instant revocation — Users cancel permissions immediately; previously granted authority does not persist
- On-chain auditability — Every redemption and charge is recorded on-chain with permission context, enabling full transaction history verification
The primary risk vectors center around the DelegationManager contract itself and any custom permission logic extensions. Audits should focus on permission validation functions, quota tracking arithmetic, and edge cases around period boundary transitions where double-charges could theoretically occur if the scheduler misfires.