Onchain Subscriptions vs One-Time Invoices in Crypto SaaS

Recurring revenue is the backbone of SaaS. In crypto, stablecoin payments offer instant settlement and global reach, but the model for billing is not obvious. Should you use onchain subscriptions or one-time invoices for recurring USDC billing? Each has tradeoffs in UX, failure handling, and implementation. Let’s break down the mechanics, with worked examples, so you can choose what fits your business.

Subscription Authorizations: How They Work, and When to Use Them

Onchain subscriptions let you collect recurring payments from a customer’s wallet without prompting them each time. The process looks like this:

1. Customer visits your checkout and agrees to a spending cap, a maximum amount per period.
2. They sign an onchain approval that lets your billing contract pull up to that amount, on a recurring schedule.
3. On each billing cycle, your backend submits a transaction to collect payment. The contract checks the cap and pulls the funds if allowed.

This is familiar to anyone who has used ERC-20 approve for DEX or DeFi protocols. For SaaS, the differences are the recurring schedule and the cap, which are explicit and visible to the user. No unlimited approvals. The customer signs, and the blockchain enforces the limit.

Example: $49/month SaaS Plan

Suppose your app charges $49 in USDC per month. Here’s how the subscription flow looks from a developer’s perspective:

// Solidity pseudo-code: Subscription contract interface
interface ISubscriptionBilling {
    function approveSubscription(address merchant, uint256 cap, uint256 interval) external;
    function collect(address customer, uint256 amount) external;
}

// Customer approves $49/month cap
tx1 = subscriptionContract.approveSubscription(
    merchantAddress,
    49e6, // USDC has 6 decimals
    30 days
);

// Each month, merchant calls collect
subscriptionContract.collect(customerAddress, 49e6);

The contract enforces the cap. If the merchant tries to collect more than $49 in a month, the transaction reverts. If the customer wants to cancel, they can revoke approval at any time. No one can increase the cap without a new signature from the customer.

When to Pick This Model

• You charge a fixed price, on a regular schedule.
• Churn is low, and you want low-friction renewals.
• The customer is comfortable setting a cap and delegating future payments within that limit.

Pros and Cons

Pros: - One signature covers many cycles. No need to prompt the user every time. - Predictable revenue collection, so long as the cap and balance allow. - Clean UX for trusted merchant-customer relationships.

Cons: - Customer must trust the merchant not to max out the cap each period (though this is enforced onchain). - Some users dislike any standing approval, even if bounded. - Edge cases: If a customer loses access to their wallet, revoking approval is harder.

One-Time Invoices: Granular Control, Explicit Payment

One-time invoices are the onchain equivalent of sending a bill for each period. The merchant creates an invoice and sends it to the customer, who must sign and submit payment each time.

1. Merchant generates a new USDC payment link or invoice for each billing period.
2. Customer receives a prompt (email, in-app, etc.) and pays from their wallet.
3. The merchant monitors for incoming payment and grants access on confirmation.

This is the default for many onchain interactions. Each payment is initiated by the customer, and no ongoing approval is needed.

Example: $49/month, Paid as Invoices

Suppose you use Reclack’s API to generate a USDC invoice each month. The customer gets a payment link:

// Node.js pseudo-code: Create an invoice with Reclack
const invoice = await reclack.createInvoice({
  payer: customerWalletAddress,
  amount: 49,
  currency: 'USDC',
  chain: 'base',
  description: 'Pro Plan - March 2024',
  dueDate: '2024-03-31'
});

// Customer pays via wallet
// Reclack monitors the chain for a confirmed payment

The customer has to interact and sign each payment. If they skip a month, no funds move. The merchant can send reminders or expire unpaid invoices.

When to Pick This Model

• You want explicit authorization for every payment.
• Your users may churn often, or need to renew access only when they use the service.
• You offer variable pricing or metered billing, and the amount changes each cycle.

Pros and Cons

Pros: - No standing approvals. Customer pays only when they choose. - Easy to handle variable or one-off billing. - Simple to implement, especially for smaller SaaS or infrequent billing.

Cons: - More friction. If the customer misses a reminder, payment is late. - Churn risk is higher. Renewals drop if users ignore prompts. - More reminders and follow-ups. Some customers want set-and-forget.

Edge Cases and Failure Modes

Both models have edge cases that matter in practice.

Subscription collection can fail if the customer’s wallet has insufficient USDC or if the approval is revoked. Your backend must handle failed attempts, retry, and notify the customer to top up or reauthorize. The onchain transaction will simply revert and funds remain in the customer’s wallet.

Invoice payment can be delayed if the customer ignores or misses the invoice. Access may need to expire until payment arrives. There is no onchain way to force collection. This is safer for users but less predictable for the merchant.

How We See It at Reclack

We support both models because companies need both. If you want recurring USDC billing with a single, bounded approval, use subscriptions. If you want explicit customer sign-off each time, or have variable amounts, use one-time invoices. Our API lets you spin up either flow, and switch when your business needs change. You can learn more at reclack.com.