Recurring Stablecoin Payments: Building Subscription Infrastructure On-Chain

The subscription economy is worth over $600 billion and growing. More than two thirds of digital-first businesses operate on recurring payment models, and SaaS companies have made monthly billing the default. Yet blockchain payment infrastructure was designed for one-time transfers: a user signs a transaction, value moves, and the interaction ends. Building recurring stablecoin payments on top of this architecture requires rethinking assumptions that traditional finance takes for granted.

With stablecoin transaction volume reaching $33 trillion in 2025 and major payment processors like Stripe launching stablecoin subscription products, the demand is clear. The challenge is engineering a system where merchants can reliably collect recurring payments without forcing users to manually approve every charge.

Why Recurring Payments Are Harder in Crypto

Traditional recurring payments operate on a pull model. When you subscribe to a streaming service and enter your card, you authorize the merchant to initiate future charges against your account. The card network, your issuing bank, and the acquiring processor collaborate to pull funds on a schedule without your involvement. ACH direct debits, SEPA mandates, and Bacs payments all follow the same pattern: the payer authorizes once, and the payee pulls funds repeatedly.

Blockchain networks are architecturally push-based. Only the holder of a private key can sign and broadcast a transaction moving funds from their wallet. No on-chain entity can reach into a wallet and withdraw funds without the owner actively signing. This is a feature, not a bug: self-custody means no intermediary has the authority to initiate debits. But it makes subscription billing fundamentally difficult.

The core tension: Pull payments require delegated authority over someone else's money. Self-custody is explicitly designed to prevent that. Every approach to on-chain recurring payments is navigating this tradeoff between convenience and control.

What Breaks Without Pull Payments

The absence of a pull mechanism creates several concrete problems for subscription businesses:

• Users must be online and manually approve each payment cycle, breaking the "set and forget" model that makes subscriptions work.
• Failed payments have no built-in retry mechanism: there is no equivalent of a dunning sequence or soft decline retry in base-layer blockchain protocols.
• Merchants cannot predict cash flow because each payment depends on the user taking action.
• There is no on-chain concept of a payment mandate, authorization capture, or pre-authorization that persists across billing cycles.

The ERC-20 Approve Pattern and Its Limits

The earliest attempt to solve recurring payments on Ethereum uses the ERC-20 approve/allowance mechanism. A token holder calls approve(spenderAddress, amount) to grant a smart contract permission to transfer up to a specified number of tokens via transferFrom(). In theory, a subscription contract could periodically call transferFrom() to collect payments up to the approved limit.

How Approve Works

The flow is straightforward: the user signs one approval transaction granting the merchant's contract an allowance. The contract then calls transferFrom(user, merchant, paymentAmount) each billing cycle, decrementing the allowance. When the allowance is exhausted, the user must re-approve.

This pattern is already used extensively in DeFi for token swaps and lending deposits. Adapting it for subscriptions means adding scheduling logic: a keeper or cron-like service that triggers the transferFrom() call at each billing interval.

Why Approvals Fall Short for Subscriptions

The allowance is a static ceiling, not a recurring schedule. There is no native concept of "100 USDC per month": a contract approved for 1,200 USDC could drain the entire amount in a single call. The approve function lacks granularity for per-period caps, rate limiting, or time-based restrictions.

Security is the deeper problem. Many dApps request unlimited approvals (setting the allowance to the maximum uint256 value) to avoid requiring users to re-approve for each interaction. If the approved contract is compromised, an attacker can drain every token the user has approved. Over $1 billion has been stolen through approval phishing since 2021, including $9.7 million from the Li.Fi Protocol in 2024 and $3.3 million from SocketDotTech in the same year.

EIP-2612 (Permit) improves the UX by enabling gasless approvals via off-chain signatures, but it does not address the fundamental lack of subscription semantics. The approved amount is still a lump sum, not a recurring authorization.

Money Streaming: Superfluid and Sablier

Money streaming protocols take a different approach entirely: instead of discrete periodic payments, value flows continuously from sender to receiver on a per-second basis. This model maps well to time-based subscriptions where the service is consumed continuously.

Superfluid

Superfluid implements money streaming through Super Tokens, an extension of the ERC-20 standard that enables dynamic balances. Users wrap standard tokens (for example, USDC becomes USDCx) and define a flow rate in tokens per second. A $1,200/year subscription becomes approximately 0.038 USDCx per second, flowing continuously without additional transactions.

The protocol handles netting automatically: all inflows and outflows for each account are calculated at every block without consuming gas per stream per block. A single on-chain transaction opens the stream, and it persists until canceled or the sender's balance is depleted. As of early 2025, Superfluid reported over $750 million in cumulative value streamed across more than 350,000 wallets, deployed on 10+ EVM chains including Ethereum, Polygon, Arbitrum, and Base.

