What is Prepaid vs. Postpaid Billing?

Prepaid billing collects payment before a customer uses anything. Postpaid billing charges after consumption has occurred. The distinction seems purely financial, but it shapes customer behavior, fraud exposure, cash flow, and how you architect your product's entitlement and metering layers. For AI and usage-based businesses in particular, choosing the wrong model for your customer profile creates problems that compound as you scale.

How Prepaid billing works

The customer pays upfront for a quantity of future usage like credits, tokens, API calls, or a time period. Your billing system converts that payment into an entitlement balance. As the customer uses the product, your metering layer decrements the balance. When it reaches zero, access either stops or a top-up is triggered.

The key operational requirement: your entitlement system has to check the balance at the point of consumption and enforce the limit in real-time. Batch-processed metering doesn't work for prepaid models. If your system calculates usage at the end of the day, a customer can burn 10x their balance before you catch it.

Prepaid is the model behind credits, tokens, and "buy X calls" pricing. Stripe's credit system, AWS credits, and most AI API products use variants of prepaid.

How Postpaid billing works

The customer uses the product and gets an invoice or charge at the end of the period, most typically monthly. Your billing system aggregates usage over the period and calculates the charge at billing time. Credit card products auto-charge. B2B enterprise accounts typically receive an invoice with net payment terms.

The key operational requirement: reliable usage aggregation. Your metering system needs to capture all consumption accurately over the period and feed those numbers into the billing calculation. Dropped events or late-arriving data create invoices that don't match reality. See revenue leakage for how this goes wrong.

Postpaid is the default for subscription SaaS (monthly recurring charges) and for API platforms with committed contracts (pay for what you use, get billed monthly).

Prepaid vs. Postpaid: tradeoffs

Prepaid vs. Postpaid in the AI Era

AI products have pushed prepaid into mainstream B2B billing because API consumption is unpredictable by nature. A single agent run can consume thousands of tokens in seconds. Postpaid billing for AI creates two problems that don't exist for traditional SaaS.

Postpaid AI billing creates unbounded cost exposure. A customer's agent misbehaves, gets stuck in a loop, and runs 100x their expected usage in an hour. On a postpaid model, they get a bill at the end of the month for an amount they never anticipated. On a prepaid model, the balance hits zero and consumption stops. From the customer's perspective, prepaid credits are a spending control mechanism, not just a pricing format.

Postpaid creates credit risk at scale. If you're an AI API platform with thousands of customers consuming at variable rates, a meaningful percentage will fail to pay postpaid invoices whether through fraud, genuine surprise at their bill, or simple payment failure. With prepaid, you collect before serving any compute. The credit risk is eliminated.

This is why OpenAI, Anthropic, and most AI API platforms default to prepaid credits. The model isn't just commercially preferable as it's operationally safer when usage spikes are a product feature, not an edge case.

Hybrid Models

Most mature billing stacks combine both models:

Prepaid with postpaid overage: Customers prepay for a base allocation. If they exceed it, overages are charged postpaid at the end of the period. This gives customers spending predictability while letting them burst without hitting a hard wall. The complexity is in how overage is priced (same rate? penalty rate?) and when it's invoiced.

Committed spend with prepaid top-ups: Enterprise customers commit to an annual minimum spend (postpaid, invoiced) and buy prepaid top-up credits for burst capacity. The committed contract provides revenue predictability; the top-ups handle variable demand.

Postpaid with spend controls: Fully postpaid, but the customer sets a monthly spend cap. When usage approaches the cap, alerts fire. When it hits, consumption stops or requires manual approval to continue. This is postpaid with the risk controls of prepaid built on top.

Common Challenges

Unused prepaid balances create deferred revenue liability. Money collected but not yet consumed sits as deferred revenue on the balance sheet. For companies that sell large credit packs, this can be substantial and complicates revenue recognition. Under ASC 606, you recognize revenue as performance obligations are satisfied — i.e., as credits are consumed, not when they're purchased.

Credit expiry creates customer friction. Prepaid credits that expire push customers to either use them up quickly or feel they're wasting money. Expiry policies that are too aggressive generate complaints and refund requests. Policies that are too lenient create long-lived deferred revenue balances. The right answer depends on your cost structure and customer relationship, but it needs to be a deliberate policy, not a default.

Postpaid fraud is a real problem for API products. Developers who want free compute can create accounts, hit your API intensively, and disappear before the month-end invoice arrives. This is disproportionately common for postpaid AI API products. Rate limiting helps but doesn't solve it; payment pre-authorization at signup is more effective.

Switching models mid-flight is painful. A customer on postpaid who moves to prepaid has an in-flight period of consumption that needs to be reconciled before the new model kicks in. A customer moving from prepaid credits to a committed contract needs their credit balance treated correctly in the transition. These migrations require billing logic that most systems don't handle automatically.

FAQ

Q: Which model is better for reducing churn?

Postpaid has a lower signup barrier, which helps acquisition. Prepaid creates stickiness through credit balances so customers with unused credits are less likely to churn because switching means losing money. For enterprise, the committed contract model (a form of prepaid) creates the most lock-in.

Q: How do prepaid credits affect revenue recognition?

Credits sold are not revenue until consumed. You record a liability (deferred revenue) when credits are purchased and recognize revenue as credits are drawn down. If credits expire unused, you typically recognize the expired balance as revenue at expiry. Your accountant should specify the exact treatment, but the general principle is: cash received ≠ revenue earned for prepaid models.

Q: Can you mix prepaid and postpaid for different customer segments?

Yes, and most scaling businesses do. PLG self-serve customers often work well on prepaid (low credit card risk, immediate activation, spending control). Enterprise customers often need postpaid invoicing (purchase order processes, net terms). The challenge is managing both models in the same billing system without creating a split-stack problem. See hybrid pricing models for how companies structure this.

Q: What's the right auto-reload threshold for prepaid credits?

Most AI products set auto-reload triggers between 10–20% of the original purchase. Too low and the customer gets interrupted mid-workflow while the reload processes. Too high and they're holding a larger float than necessary. Let customers configure it, but set a sensible default.

Q: How does postpaid billing interact with dunning?

Postpaid creates payment collection risk that prepaid doesn't. Your dunning process needs to handle failed payments at month-end, not just at renewal. For high-usage postpaid accounts, the stakes are higher: a failed payment on a $50K monthly invoice requires a different response than a failed $99 subscription renewal.