Recurring stablecoin invoices are the subscription-billing equivalent of card-on-file: a SaaS provider, retainer service, or subscription content business charges a customer the same stablecoin amount every billing cycle without the customer manually approving each charge. The mechanics differ from card recurring billing because public blockchains do not natively support a “merchant-initiated transaction” primitive—every transfer requires the wallet holder to sign. Workarounds exist: EIP-2612 permits, Uniswap’s Permit2, smart-contract pull-payment patterns, and one-off invoice generation per cycle. Each model has different security, UX, and operational trade-offs.
​

This article walks through the three recurring-billing models in production today, when each one fits, what the customer experience looks like, and where Eco fits when recurring billing needs to span multiple chains.
​

A recurring stablecoin invoice is a subscription-billing arrangement where a customer pre-authorizes a seller (or smart contract) to debit a fixed stablecoin amount on a fixed cadence—typically monthly or annually—from a wallet the customer controls. The pre-authorization can take the form of a token approval (allowance), a signed off-chain message (permit), or a deposit into a billing-specific smart contract. When the cycle hits, the seller’s billing system pulls the funds without further customer interaction.
​

The use cases mirror card recurring billing: SaaS subscriptions, retainer agreements, content paywalls, gym memberships, and any other service with a fixed periodic fee. For background on stablecoin invoicing generally, see Stablecoin Invoicing: Get Paid in USDC/USDT.
​

Three recurring billing models dominate stablecoin invoicing in production today. Each pre-authorizes the seller in a different way.
​

The customer signs a one-time token approval to a billing smart contract for an amount large enough to cover several billing cycles (e.g., 12 months at $99 = $1,188 USDC approved). The billing contract then transfers the monthly amount on the cycle date by calling ERC-20 transferFrom. The customer can revoke the approval at any time.
​

Strengths: standard ERC-20 mechanics, no custom smart contract on the customer side, broad wallet compatibility. Trade-offs: the approval surface is the security risk—if the billing contract is compromised, the entire approved amount is at risk. Production deployments use audited billing contracts with daily or per-cycle rate limits.
​

EIP-2612 lets a customer sign a permit message off-chain that authorizes a specific transfer at a specific time. Permit2, deployed by Uniswap, generalizes this for tokens that don’t natively support permits. The customer signs a permit per cycle (or a batched permit covering N cycles); the seller submits the permit to chain along with the transfer call.
​

Strengths: no on-chain approval transaction needed (saves gas on the customer side), tighter security envelope (permits can be cycle-specific), gasless UX. Trade-offs: requires the customer to sign per cycle (or pre-sign a batched permit), which adds back UX friction unless the wallet supports session-based pre-signing.
​

The customer deposits N months of stablecoin into a billing smart contract upfront (effectively prepaying the subscription). The contract releases the monthly amount to the seller on cycle dates and refunds any unused balance if the customer cancels. Request Network and several DAO-treasury tools use this pattern.
​

Strengths: no approval surface (the customer no longer holds the stablecoin in their main wallet), strong cancellation guarantees (refund logic is in the contract). Trade-offs: customer locks up working capital; smart contract risk is concentrated.
​

The simplest model: the seller generates a fresh stablecoin invoice every cycle and emails the customer a payment link. The customer signs each cycle’s payment manually. This is “recurring” in name only—it is N one-off invoices on a schedule.
​

Strengths: zero technical complexity, no smart-contract or permit risk. Trade-offs: high churn (every cycle is a fresh decision for the customer), more failed payments, more reconciliation overhead. Most teams start here and migrate to one of the other three models once they hit ~50 recurring customers.
​

The customer-facing experience varies meaningfully by model.
​

Token approval model: Customer signs once at signup ("approve $X for billing"), then receives email confirmations on each cycle. Identical to setting up Apple Pay or a card-on-file. Wallet shows an active approval; customer can revoke any time.
​

Permit-based model: Customer signs once at signup or once per cycle, depending on implementation. Wallet shows no active approval (permits are off-chain), so cancellation is just “don’t sign next month.”
​

Smart-contract deposit model: Customer deposits 6 or 12 months upfront, gets a clear “your subscription is funded through [date]” status. Cancellation refunds the unused balance. Closest to a prepaid card model.
​

One-off model: Customer pays each cycle manually. Higher friction, but the lowest commitment.
​

Card recurring billing has decades of dunning playbooks. Stablecoin recurring billing is younger and the failure modes are different.
​

The two failure modes that dominate: insufficient balance in the customer’s wallet at cycle time (no automatic top-up), and revoked approval (the customer reduced the allowance). Both surface as a failed transferFrom call. Production billing systems retry on cycle + 24h, then notify the customer via email or wallet message, then mark the subscription delinquent. B2B stablecoin payout APIs covers the dunning automation layer.
​

Insufficient-balance failures are more common than card NSF events because customers don’t treat their wallets like checking accounts. Subscription tools sometimes pair recurring billing with auto-funding (a side rule that funds the subscription wallet from a treasury wallet on cycle date) to mitigate this.
​

A subscription customer who pays USDC on Base in month 1 may want to pay USDT on Tron in month 6 because they relocated or because their employer started paying them in USDT. Recurring billing tied to a single chain breaks this. Multi-chain recurring billing requires a routing layer underneath the cycle: the customer’s wallet authorizes a transfer on whatever chain they hold balance on, and the billing system receives on the seller’s preferred chain via a cross-chain intent protocol.
​

This is still a leading-edge capability. Most production recurring stablecoin billing today is single-chain. The teams shipping multi-chain recurring billing are typically high-end B2B SaaS with global customer bases.
​

For SaaS teams running recurring billing across multiple chains, Eco Routes provides the cross-chain settlement layer that lets a single recurring authorization cover any chain the customer holds balance on. The customer pre-authorizes USDC equivalent; the billing system pulls from whichever chain has the balance, and Eco routes to the seller’s target chain. For SMBs and freelancers running recurring billing without a custom build, Eco Portal handles the same multi-chain logic in a no-code interface. Either path removes the “please bridge to my preferred chain first” step that adds friction to subscription renewal.
​

Yes, several SaaS businesses already do. The constraint is customer demographics—crypto-native users adopt stablecoin subscriptions easily, while traditional SaaS customers expect cards. Most production teams offer stablecoin recurring as a discount tender (5–10% off vs. card pricing) to capture the savings on processing fees.
​

The transferFrom call reverts and the billing system marks the cycle as failed. Standard practice is to retry at cycle + 24h, then send a customer email, then suspend service after 3–5 days. Insufficient-balance failures are roughly 2–5x more common than card NSF events because customers don’t treat wallets like checking accounts.
​

Yes, with caveats. Permit2 lets the customer sign a per-cycle or batched-cycle permit off-chain. Batched permits authorize N future cycles in advance; per-cycle permits require a customer signature each cycle. The right choice depends on whether your billing UX can prompt for a signature on cycle date.
​

Yes. Token-approval models let the customer revoke the approval immediately on-chain. Permit models cancel by simply not signing the next permit. Smart-contract deposit models include cancellation logic that refunds the unused balance to the customer’s wallet. All three models offer cleaner cancellation than card chargebacks because the dispute is resolved on-chain.
​

Pricing changes that increase the charge require a new approval or permit at the higher amount—the existing authorization caps the charge. Most teams notify customers 30 days before a price increase and ask them to re-authorize. Decreasing the price is automatic; the billing system simply pulls a smaller amount.
​