Capped Approvals or Manual Payments for Recurring USDC Billing?

Recurring stablecoin billing is now a standard ask in crypto SaaS and infrastructure. Two models dominate: one-time approvals that cap what a merchant can pull from a wallet each cycle, or prompting the customer to pay manually every month. Both fit onchain USDC subscription billing, but they carry real differences in operational flow, user experience, and failure risk.

How Capped Onchain Approvals Work

With a capped approval, the customer signs an onchain transaction that lets a contract or a merchant address pull up to a specific USDC amount from their wallet, for a set purpose. This cap is visible and explicit. The approval does not give blanket access: the customer can see and confirm the upper limit, and revoke it at any time.

Subscription cycles run automatically. Each billing period, the merchant triggers a transfer up to the cap. If the transfer is under the limit and the wallet has sufficient balance, payment settles in a single transaction. If the merchant tries to collect more than the approved cap, the transaction fails. If the wallet balance is insufficient, the collection attempt also fails, and the merchant may retry or notify the customer.

Worked Example: SaaS Subscription with a $100 Cap

Let’s say you sell a developer dashboard service for $50 per month, billed in USDC, with usage-based overages up to $30. You set the recurring cap at $100 USDC. Here’s how a capped approval flow looks in practice:

• Signup: Customer connects a wallet and signs an approval for $100 USDC to your settlement address.
• Month 1: You charge $50. The transfer is triggered onchain. Customer balance is $150. Payment settles immediately. $100 cap remains, $50 used.
• Month 2: Customer uses more API credits. Total due is $75. You trigger a $75 collection. Still under the $100 cap. Wallet has $80. Payment settles.
• Month 3: Customer’s usage spikes, $110 due. You attempt to collect $110. The transaction fails: exceeds the onchain allowance. Customer is prompted to re-approve a new cap or pay manually.

The cap guards the customer from unexpected large bills, while giving you predictable collection for standard cycles. If the customer wants to stop, they can revoke the approval through their wallet UI at any time.

Manual Pay-Per-Cycle: Mechanics and Friction

Manual billing means that each time payment is due, the customer receives a link or notification. They return to your site, connect their wallet, and sign an onchain transfer for the specific amount. No future rights are granted. The merchant never has an open allowance against the wallet.

This is the most direct model. Every payment is explicit, signed and settled as a standalone transaction. If the customer does not return to pay, you do not collect. There is no risk of surprise charges, but there is also no automation: each cycle depends on the customer’s timely action.

Example: Manual Monthly Payment Flow

• Signup: Customer creates an account. No approval is signed.
• Month 1: Invoice generated for $50. Customer receives notification, clicks payment link, signs $50 USDC transfer. Payment settles.
• Month 2: New invoice for $60. Customer must return, sign another transaction. If they delay, service may be paused or downgraded.
• Month 3: Customer forgets to pay. No transfer is signed, no USDC moves. Service is suspended until payment is made.

Manual payment gives the customer maximum control, but it creates opportunities for missed or late payments. As a merchant, you must build or use a reminder system, and accept that some customers will churn due to friction, not intent.

Tradeoffs: Predictability, UX, and Operational Cost

Predictable Revenue Collection

Capped approvals automate payment collection. If the customer has balance and the amount is within the approved cap, the merchant can collect without user intervention. This reduces failed payments due to inattention or lost reminders.

Manual payments require the customer to act every cycle. Even if they intend to pay, vacations, wallet issues, or notification failures can delay or block payment. This introduces more volatility in revenue and requires more operational follow-up.

Customer Experience and Trust

Capped approvals ask the customer for bounded trust. They see the upper limit and can revoke at any time. This is less intrusive than an unlimited approval, but still demands a degree of forward trust.

Manual payments maximize customer control. No rights are granted beyond each transaction. For larger or less frequent charges, or for customers who are highly security conscious, this can be the right fit.

Handling Usage-Based or Variable Billing

If your SaaS or dApp bills variable amounts each cycle, capped approval allows you to charge up to a ceiling without needing a new signature each time. This is critical in usage-based models, where charges can fluctuate but usually stay within a known range.

Manual payments are possible with usage billing, but require the customer to sign every variable amount. This can be a friction point, especially if usage is unpredictable or billing cycles are frequent.

Failed Payments: What Actually Happens

With capped approvals, the most common failure is a wallet with insufficient balance. When this happens, the merchant’s attempted transfer fails onchain. No USDC moves. The merchant can retry later or notify the customer. If the charge exceeds the cap, the transfer fails and the customer must approve a higher cap or pay manually.

With manual payments, failures are all user-driven. If the customer does not sign, no payment occurs. There is no way for the merchant to trigger or retry collection. Reminders and follow-ups are the only options.

Which Model Fits Which Business?

• SaaS or recurring infrastructure: Capped approvals fit well, especially where monthly or usage-based billing is standard. Predictable revenue and lower churn from missed payments.
• One-off or infrequent services: Manual payments may be better. Each transaction is explicit, and the friction is less of a factor.
• Security-conscious customers: Manual payments offer maximum control. Capped approvals are still safe, but require a trust boundary.
• High-variance usage billing: Capped approvals offer flexibility within a set ceiling. Customers can set a cap above their average usage and avoid repeated prompts.

Where the Model Breaks Down

Capped approvals do not work if your usage spikes above any reasonable cap, or if customers are unwilling to grant even a bounded right. Manual payments do not scale well for high-frequency or low-value cycles, as friction compounds.

How We Handle This at Reclack

At Reclack, we support both capped approvals and manual payments for recurring USDC billing on Base, Ethereum, and Polygon. Every recurring approval is capped. The customer sees and signs the maximum amount the merchant may collect per cycle. For manual cycles, we generate a new onchain invoice and payment link for each due amount. No funds ever flow through us, and we never touch a user’s seed or private keys. Our docs walk through both models, with code examples and operational guidance: https://reclack.com.