When to Prompt for Recurring Billing Approval: Signup or Checkout?

Prompting users to authorize recurring payments is a unique challenge in onchain billing. Stablecoin subscriptions use explicit, capped approvals. Each approval is a blockchain transaction, visible and irreversible. Whether you ask for this approval at signup or at checkout shapes both user experience and payment success rates. Let’s break down what changes, and why it matters for crypto-native SaaS.

The Mechanics of Recurring Billing Approvals

Onchain recurring billing is not like card-on-file. The user must sign a transaction giving permission for withdrawals, up to a visible cap. This creates friction, but also security. The flow looks like this:

• The dapp prompts the user to approve recurring billing, specifying a cap (for example, 100 USDC/month).
• The user signs an onchain approval, setting an allowance for the billing contract or the merchant’s address.
• Each month (or billing cycle), a transaction pulls up to the cap from the user’s wallet to the merchant’s settlement address, based on usage or subscription terms.
• The user can revoke or lower the allowance at any time.

This is non-custodial. Funds never sit with the billing platform. Each payment settles directly from the user’s wallet to the merchant. There is no possibility of chargeback after confirmation.

Signup Approval: Fewer Surprises, More Dropoff

Prompting for recurring billing approval at signup is common in traditional SaaS. Onchain, it means that the first meaningful interaction with your product is a wallet prompt. The user must:

• Connect their wallet
• Sign an approval transaction, for a capped recurring amount
• Pay gas fees for the approval

This flow reduces surprises later. Every user who completes signup has already authorized payments. You know who is ready to pay, and can provision features accordingly.

The tradeoff: higher dropoff. Some users will abandon signup when they see a transaction prompt, especially if they do not yet trust your product. Others may not have sufficient funds or are not ready to commit.

Example: SaaS Tool with 50 USDC/mo Subscription

Suppose you run a SaaS for onchain analytics at 50 USDC/month. At signup, you show:

“Authorize monthly billing, capped at 50 USDC/month. You can revoke at any time in your wallet.”

The user signs an ERC-20 approve for 50 USDC/month. If you have 1000 signups, but 600 complete the approval, you can expect up to 600 active subscriptions. Your onboarding funnel is clean, but you lose users who were just exploring.

Checkout Approval: Lower Barrier, More Payment Friction

Prompting for approval at checkout means users can explore your product before seeing a payment request. This matches the try-before-you-buy model, familiar in SaaS.

The flow:

• User signs up and explores your app
• At the paywall (checkout), you prompt for approval
• The user signs the approval for the billing cap

This increases conversion for users who want to see value before committing. You also cut down on approvals that never get used.

The downside is operational: users may hit the paywall, see the approval prompt, and drop off. Some may be surprised by the need for an onchain transaction, or be unwilling to pay gas in that moment. You will need logic to handle failed or delayed approvals.

Example: Usage-Based API

Imagine an onchain data API that charges by usage, up to a 200 USDC/month cap. A user signs up, gets free quota, and hits the paywall after some usage. Only then do you show:

“Authorize up to 200 USDC/month for usage-based billing. You can revoke or adjust the cap at any time.”

If 2000 users sign up, but only 400 hit the paywall and approve, your payment funnel is much tighter. You have better signal that these users value your product, but must handle payment logic dynamically as users reach their limits.

User Experience Considerations

Gas Fees and Approval Fatigue

Every approval is an onchain transaction. Users must have enough ETH, MATIC or BASE in their wallet to pay gas. Prompting for approval only when necessary (at checkout) reduces unnecessary gas spend. Users appreciate not being asked to sign transactions they may not use.

Trust and Transparency

Some users are wary of signing approvals before seeing value. Prompting at checkout, with clear communication of caps and the option to revoke, builds trust. Transparent UI around what is being approved, and why, is essential.

Operational Impact

Prompting at signup makes it easy to segment users who are ready to pay. You can automate provisioning or onboarding based on approval status. Prompting at checkout means more users will reach your product, but you must handle edge cases: retries, failed approvals, and partial usage.

Handling Failures: What If Approval Fails?

Onchain billing must account for the case when a user declines or cancels the approval. At signup, this means they never enter your paid funnel. At checkout, you may need to:

• Show a clear error and next steps
• Offer a retry or support flow
• Allow users to adjust the cap or use a different wallet

If a user revokes or reduces the cap later, your system should detect allowance changes and notify them proactively.

Comparing the Flows: A Worked Example

Let’s compare two approaches for a SaaS billing 100 USDC/month on Polygon.

Scenario: 10,000 Users

Signup Approval: - 10,000 land on the signup page - 7,000 connect wallet - 4,500 approve 100 USDC/month cap - 4,500 become active users

Checkout Approval: - 10,000 land on the signup page - 8,000 connect wallet - 6,000 start free trial, use the app - 2,000 hit the paywall - 1,200 approve 100 USDC/month cap - 1,200 become active paying users

Your conversion rate at each stage depends on your product and audience. Checkout approval lowers the barrier to trying the product, but fewer users ultimately approve recurring billing. Signup approval gives you a more predictable funnel, but at the cost of early friction.

Which Should You Choose?

• Use signup approval if you want only committed users, or if your onboarding cost is high.
• Use checkout approval if your product benefits from easy exploration, or if trust is a concern.
• Consider hybrid approaches: limited free usage, with clear messaging about approval requirements later.

How Reclack Handles Recurring Billing Approval

At Reclack, we let you configure when to prompt for recurring billing approval. The cap is always visible. Every approval is a signed, onchain transaction, never unlimited, and never custodial. You can build flows for signup or checkout, depending on your UX and operational needs. Our docs have examples of both. We help you handle failed approvals, retries, and user notifications in a way that fits your product’s model.