Recurring Payments in Web3 via Account Abstraction (ERC-4337): Session Keys, Paymasters, Risk Limits, and Refunds on Polygon/zkEVM

Recurring payments are the backbone of today’s digital economy. From Netflix and Spotify subscriptions to SaaS licenses and Patreon donations - the modern Web2 ecosystem thrives on the ability to automatically charge users at regular intervals.

In Web3, however, this fundamental mechanism is still missing. Traditional blockchain wallets require manual confirmation for every single transaction. Each time a user wants to pay for a subscription, they must open their wallet, approve the transfer, and pay gas fees. There’s no native way to schedule, automate, or delegate payments on-chain.

This lack of automation not only creates a poor user experience but also limits the potential for subscription-based business models in decentralized ecosystems. For Web3 to reach mainstream adoption, it must offer the same seamless financial flows users expect from Web2 - but with the added benefits of transparency, security, and self-custody.

Account Abstraction (ERC-4337) introduces the missing layer of programmability. Turning wallets into smart contracts allows developers to design secure, gasless, and automated payment flows, paving the way for true recurring payments in Web3.

Why Standard Wallets Can’t Handle Recurring Payments

Most Web3 users today interact with Externally Owned Accounts (EOAs) - wallets like MetaMask or Trust Wallet that are controlled directly by a private key. EOAs are simple and secure, but they come with major limitations that make recurring payments impossible by design.

Every action on-chain must be initiated and signed manually by the wallet owner. There is no built-in logic that allows an account to schedule future transactions, authorize automatic transfers, or react to time-based events. The blockchain simply executes what is explicitly signed - nothing more.

This means that:

• Each subscription renewal requires a new user signature.

• Gas fees must be paid manually for every transaction.

• Users cannot delegate permission to a service or smart contract to act on their behalf.

From a user experience perspective, this is like needing to manually re-enter your credit card details every month to keep your Netflix account active.

Developers have attempted workarounds - such as centralized off-chain schedulers or token approvals with unlimited allowances - but both approaches come with trade-offs. Off-chain automation reintroduces centralization and trust, while unlimited approvals pose significant security risks.

To truly enable trustless, automated payments, we need a wallet model that can execute logic autonomously - while still preserving user control and security. This is exactly what Account Abstraction (ERC-4337) makes possible.

Account Abstraction and ERC-4337

Account Abstraction (AA) is one of the most significant architectural evolutions in Ethereum. It redefines how wallets work by transforming them from externally controlled accounts into programmable smart contracts. In this model, the wallet itself becomes logic-based, not key-based.

At its core, ERC-4337 introduces a new layer that separates transaction creation from transaction execution. Instead of directly sending signed transactions to the blockchain, users create UserOperations - flexible instructions that describe what they want to do. These operations are then collected, validated, and executed by a special off-chain actor called a Bundler.

Here are the main components of the ERC-4337 ecosystem:

• Smart Account (or Smart Contract Wallet) - the user’s programmable wallet that defines custom logic for validation and execution of transactions.

• EntryPoint Contract - a shared on-chain contract that acts as the gateway for all UserOperations, ensuring standardized execution.

• Bundler - an off-chain service that aggregates multiple UserOperations into a single transaction and submits it to the EntryPoint.

• Paymaster - an optional module that can pay gas fees on behalf of users, enabling gasless or token-based transactions.

This modular design allows for flexible and user-friendly payment flows. For example, a developer can program a wallet that automatically authorizes a transaction every 30 days or uses a Paymaster to cover gas fees for subscription renewals.

With ERC-4337, recurring payments no longer require constant user interaction or centralized intermediaries. Instead, the wallet itself becomes an intelligent agent capable of enforcing predefined rules - securely and autonomously.

Architecture of Recurring Payments via Account Abstraction

To enable recurring payments on-chain, we can combine several ERC-4337 components into a modular system that mimics traditional subscription logic - but in a decentralized and trustless way.

At a high level, the flow looks like this:

1. The user deploys or connects to a Smart Account (an ERC-4337 wallet).

2. The user grants permission for periodic payments - defining parameters such as recipient, token, amount, and frequency.

3. A Subscription Manager smart contract stores and manages these authorizations.

4. A Bundler periodically submits UserOperation to execute the payment when it’s due.

5. A Paymaster covers the gas cost, allowing the user to pay entirely in tokens (for example, USDC) without worrying about ETH balances.

