Managing Multiple USDC Subscriptions for a Single Customer

Recurring billing onchain is straightforward with a single subscription. Adding multiple subscriptions for the same customer introduces details you need to get right. Each subscription must be independently managed, authorized, and settled. The customer must see clear caps for each, and the system must avoid cross-contamination between approvals. This guide walks through the mechanics, from setup to handling failures, with a concrete example.

When You Need Multiple Subscriptions

A customer may need several independent services, each billed on its own schedule. SaaS products often have a base plan and add-ons. A marketplace might charge a monthly listing fee and a usage-based advertising fee. Each of these should be a separate subscription: the customer must approve them separately, and each must have its own cap. This ensures transparency and avoids surprises on the payer side.

Key Constraints and Expectations

• Every recurring USDC payment must be pre-approved by the customer, with a cap for each subscription.
• Approvals are not pooled: each subscription is authorized and settled individually.
• No unlimited or global approval. The customer signs a cap for each recurring charge stream.
• Settlement is onchain, final, and non-reversible. No chargebacks after confirmation.
• USDC collection is currently supported on Base, Ethereum, and Polygon.

Designing Subscription Entities

Treat each recurring service as its own subscription object. Do not try to multiplex different recurring charges into a single approval. Each subscription has:

• A unique identifier (e.g., subscription UUID)
• The payer’s wallet address
• The merchant’s settlement address
• The period and amount (e.g., 100 USDC/month)
• The cap (e.g., 120 USDC max per period)

Store these in your backend and surface them in your UI and customer portal.

Example: SaaS Base Plan Plus Add-On

Suppose you offer a SaaS platform. The base plan is 100 USDC per month. There’s an optional analytics add-on for 30 USDC per month. A customer can subscribe to the base only, the add-on only, or both. Each is a separate subscription.

• Base Plan: 100 USDC/month, cap 110 USDC
• Analytics Add-On: 30 USDC/month, cap 35 USDC

Both subscriptions: the customer will see and sign two separate approval flows. Each approval is for the relevant cap, scoped to the merchant’s settlement address.

Managing Approvals and Customer Experience

Each subscription requires its own approval transaction. Do not bundle several subscriptions into one ERC-20 approval. For best UX, present them together when possible. The customer must:

1. Review the details and cap for each subscription
2. Sign each approval transaction from their wallet (e.g., via WalletConnect or browser extension)
3. Receive a confirmation per subscription

If the customer only approves one, only that subscription is active. The system should reflect this immediately.

Handling Approval Expiry and Cap Adjustments

If a customer wants to upgrade, downgrade, or cancel an add-on, adjust the cap and trigger a new approval. Do not re-use a previous approval for a higher cap. If the cap is lowered, the system should request a new approval to reflect the reduced limit. If the customer cancels, revoke the approval and mark the subscription as ended in your system.

Billing and Settlement Flows

Each subscription runs its own billing logic. At the start of each period, your backend attempts to collect the agreed USDC amount for each active subscription. The process is:

1. Check the customer’s allowance and balance for each subscription
2. Initiate a transfer, bounded by the cap
3. Wait for onchain confirmation
4. Mark the subscription cycle as settled on success

If the transfer fails (insufficient balance, revoked approval, or gas issues), retry following your project’s policy. Do not attempt to collect from a different approved cap. Each subscription’s funds must come from its own signed approval.

Worked Example: Customer with Two Subscriptions

Let’s say Alice subscribes to both the base plan (100 USDC/month, cap 110 USDC) and the analytics add-on (30 USDC/month, cap 35 USDC). At the start of the month:

• Your backend checks Alice’s wallet for both caps.
• For the base plan, it sees her ERC-20 approval to the merchant’s settlement address for 110 USDC. For the analytics add-on, it sees a separate approval for 35 USDC.
• You call transferFrom() for 100 USDC to settle the base plan, and transferFrom() for 30 USDC for the add-on. Each function call is scoped to the approved cap for that subscription.
• Both transactions are sent to the chain (e.g., Base or Polygon).
• When each is confirmed, mark that cycle as paid in your system.

If Alice only has 120 USDC in her wallet, the base plan will settle, but the add-on will fail (insufficient funds). Your system should notify Alice, retry according to your retry policy, and log the failure for the add-on without affecting the base plan subscription.

Avoiding Common Pitfalls

Never re-use a cap across subscriptions. Each approval must be tied to a specific recurring payment stream. If you try to settle multiple subscriptions against a single approval, you risk exceeding what the customer explicitly authorized.

Do not bundle into a single transaction. Onchain settlement must be atomic per subscription to match the customer’s approval and your internal records. If one subscription’s payment fails, the others should not be affected.

Always surface each subscription’s state. The customer portal and your support team must see the status of each subscription, including active, pending approval, failed, or canceled. This prevents confusion and simplifies support.

Implementation Notes

A non-custodial platform like Reclack does not hold funds, so your system should:

• Track each subscription’s approval and cap
• Attempt settlement for each independently
• React to onchain failures by retrying or marking the cycle as failed
• Never prompt for a private key or request unlimited approval

If you are building the integration, you may use a webhook or polling to detect onchain confirmations. Your UI should surface success or failure per subscription, not as a batch.

Handling Upgrades and Add-Ons

If a customer wants to add another service mid-cycle, prompt for a new approval and create a new subscription object. Do not merge it with the existing approval. If the new service starts mid-period, pro-rate the first charge if that matches your billing model. Always show the cap before requesting the approval.

How We Handle Multiple Subscriptions at Reclack

We designed Reclack so that each subscription is its own object, approval, and onchain settlement. This lets you offer flexible SaaS plans, add-ons, or usage-based services to the same customer without confusion or risk. Each approval is strictly bounded, visible to the customer, and never pooled. If you want to see how this works in practice, or if you are ready to try it, see reclack.com.