Stablecoin Subscriptions: Recurring Onchain Billing Patterns
Three primitives power stablecoin subscriptions in 2026: pull-payments using ERC-20 allowance, allowance-cap with periodic top-ups, and intent-based deposits that settle into a chosen stablecoin. Sablier and Superfluid handle streaming flows. Stripe Billing added native stablecoin subs. Pick by churn risk and customer wallet behavior.
Recurring billing is the use case that stablecoins struggled with for years. Cards do it cleanly with a saved-card-on-file and a merchant-initiated charge. Onchain, the wallet has to authorize each pull, the user has to keep the wallet funded, and a missed payment cannot be solved by retrying a stored credential.
2025 to 2026 changed that. The patterns now work. This article walks through the three primitives, the dunning logic, and a comparison of when each fits.
Pattern one: pull-payment with allowance
The original onchain subscription pattern. The user calls approve() on the stablecoin contract, authorizing the merchant's contract to spend up to N tokens. The merchant calls transferFrom() on the schedule, pulling the recurring amount.
Strengths: native ERC-20 primitive, supported by every wallet, no new infra. Used by Loop Crypto, Coinflow, and roll-your-own merchants.
Weaknesses:
Allowance is a blunt cap; if the user sets it high, the merchant can pull anything up to that cap.
If the user revokes or moves funds, the next pull fails silently.
UX puts the trust burden on the user during the approve step.
Best fit: web3-native users, low-friction SaaS where users already understand approvals.
Pattern two: allowance-cap with periodic top-ups
A refinement. Instead of a high or infinite allowance, the merchant requests a tight cap (one period's worth) and the dapp prompts the user to re-approve before the next pull. Higher friction, lower trust risk.
The trade-off: more UX prompts but no scope creep. Some wallets (Rainbow, Coinbase Wallet, Family) now expose the allowance management UI directly, making the periodic re-approve flow tolerable.
Best fit: high-value subscriptions where users care about exposure.
Pattern three: streaming (Sablier, Superfluid)
A different model entirely. Instead of discrete pulls, the user opens a stream that drips the subscription amount per second. The merchant can withdraw the accrued balance at any point. Stop the stream, stop the bill.
Superfluid (per the directory listing in our 2026 stablecoin payment providers audit) handles continuous payroll, vendor payments, and per-second subscriptions. The contract holds a deposit, accrual is real-time, the receiver can drain anytime.
Sablier (sablier.com) is in the same family: token distribution with vesting, payments, and airdrops, per-action fees, transparent pricing. Heavier on the vesting side; payment-streaming exists.
Strengths: pro-rated billing is free, cancellations are instant, no failed-charge dunning loop because the user can never owe more than they staged.
Weaknesses: gas cost per stream open / close on some chains, less familiar UX, requires upfront token deposit.
Best fit: payroll, B2B vendor payments, premium-tier SaaS, anything where the customer wants pro-rated cancel.
Pattern four: intent-based deposits
The newest pattern. The user does not approve anything; the merchant generates a payment intent (a quote + a deposit address + a target settlement stablecoin), and the user sends funds from any wallet, any chain, any token. The intent system normalizes the deposit into the merchant's chosen stablecoin.
Daimo Pay (docs.daimo.com) is the cleanest example. Eco Routes provides the intent-based cross-chain settlement layer that powers similar flows.
The subscription variant: a hosted billing page with a recurring intent. The user comes back monthly (or on a reminder), pays from whatever wallet they want, the merchant settles into USDC on Base or Solana.
Strengths: zero approval risk, any-chain any-token UX, lowest customer setup friction.
Weaknesses: not strictly recurring; user has to act each period. Pairs well with reminder emails or wallet push notifications. Closer to invoice-based than true subscription.
Pattern five: Stripe Billing native stablecoin
Stripe shipped stablecoin subscriptions through Stripe Billing (docs.stripe.com/billing/subscriptions/stablecoins). The flow: a SetupIntent collects an authorization from the customer's wallet, the Stripe billing engine fires recurring withdraw calls, and the merchant receives the agreed amount in USDC on Ethereum, Solana, Polygon, or Base.
For merchants already on Stripe, this is the lowest-friction path. The trade-off is platform lock-in and Stripe's fee on the stablecoin leg, which is published at 1.5% in their docs.
Comparison: pull versus allowance-cap versus intent
Pattern | User friction | Approval risk | Failed-charge handling | Pro-rated cancel | Best for |
Pull-payment (high allowance) | One-time approve | High | Silent fail | No | Web3-native SaaS |
Allowance-cap (period re-approve) | Per-period approve | Low | Visible prompt | No | High-value subs |
Streaming (Sablier / Superfluid) | Open stream once | Bounded by deposit | Stream stops | Yes | Payroll, vendor, premium SaaS |
Intent-based (Daimo, Routes) | Per-payment | None | User did not pay | N / A | Invoice-style, any-chain customers |
Stripe Billing stablecoin | SetupIntent once | Stripe-managed | Stripe retry | Per Stripe rules | Merchants already on Stripe |
How do you handle failed charges (dunning) onchain?
Card dunning is a known craft: retry on day 1, 3, 7, fall back to email, recover 30 to 60% of failed charges through retry logic. Onchain dunning is different because the reasons for failure are different.
Common failure modes:
Allowance was revoked or set too low.
Wallet balance dropped below the pull amount.
User moved funds to a different address.
Wallet is connected to a different network than the merchant expects.
The dunning playbook:
Retry once, immediately. Some failures are transient (mempool congestion, nonce conflict).
Email or notify the customer with a one-click re-authorize link.
Offer a switch to intent-based as a recovery path. The customer pays once from any wallet, the subscription resumes.
Soft-cancel after N retries. Don't let zombie subscriptions accrue silent failures.
Streaming subscriptions skip most of this because the failure mode is the deposit running dry, which is visible to the user in real time.
Which pattern should you pick?
A short decision tree:
Already on Stripe Billing? Use Stripe stablecoin subscriptions. Lowest cost to ship.
Selling to web3-native users with their own wallets? Allowance-cap with periodic re-approve, or streaming.
Selling to a mainstream customer who has a wallet but does not live in it? Intent-based, with a recurring invoice cadence.
Payroll or vendor payments? Streaming (Superfluid is purpose-built for it).
B2B, want full control? Roll your own with allowance-cap and a robust dunning loop.
Sources
Stripe stablecoin billing, docs.stripe.com/billing/subscriptions/stablecoins
Sablier, sablier.com
Daimo Pay, docs.daimo.com
Eco's 2026 stablecoin payment providers audit
Related reading
PLACEHOLDER-accept-stablecoin-payments-setup-smb-shopify-woo-custom
PLACEHOLDER-stablecoin-settlement-marketplaces-splits-holds-refunds
PLACEHOLDER-stablecoin-off-ramp-providers-business-bridge-bvnk-moneygram-conduit