6. The merchant’s Payment Receiver Contract collects the funds, optionally emitting an event or NFT receipt for the subscription cycle.

Each component has a clearly defined responsibility:

• Smart Account - stores user rules and authorizations for recurring transfers.

• Subscription Manager Contract - holds subscription data (amount, token, schedule, status) and verifies timing and limits.

• Bundler Service - acts as an executor, checking due payments and triggering the operations.

• Paymaster - ensures the user doesn’t need ETH for gas, making the experience frictionless.

• Merchant Contract - receives and records incoming payments securely on-chain.

This design ensures full automation while maintaining decentralization. The wallet logic, not an external server, decides when and how payments occur. Every transfer is executed transparently through on-chain contracts and recorded immutably.

Such architecture enables true Web3-native subscription models - from SaaS and content platforms to DAO memberships and on-chain services. Users can pre-authorize payments safely, while developers can build fully autonomous billing systems that never require manual confirmations.

Transaction Flow (Step-by-Step)

The recurring payment process in an ERC-4337-based system follows a clear and transparent cycle that ensures automation, security, and full user control.

First comes the initialization phase. The user creates or connects to a Smart Account that supports ERC-4337. Through a dApp interface, they configure their subscription by specifying the recipient (merchant), payment token (for example, USDC), amount, frequency (for instance, every 30 days), and a maximum spending limit or authorization period. This data is stored in a Subscription Manager smart contract, and the user signs an initial authorization with their Smart Account to confirm the setup.

Next is authorization and scheduling. The Smart Account contains validation logic that allows it to approve future transactions automatically, under specific conditions defined during setup. Instead of manually signing each payment, the wallet relies on an off-chain scheduler managed by a Bundler or automation service such as Gelato or Chainlink Automation. Each upcoming payment is represented by a UserOperation object that includes the subscription ID, execution time, and payment parameters.

When the payment date arrives, the execution phase begins. The Bundler packages the pending UserOperation and submits it to the EntryPoint contract. The EntryPoint validates the operation through the user’s Smart Account logic, checking the signature, balance, and timing before executing the payment via the Subscription Manager. Funds are transferred directly from the user’s wallet to the merchant’s contract. If the account lacks sufficient balance or authorization, the transaction automatically fails, preventing any unauthorized charges.

Gas fees are handled through an optional Paymaster component. The Paymaster can cover the transaction fees on behalf of the user, enabling a gasless user experience where payments are made entirely in tokens like USDC without needing ETH. The Paymaster can later be reimbursed by the merchant, the protocol, or through a small recurring service fee.

Finally, the user retains complete control through cancellation and management features. They can revoke authorization, pause or delete their subscription, or modify payment limits and frequency at any time. All permissions and operations are recorded on-chain, ensuring full transparency and preventing overcharging or hidden renewals.

In this structure, ERC-4337 enables autonomous, verifiable, and user-controlled recurring payments. No centralized intermediary is required, and the logic of each subscription is enforced by the wallet itself - making decentralized subscriptions both practical and secure.

L2 Data Availability Layer: A Comparison of Celestia, EigenDA, and Avail Read

Technical Implementation Details

Implementing recurring payments with ERC-4337 requires combining several technical elements: smart accounts, a subscription management contract, a bundler or automation layer, and optionally a Paymaster to handle gas fees. Together, they create a system that feels as seamless as Web2 billing but operates entirely on-chain.

At the center of this design is the Smart Account, which replaces the traditional externally owned account. Instead of using a private key for every transaction, the Smart Account defines a function validateUserOp() that determines when a UserOperation can be executed. This allows developers to embed logic such as time checks, spending limits, and authorization rules directly inside the wallet contract.

A UserOperation is a data structure that represents a transaction request under ERC-4337. It includes fields like the sender address, call data, nonce, gas limit, and a signature or proof that the operation is valid. When a recurring payment is due, the Bundler prepares a UserOperation that calls the executePayment() function of the Subscription Manager contract on behalf of the user.

The Subscription Manager smart contract acts as the controller of all subscription logic. It stores details such as the payer, receiver, token address, amount, frequency, next payment date, and status. Before executing any transfer, it checks that the current block timestamp is greater than or equal to the next scheduled payment and that the user’s Smart Account confirms the operation through its validation logic.

Here is a simplified conceptual snippet showing how a recurring payment might be triggered:

