Why AI apps use credits
AI apps often need a unit system in addition to subscriptions. A user might buy a monthly plan, a one-time credit pack, or extra usage for generations, API calls, or compute-heavy actions.
Credits let your product represent those actions as units that can be checked and consumed from a backend flow instead of relying only on plan names or frontend state.
Why Stripe payment alone is not enough
Stripe can collect the payment for an AI credit pack, but your product still has to answer runtime questions after checkout: whether the subject has access, how many units remain, and when a generation or API request should spend those units.
Licenzy connects the Stripe purchase to entitlement state, then exposes access checks and usage consumption through backend runtime endpoints.
Recommended flow
- Start checkout with
POST /v1/checkout/session. - Let payment create or update the user's entitlement.
- Check access from your backend with
POST /v1/access/check. - Run the generation, API call, or compute action.
- Consume units with
POST /v1/usage/consumeafter the real work is accepted or completed.
Consume after work happens
Tie usage consumption to the completed business event. Use an idempotency key so retries do not spend the same AI credits twice.
Common mistakes
- Tracking credits only in the frontend instead of in a trusted backend flow.
- Consuming credits before the generation, API call, or compute action completes.
- Retrying consumption without a stable idempotency key for the business event.
- Ignoring
insufficient_usageinstead of returning a top-up or checkout path. - Assuming Stripe payment success is the same thing as current runtime access.