Sablier

Sablier pioneered token streaming in 2019 and has processed over 552,000 streams across 297,000+ users on 20+ EVM chains. It offers three product lines: Lockup for fixed-duration vesting, Flow for open-ended recurring payments, and Merkle Airdrops for token distribution. The underlying contracts are permissionless: streams continue to function regardless of the company's operational status.

Streaming Limitations

Streaming works well for payroll, contributor compensation, and token vesting, where value accrues linearly over time. ENS DAO and Optimism both use Superfluid for contributor payments. But the model has friction for traditional subscription billing:

• Users must maintain a sufficient Super Token balance at all times; if the balance depletes, the stream terminates.
• The wrapping step (converting USDC to USDCx) adds UX complexity and requires understanding a non-standard token.
• Merchants expecting discrete monthly payments must aggregate continuous micro-flows into billing-cycle revenue, complicating accounting and reconciliation.
• Streaming is less intuitive for consumers: "$9.99/month" is a concept everyone understands, while "0.000003858 USDC per second" is not.

Account Abstraction and Session Keys

Account abstraction (ERC-4337) offers the most promising architectural foundation for on-chain recurring payments. By replacing externally owned accounts with smart contract wallets that can implement custom validation logic, account abstraction enables programmable spending policies that closely mirror traditional payment mandates.

Session Keys

A session key is a secondary, locally-generated keypair with scoped authority that the wallet owner delegates to a dApp. Instead of requiring the user's primary private key for every transaction, the session key can sign transactions within defined boundaries:

• Target contract: which contract address the key can interact with
• Function selectors: which specific functions can be called
• Spending caps: maximum per-transaction and cumulative limits
• Time expiry: mandatory expiration timestamp
• Gas caps: limits on gas spending per operation

For subscriptions, a user could grant a session key stating: "this app may transfer up to 50 USDC monthly to this specific address, expiring after twelve months." The dApp settles each billing cycle without user interaction, and the user can revoke the session key at any time.

ERC-7715 Permission Requests

ERC-7715 introduces wallet_grantPermissions, a JSON-RPC method that lets a dApp request a scoped, time-bounded delegation from a user's wallet. The wallet shows a confirmation UI where the user can approve, deny, or modify the requested scope. Permissions are "attenuable": a parent grant can be narrowed before passing to a sub-component, and if a session key is compromised, the damage is bounded by the grant's scope.

Combined with paymasters that cover gas fees in stablecoins rather than requiring ETH, this architecture enables a UX where the user approves once, sees a clear summary of what they are authorizing, and then receives automatic billing in USDC or USDT without touching their wallet again. Smart account deployments surpassed 30 million across Ethereum and its L2 ecosystem by mid-2026, and EIP-7702 (live since the Pectra upgrade in May 2025) allows existing EOA wallets to temporarily gain smart account capabilities without migrating funds.

Key distinction: Session keys invert the approval model. Instead of giving a contract blanket permission to move your tokens, you grant a scoped key that can only perform specific actions within defined limits. If the key is compromised, the maximum loss equals the session's spending cap, not your entire token balance.

Comparing Recurring Payment Approaches

Each approach to on-chain recurring payments makes different tradeoffs between security, user experience, and technical complexity. The right choice depends on the use case: payroll streaming differs fundamentally from SaaS subscription billing.

Emerging Platforms and Infrastructure

A growing number of platforms are building production-ready recurring payment infrastructure for stablecoins, each targeting different segments of the market.

Stripe Stablecoin Subscriptions

Stripe's $1.1 billion acquisition of Bridge (closed February 2025) signaled serious intent. Stripe launched stablecoin subscription payments in late 2025, allowing merchants to accept USDC on Ethereum, Solana, and Polygon for recurring billing. Given that 30% of Stripe businesses operate on recurring models, this represents meaningful infrastructure: merchants get stablecoin acceptance through the same Stripe API they already use for card billing.

Loop Crypto

Loop Crypto focuses specifically on crypto recurring payments, offering autopay functionality where customers never lock up funds. Loop handles recurring charges across Ethereum, Solana, and EVM chains, integrating with existing billing platforms like Stripe and Chargebee. Merchants can configure which tokens to accept, including stablecoin-only configurations.

Spritz Finance

Spritz Finance bridges crypto to real-world bill payments. Its SMARTPay feature enables scheduled recurring payments with zero gas fees via a single signature transaction: users pay phone bills, mortgages, utilities, and credit cards directly from stablecoin wallets across Polygon, Ethereum, Avalanche, and Arbitrum. When triggered, Spritz converts stablecoins to fiat and delivers immediate payment to the biller.

Confirmo