function executePayment(uint256 subscriptionId) external {
    Subscription storage sub = subscriptions[subscriptionId];
    require(block.timestamp >= sub.nextPayment, "Too early");
    require(sub.active, "Inactive subscription");

    IERC20(sub.token).transferFrom(sub.payer, sub.recipient, sub.amount);
    sub.nextPayment = block.timestamp + sub.interval;
}

This function ensures that payments happen only when scheduled and that each transfer is fully authorized.

To improve usability, developers can integrate Permit2 (by Uniswap) or EIP-2612 tokens. These standards allow token transfers to be pre-approved through cryptographic permits rather than repeated approve() calls, reducing the number of required interactions.

The Paymaster plays an important role in improving UX. It can sponsor gas fees for the user, allowing the transaction to be executed even if the Smart Account has no ETH. In many cases, the merchant or dApp operator funds the Paymaster, making the subscription process feel frictionless and familiar to Web2 users.

For automation, services like Gelato Automate, Chainlink Automation, or custom cron-based scripts can be used to monitor subscription states and submit UserOperations to the Bundler when payments are due. This ensures consistent execution without user involvement.

By combining these elements, developers can build a fully trustless and composable subscription framework: the Smart Account enforces security and authorization, the Subscription Manager coordinates timing and logic, the Bundler ensures execution, and the Paymaster abstracts away gas costs. The result is a payment experience that mirrors the convenience of Web2 recurring billing while remaining entirely decentralized and transparent.

Security and Limitations

While Account Abstraction introduces a powerful framework for automating transactions, implementing recurring payments on-chain requires careful attention to security, trust boundaries, and operational limits. Each component in the system - the Smart Account, Subscription Manager, Bundler, and Paymaster - must be designed with clear safety guarantees to prevent abuse or unintended spending.

The first key aspect is authorization control. Since recurring payments involve pre-approved transfers, it’s essential to define strict limits: the maximum amount per transaction, total spending caps, and expiration dates for authorizations. Without these safeguards, a malicious contract could drain the user’s balance over time. Smart Accounts should verify every payment against these constraints before execution.

Another important consideration is cancellation and revocation. Users must be able to revoke permissions or deactivate subscriptions at any time. A well-designed system includes both an on-chain cancelSubscription() function and off-chain UI integration that clearly shows all active authorizations. Once revoked, no future UserOperations should be accepted for that subscription ID.

Security also depends on trust minimization between actors. The Bundler, for example, has visibility into UserOperations but cannot modify their parameters without invalidating the user’s signature. However, if a dApp relies on a single Bundler or Paymaster service, it effectively introduces a semi-centralized dependency. For production-grade systems, multiple Bundlers and decentralized relayers should be used to improve reliability and censorship resistance.

The Paymaster introduces additional attack surfaces. Since it covers gas fees, it can be exploited if attackers submit unauthorized or repeated operations. To mitigate this, Paymasters should enforce strict validation logic - such as checking whitelisted senders, subscription IDs, or even requesting proof-of-payment signatures from the Smart Account. Rate limiting and per-user quotas can further reduce risk.

Another challenge lies in token volatility and liquidity. For recurring payments, stablecoins like USDC, DAI, or EUROe are typically preferred. Using volatile assets such as ETH or MATIC could lead to unpredictable billing amounts or insufficient balances at the time of execution.

Finally, timing guarantees on decentralized networks are approximate. Automation systems like Gelato or Chainlink perform best-effort scheduling, but block time and congestion can cause slight delays. This means “monthly” or “daily” payments are not exact to the second - a small but inherent trade-off in decentralized automation.

Despite these limitations, the combination of strong validation logic, clear authorization limits, and transparent execution makes ERC-4337 recurring payments far safer than centralized billing systems. Users maintain full control, every transaction is verifiable on-chain, and no third party can unilaterally charge or modify payment terms.

Account Abstraction shifts trust from intermediaries to code - and when implemented carefully, that code can be both secure and reliable enough to power large-scale decentralized subscription systems.

Exploring the Benefits and Set-Up Process of Polygon's Edge Network with Side Chains Read

Real-World Use Cases and Prototypes

Although recurring payments in Web3 are still an emerging concept, several pioneering projects and frameworks are already demonstrating how Account Abstraction can make automated on-chain billing practical. These implementations vary in architecture and complexity, but they all share the same goal - enabling continuous, trustless payment flows.

