How to Sell Usage Credits in Your AI App (Pay-as-You-Go Without Surprises)

Posted on Nov 2 • Originally published at shiptopaid.com

Your app calls an AI model, and every time someone uses it, you pay a little. A flat monthly price works until one customer uses it a hundred times more than everyone else. Then you start wondering whether you should charge by use instead. Credits are the usual answer: the customer pays up front for a balance, and each use takes some of it away.

I'm Deepak, a developer in Hyderabad. I build side projects with AI agents and spend a lot of my time wiring payments into apps made with Claude Code, Cursor and Codex. This guide covers the ways to charge by usage, the choices you have to make before your agent writes anything, what Polar and Stripe offer, and what to test. No code needed.

Everything I say about Polar and Stripe comes from their own docs, as of 30 Oct 2026, linked so you can check again. Usage billing is one of the faster-changing parts of both, so re-read the docs before you rely on a detail.

Pick a unit your customers understand, like "1 credit = 1 image". Decide what happens when someone runs out. Keep one clear record of each person's balance, and make sure two quick clicks can't spend the same credit twice. Add credits only when the payment provider confirms the payment, and only once per payment. Then test all of it in test mode before a real customer does.

There are three common setups. They sound similar, but they feel very different to the customer.

For a small app, packs or a monthly allowance are usually easier to explain and harder to get wrong, because the customer has paid before they use anything. Billing afterwards makes more sense when your customers are businesses that expect it. I'm not going to pretend one of these sells better; it depends on your app and your customers.

If you're still deciding between one-time, subscription and credits in general, my guide on how to charge for your vibe-coded app covers that first choice.

"Tokens" mean something to you. They mean very little to most customers. A unit tied to what the customer actually gets is easier: one credit per image, per document summarised, per minute of audio. If different actions cost you very different amounts, give them different prices in credits ("a quick answer costs 1 credit, a long report costs 5") and show that price before the person clicks.

To set the price, work out what one use costs you: the AI model's charge for a typical request, plus anything else that use triggers, like storage. Your provider's pricing page and your own usage dashboard will tell you. Then add a margin that also covers the payment provider's fees and the uses that fail and get retried. I can't give you a number, because it depends entirely on your model and your app, so measure a few real uses rather than guessing.

Keep credits as whole numbers. "You have 37 credits left" is clear; "you have 3.72 credits" invites questions, and fractions are where balance bugs like to hide.

Decide this before you build, because your agent will pick something if you don't.

On Polar, usage-based billing works like this: your app sends Polar a small message each time a customer uses something (Polar calls these events), and a meter counts or adds them up per customer. Polar labels usage-based billing a new feature.

On Stripe, the usage-based billing page now says Metronome is part of Stripe and is the recommended starting point for new usage-based setups, including prepaid credits. The older "basic" usage billing, built on meters, is still fully supported and, according to the same page, works more fully with Stripe Checkout. If your agent suggests one or the other, this is why; ask it which one it's using and why.

So on Stripe, "1 credit = 1 image" packs aren't something you switch on. Many small apps keep that balance in their own database and use Stripe Checkout only to sell the packs. That's a perfectly normal setup; it just means your app owns the balance.

Whichever provider you use, these are the parts your agent has to get right. Each comes with something you can ask it.

Use Polar's sandbox or Stripe's test mode with their test cards. Go through this list as a customer would:

If you want customers to try the app before buying, a few free starter credits work like a small trial; my guide to adding a free trial covers the trade-offs. And if someone ever says they paid but got no credits, my guide on why customers get locked out after paying walks through the usual causes.

I made ShipToPaid so AI agents get payments right in apps like yours. The full pack has a usage credits skill and an add-credits command that guide your agent through a credit balance in your own database and/or Polar usage billing, with credits added only from verified payment messages and spending done in one safe step. To be clear about its limits: the starter app itself sells subscriptions, not credits, and the skill says its Polar usage-billing examples are checked against Polar's code library but haven't been tested with live usage billing. You don't need any of it to follow this guide.