One of our customers recently came to us with an interesting requirement.
They are building an AI product where customers purchase credits and consume those credits while using the product.
The requirement sounded simple:
When a customer's credit balance reaches a certain threshold, automatically charge their saved payment method and add more credits.
For example:
A customer buys 1,000 credits.
They keep using the product, and eventually their balance reaches zero.
Instead of asking the customer to go through checkout again, the product should automatically charge, say, $10 to the customer's saved payment method and add another 1,000 credits.
Simple, right?
Not exactly.
The problem with charging later
The first payment is straightforward because the customer is actively going through checkout.
But the next charge could happen hours, days, or weeks later.
The customer isn't sitting on the checkout page anymore.
This is where off-session charging comes in.
The merchant needs to be able to charge a customer's saved payment method without requiring the customer to actively participate in every transaction.
For AI products, this becomes especially useful.
Think about products that charge based on:
- AI tokens
- API calls
- Agent runs
- Compute usage
- Image generations
- Credits
- Storage
- Other usage-based resources
You don't necessarily want the customer to manually purchase credits every time their balance gets low.
But there are more problems to solve
Once we started thinking about the requirement, it became clear that simply exposing a "charge customer" API wasn't enough.
There are several things that can happen.
What if the card gets declined?
What if the payment requires additional authentication?
What if the payment succeeds but the application doesn't receive the response?
What if the application retries the request and accidentally charges the customer twice?
When should the new credits actually be granted?
And how does the application know whether the payment eventually succeeded or failed?
The payment itself is only one part of the workflow.
How we approached it
We wanted the merchant's application to control when the charge should happen.
For example, the application might have logic like:
Credit balance < 100 → charge $10 → add 1,000 credits
The application already knows the customer's usage through Kelviq's metering and entitlement system.
Once the threshold is reached, it can initiate an off-session charge against the customer's saved payment method.
But importantly, the application shouldn't assume that initiating the charge means the payment succeeded.
The payment needs to go through its lifecycle.
Once the charge succeeds, the application can receive the corresponding webhook and grant the additional credits.
So the flow becomes:
Customer purchases → payment method saved → customer consumes credits → threshold reached → off-session charge initiated → payment succeeds → webhook received → credits added
This keeps payment processing and product access connected without requiring the customer to repeatedly visit checkout.
Beyond AI credits
While the initial requirement came from an AI credit use case, we realized the same mechanism can support many other scenarios.
For example:
Automatic credit top-ups
Automatically purchase another credit pack when the balance gets low.
Usage-based billing
Charge customers based on accumulated usage.
One-time add-ons
Allow applications to trigger purchases for additional features or resources.
Custom billing workflows
Build billing logic where the application determines when and how much a customer should be charged.
This was one of those features where a customer requirement initially looked very specific, but solving it properly opened up a much broader set of use cases.
Now available in Kelviq
Kelviq now supports off-session charging through our Charges API.
Merchants can charge a customer's saved payment method programmatically and combine it with Kelviq's usage metering, credits, and entitlements to build custom monetization workflows.
For us, this is also an interesting direction.
As AI products become increasingly usage-driven, billing can't always be modeled as just:
$20/month → unlock Pro plan
Sometimes the product itself needs to participate in the billing decision.
Usage happens → application evaluates it → billing action happens → entitlement changes.
That's the kind of billing infrastructure we're trying to build with Kelviq.
Top comments (0)