One of the most active ecosystems in this space is Biconomy. Through its Account Abstraction SDK, Biconomy allows developers to create smart accounts with programmable permissions and integrate Paymasters for gasless transactions. Their experimental subscription demos showcase how users can authorize a recurring transfer once, while the dApp’s backend uses a Bundler to automatically execute payments on schedule. Biconomy’s model is particularly appealing for Web3 SaaS and NFT membership platforms looking to offer Web2-like convenience.

Another strong example comes from Safe (formerly Gnosis Safe), which has long provided multi-signature smart wallets. Combined with automation frameworks such as Gelato Automate, Safe accounts can be programmed to perform recurring token transfers at defined intervals. This setup has already been adopted by DAOs to automate payrolls, treasury allocations, and grant disbursements - effectively functioning as a decentralized version of corporate direct debit systems.

A related but distinct approach is offered by Superfluid and Sablier v2, which focus on streaming payments rather than discrete recurring transactions. Instead of charging users once per period, these protocols continuously stream value over time, measured by block intervals. For certain use cases - such as hourly wages, yield sharing, or pay-as-you-go subscriptions - streaming can even outperform traditional billing cycles. However, ERC-4337-based recurring payments provide finer control over scheduling, amounts, and cancellation logic, making them a better fit for subscription-style payments.

Some developers are also experimenting with Gelato Network and Chainlink Automation to handle the off-chain orchestration of ERC-4337 UserOperations. In these setups, the automation service regularly checks which subscriptions are due and submits the corresponding operation to the EntryPoint contract. This approach preserves decentralization while ensuring reliability and uptime similar to centralized schedulers.

Finally, early-stage projects such as ZeroDev, Alchemy Account Kit, and StackUp are building complete development stacks for Account Abstraction wallets. These SDKs make it significantly easier for developers to add recurring payment features without dealing directly with low-level ERC-4337 logic. They abstract away complex components like Bundlers and Paymasters, letting teams focus on user experience and business logic.

Taken together, these initiatives show that recurring payments are no longer just a theoretical use case for Account Abstraction - they are already being prototyped and deployed across multiple ecosystems. As the tooling matures and multi-chain support expands, the Web3 economy is moving closer to a world where subscriptions, memberships, and automated payouts are as seamless and reliable as their Web2 counterparts, but fully owned and controlled by users themselves.

Economic Model and UX

Recurring payments powered by Account Abstraction do more than automate transactions - they redefine how users and businesses interact economically in Web3. By removing the friction of manual confirmations and volatile gas costs, ERC-4337 makes decentralized subscriptions and pay-per-use models viable at scale.

From a user experience perspective, the benefits are immediate. A single authorization replaces an endless stream of confirmations. Users can subscribe to a service once, define their spending limits, and enjoy a truly hands-off payment flow. The integration of Paymasters allows dApps to offer gasless subscriptions, where users pay only in the native token of the service (for example, USDC or a project’s utility token) without worrying about ETH balances. This simplicity is critical for onboarding non-technical users, who often find gas fees and transaction confirmations confusing or intimidating.

Additionally, because all recurring logic is handled by the Smart Account, the experience can be tailored to the individual. Developers can offer features like:

• trial periods and automatic renewals,

• dynamic pricing based on usage or time,

• on-chain notifications or NFT receipts for each successful payment,

• transparent cancellation policies enforced directly by smart contracts.

From a business and protocol standpoint, recurring payments introduce new possibilities for monetization and revenue stability. Projects that previously relied on one-time NFT sales or token-based donations can now offer subscription-based access to premium features, content, or governance rights. DAOs can implement automated payroll systems for contributors. Infrastructure providers and DeFi protocols can charge maintenance or performance fees periodically, rather than upfront.

The economic model also evolves. Paymasters can be monetized through small service fees, or subsidized entirely to attract new users - a strategy similar to Web2’s “free trial” acquisition model. Meanwhile, Bundlers may earn micro-fees for handling transactions, forming a new layer of decentralized infrastructure providers. These actors form a mini-economy around the recurring payments ecosystem, ensuring sustainability while maintaining user sovereignty.

From a macro perspective, ERC-4337 recurring payments bring predictability to on-chain cash flows. Businesses can forecast revenue in tokens, while users maintain full transparency and control over their spending. Because every transaction is publicly verifiable, auditing and analytics become straightforward, enabling better compliance and financial reporting for decentralized organizations.

