Monthly Credits or Pay As You Go? Build Both Without Two Billing Systems

For your Q4 2026 pricing review, the useful question is not simply “subscriptions or usage-based billing?” It is whether customers can choose a predictable replenishment schedule without losing the flexibility to buy credits only when they need them.

A research tool may be used every working day. A video generator may be used heavily for one launch and then sit idle. The same product can serve both patterns. A credit wallet gives you a common usage layer; recurring purchases and one-off top-ups become two ways to fund it.

Here is how to design that hybrid in Cred, based on the platform's capabilities as of October 11, 2026.

Separate funding from consumption

There are three distinct decisions:

• What is being consumed? Your application credit type represents the unit users spend.
• What can customers buy? Pricing tiers define credit packages and their prices.
• When do customers pay? A checkout can be a one-off purchase or an explicitly requested recurring subscription.

Do not mix application credits with the CRD credits that fund your own Cred API usage. They serve different purposes: your customer's balance powers your product; your platform balance powers your integration.

Keeping those layers separate means a monthly customer and an occasional customer can use the same feature-metering logic. You do not need a second consumption system just because one customer pays on a schedule.

Recurring billing must be an explicit choice

Cred supports pricing tiers configured for one-time purchases, monthly recurring purchases, or both. However, labeling a tier as recurring does not silently turn an existing checkout integration into a subscription.

The hosted checkout request must explicitly send billing: "recurring" to create a subscription. A request that omits that choice remains one-off. This distinction protects existing integrations and, more importantly, makes the customer's recurring commitment deliberate.

In your purchase screen, show the payment schedule before checkout. A monthly credit package and a one-off top-up should not share an ambiguous “Buy” action if the customer cannot tell which commitment they are making.

See the hosted checkout reference and subscription reference for the current request fields.

Fund renewals from paid invoices, not checkout redirects

Opening checkout is not payment. Returning to a success page is not payment. Creating a subscription is not proof that its first invoice has been paid.

Cred's recurring credit issuance is tied to a paid Stripe invoice. The invoice reference is used to prevent that invoice from funding the wallet twice when processing paths retry. The checkout session itself is not the source of recurring credit issuance.

This matters for both the first payment and subsequent renewals. The wallet should reflect a confirmed paid invoice, not a browser navigation or an application-side assumption.

For Stripe Connect subscriptions, webhook processing supplies updates. When you use your own Stripe keys, renewals are picked up by the reconciliation sweep rather than an immediate renewal webhook path. Design your interface to tolerate that delay; do not promise that every renewal balance update is instantaneous.

Cancellation and card management are different actions

A complete hybrid offering needs more than checkout. Customers also need to stop future renewals and recover from payment failures.

Cred exposes subscription cancellation through its API and dashboard. Its subscription portal endpoint returns a short-lived Stripe link for payment-method and invoice management. That portal is not a general plan-switching interface: cancellation and plan changes are disabled there to preserve the crediting model.

If someone moves from monthly replenishment to Pay As You Go, your application must explicitly cancel the subscription according to your chosen cancellation timing. Adding a one-off purchase button does not cancel an existing agreement. Likewise, changing a label in your pricing screen does not stop Stripe renewals.

Communicate the effective cancellation state clearly. Do not infer an unused-credit expiry or automatic balance removal from subscription cancellation; those are separate policies you must define and support.

Test the customer journeys, not just the checkout

Before your next launch, walk through these cases:

1. An occasional customer buys once and has no subscription created.
2. A monthly customer receives credits after the initial invoice is paid.
3. A renewal is processed more than once but adds credits only once.
4. A failed payment does not grant a new allowance.
5. A customer cancels, and your interface reflects the actual subscription state.
6. A customer updates a card using a fresh portal link.
7. A customer buys a top-up without accidentally starting another subscription.

Hybrid pricing is not a claim that every customer wants a subscription. It is a way to offer predictable replenishment and occasional spending without fragmenting your ledger.

Start with one credit type, make the billing choice explicit, and build against the current Cred documentation. Your pricing page can stay flexible while the wallet remains consistent.