Confirmo launched a stablecoin subscription payment service supporting automated recurring billing across 700+ self-custody wallets and exchange accounts. This approach works at the payment processor level rather than the smart contract level, handling the complexity of multi-wallet compatibility without requiring users to interact with new token standards.

Gas Fees, Failed Payments, and Operational Challenges

Beyond the architectural push-vs-pull challenge, recurring on-chain payments face operational problems that traditional billing systems solved decades ago.

Gas Fee Unpredictability

On Ethereum mainnet, gas prices fluctuate dramatically. A recurring payment that costs $0.50 in gas during low congestion might cost $15 during a fee spike. For a $9.99/month subscription, unpredictable gas can exceed the payment itself. Layer 2 networks like Base, Arbitrum, and Optimism reduce gas to sub-cent levels, but introduce bridging complexity. Paymasters (under ERC-4337) can abstract gas entirely, letting users pay fees in the stablecoin itself, but the cost is still borne somewhere in the system.

Failed Payment Recovery

In traditional billing, when a card charge fails, the merchant retries using established dunning sequences: retry on day 3, again on day 7, send a notification, downgrade the account. There is no universal standard for retry logic in on-chain billing. Insufficient balance, revoked approvals, wallet migration, and contract upgrades can all cause failures. Platforms like Loop and Spritz are building retry and webhook infrastructure, but it is proprietary rather than standardized.

Consumer Protection Gaps

Traditional payment systems include consumer protections: chargebacks on card payments, SEPA Direct Debit's unconditional 8-week refund right, ACH dispute windows. On-chain payments are final by design. Recurring stablecoin payments create ambiguity around refund rights, billing disputes, and regulatory compliance. As stablecoin regulation matures, jurisdictions like the EU (MiCA, fully in force since December 2024) are beginning to define requirements for stablecoin payment providers, but consumer protection frameworks specifically for recurring crypto billing remain underdeveloped.

The Merchant Opportunity

Despite the technical challenges, merchant demand for stablecoin subscription billing is growing for concrete economic reasons.

Cross-border subscription revenue is a primary driver. A SaaS company billing customers in 50 countries faces foreign exchange spreads, correspondent banking fees, and settlement delays of 2 to 5 business days. Stablecoins denominated in dollars settle in seconds at a fraction of the cost. Stripe reported that its Bridge transaction volume increased 4x over the past year, and one customer (Shadeform, an AI infrastructure company) shifted approximately 20% of payment volume to stablecoins, which "settle near-instantaneously and cost half as much per transaction."

The total stablecoin market cap reached approximately $315 billion by mid-2026, with USDT at roughly $184 billion and USDC at $77 billion. Real-world stablecoin payment volume (excluding automated and bot activity) reached approximately $400 billion in 2025, with B2B payments accounting for more than half. The infrastructure is being used, and the volumes justify building subscription tooling on top of it.

Where Spark Fits In

As Spark's ecosystem expands beyond one-time Bitcoin and stablecoin transfers, recurring payment support becomes essential for merchant adoption. A payment network that only handles individual transactions cannot serve the subscription economy. Spark's architecture offers several properties relevant to recurring payments:

• Instant settlement without on-chain transactions per payment, avoiding gas fee unpredictability entirely
• Native stablecoin support through USDB, enabling dollar-denominated billing on Bitcoin infrastructure
• Self-custodial architecture where users retain control of funds between payment events
• Lightning Network compatibility for interoperability with existing payment infrastructure

For wallets building on Spark, General Bread demonstrates how consumer-facing applications can leverage the protocol for stablecoin payments. As the ecosystem matures, recurring payment capabilities at the SDK and wallet layer will determine whether stablecoin-native subscriptions become practical for everyday merchants. Developers interested in building on this infrastructure can explore the Spark SDK documentation and the broader subscription billing infrastructure landscape.

What Comes Next

The recurring stablecoin payment stack is converging on a layered architecture: smart wallets with session keys at the base, payment orchestration platforms in the middle, and merchant billing integrations at the top. The pieces are falling into place:

• ERC-4337 smart accounts provide the programmable wallet layer, with 30 million+ deployments across Ethereum L1 and L2s
• ERC-7715 standardizes permission requests, giving subscription apps a consistent way to request scoped billing authority
• EIP-7702 bridges the gap for existing EOA users, letting them access smart wallet features without migration
• Paymasters eliminate the need for users to hold native gas tokens, enabling pure stablecoin billing UX

The missing piece is standardization across these layers. Today, each platform implements its own retry logic, cancellation flow, and billing event format. A shared standard for on-chain subscription state (billing period, payment status, grace period, cancellation) would accelerate adoption by letting merchants integrate once and work across wallets. Until then, recurring stablecoin payments will continue to mature through platform-specific implementations, each pushing the ecosystem closer to parity with the subscription infrastructure that traditional payment rails have built over decades.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.