The real power of this model lies in UX parity with Web2. By combining seamless onboarding, predictable billing, and transparent automation, Account Abstraction bridges the psychological and technical gap that has long separated Web2 fintech from Web3 infrastructure. For many users, it could be the first time interacting with a blockchain feels as natural as using a traditional payment app - yet with complete self-custody and trustless guarantees.

Polygon Network: The Superior Alternative to Ethereum Read

Future Outlook and Standards

The introduction of Account Abstraction and ERC-4337 marks a turning point for how we think about payments in Web3. Yet, this is only the beginning. As the ecosystem evolves, new standards and architectures are emerging to make smart accounts even more modular, flexible, and autonomous - unlocking use cases far beyond simple recurring transactions.

One of the most anticipated developments is ERC-7579, a proposed standard for modular smart accounts. While ERC-4337 defines the infrastructure for user operations, ERC-7579 focuses on composability - allowing wallets to plug in different modules for validation, execution, security, and recovery. In practice, this means developers could install a “recurring payments module” into a wallet just as easily as adding a browser extension, without redeploying or rewriting the account logic. Such modularity will make subscription systems easier to integrate and update across chains.

Another major trend is the shift toward intent-based architecture. Instead of crafting explicit transactions, users will soon express “intents” - high-level goals like “pay this address 10 USDC every month.” Smart accounts and decentralized services will then resolve these intents automatically, finding optimal routes and execution conditions. This evolution builds directly on the principles of Account Abstraction and moves Web3 closer to fully autonomous financial coordination.

We can also expect deeper integration with Layer 2 and Layer 3 ecosystems. Rollups such as Optimism, Arbitrum, and zkSync are already implementing native support for ERC-4337, significantly reducing gas costs for smart account operations. As recurring payments rely on frequent low-value transfers, these scalability improvements will be essential for mainstream adoption.

Furthermore, cross-chain automation frameworks will emerge to handle multi-network subscriptions - for example, paying a Polygon dApp using an Ethereum smart account or managing subscriptions across rollups. Combined with decentralized identity (DID) standards and verifiable credentials, this could lead to unified, portable subscription identities that follow the user across ecosystems.

In the broader financial landscape, Account Abstraction has the potential to merge DeFi and real-world payments. Businesses could issue on-chain invoices tied to recurring smart account authorizations, while consumers could manage both crypto and fiat subscriptions through a single programmable wallet. Over time, regulatory-compliant modules and fiat on-ramps will further blur the line between Web2 and Web3 billing infrastructures.

Ultimately, recurring payments powered by Account Abstraction are more than a technical upgrade - they represent a paradigm shift in user experience and trust. By giving users programmable control over their financial relationships, Web3 can evolve from a system of isolated transactions to one of continuous, automated, and self-sovereign economic flows.

As standards mature and developer tools expand, we’re moving toward a future where subscribing, donating, or paying rent on-chain is as seamless as a single click - and where automation serves the user, not the intermediary.

Conclusion

Recurring payments are one of the missing building blocks of a mature Web3 economy. By leveraging Account Abstraction through ERC-4337, developers can finally build wallets and payment systems that match the convenience and reliability of Web2 - without sacrificing decentralization or user ownership.

This new paradigm transforms the wallet from a passive keyholder into an active, programmable financial agent capable of executing logic, enforcing permissions, and automating complex payment flows. With emerging standards like ERC-7579, modular smart accounts, and intent-based architectures, recurring payments are just the first step toward a broader transformation of how users and protocols interact financially.

At Technorely, we believe that Account Abstraction will become a foundation for the next generation of decentralized financial systems. Our team is actively exploring ERC-4337 integrations, Paymaster design, and recurring payment frameworks that combine automation, security, and a great user experience. By bridging cutting-edge blockchain infrastructure with practical business use cases, Technorely aims to make decentralized subscriptions, payrolls, and token-based billing accessible to real users and enterprises alike.

As the tools, SDKs, and infrastructure around Account Abstraction mature, seamless, gasless, and autonomous payments will become the norm. Web3 will no longer be limited by manual confirmations and fragmented UX - instead, it will offer a smooth, intelligent financial experience built entirely on open, verifiable code.

The future of payments in Web3 is not just decentralized - it’s automated, user-driven, and built by innovators shaping the ecosystem today.