Capped Approvals for Onchain Recurring USDC Billing: Pros and Cons

Recurring payments are a core part of SaaS and digital services. In crypto, recurring billing means letting a merchant collect a stablecoin payment from a customer’s wallet at set intervals. The central question is: how should users approve these payments? Should you use capped onchain approvals, or prompt for a signature every time?

Why Capped Onchain Approvals Exist

With ERC-20 tokens like USDC, a contract cannot move funds from a user’s wallet without an explicit approval. Most onchain recurring billing flows start with a user signing an approval transaction. This approval sets a maximum amount the contract can pull in one go or over a specific period.

A capped approval is not open-ended. Instead, the user is presented with a cap, say, 100 USDC per month. The merchant can only collect up to that cap, and the user must re-approve if a higher amount is needed. This is a deliberate trade-off. It avoids the risks of unlimited approvals while still letting the merchant charge recurring fees without re-prompting for every payment.

The Alternative: Prompt Every Time

You could ask the user to sign a transaction for each charge. This gives the user maximum control. No funds move without explicit confirmation. But this also adds friction, especially for monthly SaaS subscriptions or API usage billing. Each billing cycle, the user must return, sign, and pay gas. Any missed signature means a missed payment and, potentially, a service interruption.

How Capped Approvals Work: A Worked Example

Imagine a SaaS platform charges 20 USDC per month for access. The platform uses a capped onchain approval for recurring billing. Here is what the customer flow looks like:

• At signup, the user signs two onchain transactions:
  • An approval for the contract to spend up to 60 USDC (a three-month cap).
  • The first payment of 20 USDC.
• The next month, the contract collects another 20 USDC, bringing the total to 40 USDC spent.
• In month three, the platform pulls the final 20 USDC from the original approval. The cap is now fully used.
• Before month four, the contract cannot pull more funds. The user must re-approve, extending or raising the cap.

No one can exceed the 60 USDC cap without the user’s new signature. If the user wants to cancel, they can stop approving. There is no unlimited risk exposure.

What Happens When the Cap Runs Out?

If the platform tries to collect 20 USDC in month four but the cap is depleted, the transaction fails. The contract cannot transfer more than the approved amount. The user receives a prompt to re-approve, or the service pauses until they do.

Pros of Capped Approvals in Recurring Stablecoin Billing

Lower Friction

Users only approve once per cap period. No need to sign monthly if the cap covers several billing cycles. This is smoother for low-ticket, high-frequency services.

Predictable Risk Exposure

A capped approval limits the most the merchant can collect. If the merchant is compromised, or the contract has a bug, the user’s exposure is limited to the cap.

Fewer Missed Payments

Friction from re-prompting can cause drop-off. With capped approvals, most collections will succeed until the cap runs out. This means more consistent revenue for SaaS or membership businesses.

Cons and Limitations of Capped Approvals

Requires Trust in the Cap Logic

The user must understand the cap and trust that the contract cannot exceed it. If the UI or contract does not make this clear, users may be wary.

Manual Re-Approval Still Needed

Capped approvals do not remove all friction. The user must re-approve when the cap runs out, or when the price changes. This can still interrupt service if not handled smoothly.

Cannot Reverse Payments

Once a capped payment is made and confirmed onchain, it is final. If the user disputes a charge, there is no chargeback. Refunds depend on the merchant’s policy and process.

Gas Costs

Approvals and payments both require gas. The initial setup is more expensive than just paying the first invoice, since the user must send two transactions (approval and payment) instead of one. For low-value subscriptions, this can matter.

Patterns to Avoid

Do not use unlimited approvals for recurring billing. Users are right to be cautious. If a contract is ever compromised, the entire wallet balance is at risk. Always show the cap, explain the period it covers, and require a new signature for any increase.

Who Should Use Capped Approvals?

Capped onchain approvals fit products with regular, predictable billing cycles. SaaS with monthly fees, gated Discord channels, API usage with clear limits, or NFT memberships that renew. They are less suited to high-variance, unpredictable usage, where metered billing can spike above the cap.

If your service is high-touch or high-value, you may want to prompt every time. For low-friction, recurring SaaS, a well-implemented capped approval balances safety and convenience.

Should You Use Capped Approvals? A Decision Table

Billing Model	Capped Approval?	Notes
Flat monthly SaaS	Yes	Set cap to 2-3x monthly fee
High-variance API	Maybe	Needs careful cap management
One-off consulting	No	Use single payment, not recurring
NFT membership renew	Yes	Cap for renewal window
Usage-based metered	Maybe	Cap can be tricky for spikes

How We Handle Capped Approvals at Reclack

At Reclack, we use capped onchain approvals for recurring USDC billing. Every recurring payment authorization is bounded, users see the cap and sign it up front. We never request unlimited approvals. When the cap is reached, we prompt the user to re-authorize, keeping exposure predictable. Merchants never receive funds they are not due, and users never lose control of their wallet. If you want to see how this works in practice, read more about Reclack.