# How OpenAI Billing Works: ChatGPT Subscriptions, API Tokens and Credits

> How OpenAI billing works across ChatGPT plans and the API: subscriptions, per-token metering, prepaid credits, spend caps, rate tiers, and the billing architecture AI founders can copy.
- **Author**: Ayush Agarwal
- **Published**: 2026-04-07
- **Modified**: 2026-10-06
- **Category**: AI, Billing
- **URL**: https://dodopayments.com/blogs/en/openai-billing-model

---

**OpenAI billing runs as two separate systems on one account. ChatGPT is sold as a fixed monthly or per-seat subscription, and the API is sold as pay-as-you-go metered billing charged per token at a rate that differs for every model.** Paying for one does not pay for the other, and that split is the single most common source of confusion on an OpenAI invoice.

Around both sits a shared layer of prepaid credits, spend caps, rate limit tiers, and enterprise invoicing. That layer is what lets a casual chat user and a production API workload live on the same account system without sharing the same pricing logic.

Most people searching **openai billing** or **open ai billing** want one of two answers. If the question is why a ChatGPT charge appeared or which plan to pick, the plan lineup section below covers it. If the question is **openai api billing** specifically, the short answer is that a single request is split into four separately priced components - input tokens, cached input tokens, cache writes, and output tokens - each billed per million tokens at a rate published per model, and settled either against a prepaid balance or a card charged as usage accrues.

The rest of this piece is about how those pieces connect, because the architecture is far more durable than any published rate. Every rate on OpenAI's price sheet has changed multiple times since launch; the four-layer structure of subscriptions, credits, meters, and spend controls has not.

OpenAI's monetization model matters because many AI founders now need the same thing: a hybrid stack that supports subscriptions for end users, prepaid credits for developers, and usage controls for enterprise buyers. Delivering that cleanly depends on solid [entitlement management](https://dodopayments.com/blogs/entitlement-management-saas) and a self-serve [customer billing portal](https://dodopayments.com/blogs/customer-billing-portal) so buyers can manage their own plans.

OpenAI API pricing page snapshot showing per-token model rates published separately for input, cached input, and output

For adjacent strategy reading, see [AI pricing models](https://dodopayments.com/blogs/ai-pricing-models), [Pay as you go AI SaaS](https://dodopayments.com/blogs/pay-as-you-go-ai-saas), and [API monetization](https://dodopayments.com/blogs/api-monetization). For a side-by-side on the other frontier lab, read the [Anthropic billing model breakdown](https://dodopayments.com/blogs/anthropic-billing-model), compare [how Anthropic prices Claude](https://dodopayments.com/blogs/claude-token-cost-explained-2026), and check the [margin math on Claude API pricing](https://dodopayments.com/blogs/anthropic-claude-api-pricing-margin).

## OpenAI billing in one sentence

OpenAI billing combines:

- **ChatGPT subscriptions** for consumers and teams
- **prepaid API credits** for developers
- **usage-based token billing** for model consumption
- **spend controls and invoicing** for larger organizations

That is why OpenAI can serve a casual ChatGPT user and a production API customer without forcing both into the same payment logic.

### ChatGPT billing vs API billing, side by side

The two systems share an account and almost nothing else. This is the table to read first if you are trying to work out which one your charge came from.

| | ChatGPT subscription billing | OpenAI API billing |
| --- | --- | --- |
| What you buy | Access to the product for a period | Compute measured per request |
| Unit of charge | A seat or a plan, per month | Input, cached input, and output tokens |
| When you are charged | On a fixed renewal date | Continuously as usage accrues, or drawn from prepaid balance |
| Price predictability | Known before the month starts | Varies with model, prompt length, and volume |
| Who it is built for | End users and internal teams | Developers embedding models in their own product |
| Overage behaviour | Plan limits, now extendable with credits | Spend caps and rate tiers, then hard stop |

The practical consequence: a ChatGPT Plus or Business subscription grants no API credits, and an API balance does not raise a ChatGPT plan limit. They are billed, metered, and capped independently.

## The ChatGPT plan lineup

OpenAI's consumer and team plans are built around predictable monthly spend. Rather than reprint a price list that moves several times a year, the useful thing to study is the shape of the ladder, which has stayed remarkably stable even as the figures on it change. Check OpenAI's own pricing page for the current numbers before you model anything against them.

| Tier | Billing model | What the buyer is really purchasing |
| --- | --- | --- |
| Free | No subscription | Limited access, capped usage, lower priority |
| Entry paid tier | Flat monthly subscription | More messages, uploads, and memory than Free |
| Standard paid tier | Flat monthly subscription | Advanced reasoning models, projects, custom GPTs |
| Power tier | Flat monthly subscription sold in usage multiples | Same core features, a much larger usage allowance |
| Business | Per-seat subscription, annual or monthly, with a seat minimum | Shared workspace, admin controls, unified billing |
| Enterprise | Custom invoiced contract | Security, controls, data residency, volume discounts, SLAs |

As a dated checkpoint against that abstract ladder, here is what OpenAI actually published in September 2026. The consumer lineup is Free, Go, Plus, Pro, Business, and Enterprise. Go is a newer low-cost entry tier that OpenAI has said may include ads. Plus sits at $20 per month with no annual option. Pro is the clearest illustration of the capacity-multiple idea in the table above, because it is now sold at two separate price points, $100 and $200, where the $200 tier is branded Pro 20X for its usage multiple. OpenAI paused new signups and upgrades to that $200 tier on 10 September 2026, which is a useful reminder that a top tier priced on capacity is also a capacity commitment the vendor has to honour.

Note also that the seat tier is now called Business. Older write-ups call it Team, and that name is retired.

Three architectural details matter far more than the exact numbers, and they are the parts you can safely copy.

**The ladder is deliberately uneven.** The gaps between adjacent tiers widen sharply as you climb. The first steps are small enough to be an impulse upgrade, while the jump into the top consumer tier is a multiple of everything below it. OpenAI is not spacing tiers evenly by feature. It is spacing them by willingness to pay, with a wide top band absorbing the small number of users whose consumption would otherwise break the unit economics of the standard plan.

**The top tier is sold on capacity multiples, not features.** The highest consumer tiers ship the same core capabilities and differ mainly in how much usage they include, expressed as a multiple of the standard plan. That is metered billing wearing a subscription costume, and it is the cleanest example in the market of charging heavy users more without ever showing them token math. If you are pricing a chat product, the same trick is covered in more depth in this breakdown of [profitable AI chat app pricing](https://dodopayments.com/blogs/profitable-ai-chat-app-pricing).

**Consumer plans now include credits.** OpenAI lets users extend usage with ChatGPT credits once plan limits are reached, and some enterprise and education agreements scale usage against credits instead of fixed limits entirely. The subscription and the meter are no longer separate systems.

One more shift worth watching: advertising has entered the conversation as a subsidy for the cheapest paid AI tiers. If that becomes normal, it changes what an entry tier is allowed to cost for everyone else in the market, and it gives incumbents a second revenue line to defend a price point that pure subscription businesses cannot match.

## OpenAI API billing: how token costs are calculated

**OpenAI API billing is pure pay-as-you-go metering with no seat, no plan, and no monthly minimum.** You add a payment method or prepay a balance, and every request draws down against it at a rate determined by the model you called and the number of tokens that moved in each direction.

The API side works differently from ChatGPT in every respect that matters. Developers are billed by model and by usage, and a single request is decomposed into separately priced components: input tokens, cached input tokens, cache writes, and output tokens. Rates are published per million tokens and differ for every model in the lineup, from flagship reasoning models down to the small, cheap models built for classification and routing.

The same architecture shows up across every serious AI product that resells inference. [Cursor's billing model](https://dodopayments.com/blogs/cursor-billing-model) wraps it in a dollar-denominated usage pool, and [Anthropic's billing model](https://dodopayments.com/blogs/anthropic-billing-model) exposes it almost identically, which is why the comparison in [AI billing platforms](https://dodopayments.com/blogs/ai-billing-platforms) is mostly a comparison of packaging rather than of meters.

Deliberately, this article does not reprint those rates. Model names and per-token prices change several times a year, and a table copied into a blog post is wrong within a quarter. Read the current numbers from OpenAI's own pricing page and treat them as a live input to your cost model rather than a constant you hardcode. The billing architecture around those rates changes far more slowly, and that is what is worth learning.

The structural facts survive every price revision:

- output tokens cost several times more than input tokens on the same model
- cached input is priced at a steep discount against fresh input, which makes prompt reuse a first-class cost decision
- the smallest model in a family can be an order of magnitude cheaper than the flagship for the same request shape
- tool calls, file storage, sandboxed code execution, and audio all meter separately from text tokens
- audio is materially more expensive than text on the same model

### Four pricing dimensions, not one

Most cost models treat "price per token for model X" as a single number. It is not. OpenAI prices the same model along at least four axes, and an estimate that ignores them will be wrong in production, usually in the expensive direction.

**Context length.** Past a published context breakpoint, long requests move to a higher rate for both input and output. Cost per request can rise sharply purely from conversation length, with no change in model choice. Long-running chat threads are the usual culprit, because every turn resends the transcript and the meter counts it again.

**Latency tier.** The same model is sold at several service tiers: an asynchronous batch tier, a best-effort flexible tier, a standard tier, and a priority tier that buys lower and more consistent latency. Batch and flex are published at a discount against standard, and priority carries a premium over it. The spread between the cheapest and most expensive way to run an identical prompt is large enough that for any workload without a human waiting on the response, moving it to batch is the single biggest lever on gross margin.

**Caching.** Cached input runs at a fraction of standard input, but newer model families also charge for the cache write itself. Caching is therefore a decision with its own cost rather than a free optimization. It pays off when the same prefix is reused many times across requests, and it can lose money when it is not.

**Tools and modalities.** Tool calls meter separately from tokens. Web search is billed per block of calls, file search charges for stored data per day above a free allowance plus a per-call fee, sandboxed code execution is billed per session by container size, and realtime audio is priced separately from text on the same model. Regional processing endpoints for data residency also carry an uplift on eligible models, so compliance has an explicit line-item price.

That is the core of **openai API credits** and usage billing: cost follows consumption rather than seats. Capturing it accurately on your own side is an architecture problem, not a pricing-page problem, and it is worth reading how to structure [metering LLM token usage](https://dodopayments.com/blogs/metering-llm-token-usage-architecture) before you commit to a schema.

## How OpenAI API billing works for developers

**OpenAI API billing is a prepaid, dollar-denominated balance that every request draws down per token.** A developer tops up the account, each call deducts its input and output token cost from that balance at the rate for the model used, and when the balance hits $0 the API stops accepting calls. Pricing pages describe the rates; this is the account mechanics underneath them.

| Mechanism | How it works on the OpenAI API | Why it matters to the buyer |
| --- | --- | --- |
| Prepaid credits | Top-ups of $5, $10, $50 or more, shown as a dollar balance that can only be spent on OpenAI | Low entry cost, no invoice to chase, no surprise bill |
| Per-token charging | Input and output tokens are metered separately and deducted from the same balance, at different rates per model | Cost follows the prompt and response size, not a seat count |
| Credit expiry and refunds | Purchased credits expire one year after purchase and are non-refundable | Long enough to remove "use it or lose it" pressure on larger top-ups |
| Zero-balance behaviour | API calls fail once the balance reaches $0 | A runaway loop cannot create debt |
| Auto-recharge | Buys more credits automatically when the balance falls below a threshold the user sets | Keeps production traffic running without manual top-ups |
| Usage tiers | Rate limits rise as total spend accumulates over time | Throughput grows with billing history, without a sales call |

### Prepaid credits are the payment layer

The credit balance is the actual payment instrument on the API side. Because the money arrives before the compute is consumed, OpenAI carries no collection risk, and the developer gets a natural budget ceiling. Denominating credits in US dollars rather than abstract points also means a developer can read the cost of a request directly, which makes budgeting far easier for a finance team.

### Per-token charging is the meter

Every request produces usage for input tokens and output tokens, and each is converted to dollars at the published rate for the model that served it. Output is priced higher than input on the same model, so two requests with the same total token count can cost very different amounts. The four pricing dimensions above - context length, latency tier, caching, and tools - all change how many dollars a given request deducts.

### Usage tiers and spend limits are the control layer

Usage tiers tie rate limits to cumulative spend: a new account starts with conservative throughput, and limits rise as verified spend builds. Spend limits sit alongside them as a budget control, so a team can cap what a project or organisation consumes in a period. Together they turn billing history into a trust signal, which is the same idea behind tying [customer quotas to usage](https://dodopayments.com/blogs/openai-usage-limits-customer-quotas).

### Auto-recharge closes the loop

A prepaid balance that hits $0 in production is an outage. Auto-recharge solves that by charging the saved card for a fixed top-up whenever the balance drops below a chosen threshold. The trade-off is that the card on file now carries production uptime, so failed recharge charges need the same retry and card-updater treatment as subscription renewals.

### Rebuilding OpenAI API billing with Dodo Payments

The same model maps directly onto Dodo's primitives, and Dodo's own walkthrough uses exactly this structure. The steps:

1. **Create a fiat credit entitlement** in USD with [credit-based billing](https://docs.dodopayments.com/features/credit-based-billing), so one credit equals one dollar and balances track cents. Set expiry to 365 days to mirror OpenAI's one-year expiry, or to never expire.
2. **Sell top-up packs** as [one-time payment products](https://docs.dodopayments.com/features/one-time-payment-products) that each grant credits equal to the pack's dollar value, so a $50 pack issues 50 credits.
3. **Create token meters** such as `llm.input_tokens` and `llm.output_tokens` with [usage meters](https://docs.dodopayments.com/features/usage-based-billing/meters), using sum aggregation on a `tokens` property, then enable billing usage in credits and set "meter units per credit" from your own price. If you charge $2.50 per million input tokens, that is 400,000 tokens per credit.
4. **Send usage events** after each model call through [event ingestion](https://docs.dodopayments.com/features/usage-based-billing/event-ingestion), with a unique event ID per request so retries never double-deduct. The [LLM ingestion blueprint](https://docs.dodopayments.com/developer-resources/ingestion-blueprints/llm) wraps an OpenAI, Anthropic, Gemini, Groq, OpenRouter, or Vercel AI SDK client and reports input, output, and total tokens automatically.
5. **Enforce the zero balance in your app.** Dodo does not block usage when a balance reaches zero, so check the customer's credit balance before forwarding a request and reject it (for example with a `402`) if it is empty. Set a low-balance threshold and listen for [credit webhooks](https://docs.dodopayments.com/developer-resources/webhooks/intents/credit) to warn users before they run out.

A top-up purchase is a standard hosted checkout for a credit pack product:

```typescript
import DodoPayments from 'dodopayments';

const client = new DodoPayments({
  bearerToken: process.env['DODO_PAYMENTS_API_KEY'],
});

// $50 credit pack product that grants 50 USD fiat credits
const session = await client.checkoutSessions.create({
  product_cart: [{ product_id: 'pdt_credit_pack_50', quantity: 1 }],
  customer: { email: 'developer@example.com', name: 'Developer Name' },
  return_url: process.env['TOPUP_RETURN_URL'], // e.g. your dashboard URL
});
console.log(session.checkout_url);
```

Three operational details are worth planning for. Credit deductions are processed asynchronously by a background worker roughly once a minute, so strict real-time enforcement needs a local balance cache. Refunding a credit pack does not remove the credits it granted, so issue a matching debit when you refund. And spend-based usage tiers are something you build yourself: add each `payment.succeeded` amount to a lifetime-spend field and map spend bands to rate limits in your API middleware.

Because Dodo acts as the [Merchant of Record for AI products](https://dodopayments.com/blogs/merchant-of-record-ai), the tax on every top-up across jurisdictions is calculated, collected, and remitted for you. If you are still choosing a metering vendor, this roundup of the [best billing platforms for usage-based pricing](https://dodopayments.com/blogs/best-billing-platform-usage-based-pricing) compares the options.

## The billing architecture that ties it together

This is the clearest way to think about the full OpenAI billing system.

```mermaid
flowchart LR
    A["ChatGPT subscriptions"] --> E["Unified billing system"]
    B["API credits"] --> E
    C["Enterprise controls"] --> E
    D["Usage meters"] --> E
```

### Consumer side

The consumer side is simple on the surface:

1. user chooses a ChatGPT plan
2. card or workspace billing charges monthly
3. plan controls limits, feature access, and model access
4. usage caps shape behavior without exposing token math to the customer
5. credits let heavy users extend past plan limits without changing tier

Step five is the recent change. A pure subscription forces every heavy user into either an upgrade or a hard stop. Adding credits on top of a subscription creates a third option, and it converts what used to be a support conversation into revenue.

### Developer side

The API side is more explicit:

1. developer adds a payment method or prepays balance
2. every API request creates usage events
3. model-specific token pricing calculates cost
4. account spend limits and rate tiers control throughput

### Enterprise side

Larger buyers usually need:

- spend caps by workspace or project
- invoice-based payment terms
- administrative controls and permissions
- reporting for finance, security, and procurement

This is where **openai subscription billing** stops being only a monthly plan question and becomes a revenue-ops question.

## Why OpenAI's billing model works

### 1. It matches pricing to audience

Consumers want a predictable monthly bill. Developers want to pay for actual usage. Enterprise buyers want control, reporting, and negotiated terms. OpenAI uses a separate commercial logic for each without fragmenting the brand.

### 2. It separates compute from packaging

ChatGPT sells access, convenience, and product experience. The API sells raw capability and throughput. Those are related products, but not the same monetization surface.

### 3. It supports hybrid monetization

OpenAI effectively shows why AI companies should not force everything into one billing model. Hybrid monetization is becoming normal for AI apps, wrappers, copilots, and platforms.

The clearest evidence is that the two systems have started converging. Subscriptions now carry credits for overage, and Enterprise flexible pricing drops fixed rate limits entirely in favor of credit-based consumption. OpenAI did not choose between subscriptions and usage billing. It built both and let customers sit anywhere on the spectrum, which is a harder engineering problem than either model alone.

### 4. It gives buyers a cost lever

The batch, flex, standard, and priority tiers let a customer trade latency for money without leaving the platform or renegotiating a contract. A team whose margins are under pressure can move background jobs to the asynchronous tier and cut that line of spend substantially. That keeps cost-sensitive customers on the platform instead of pushing them toward a cheaper competitor, and it is a pattern worth copying for any product with meaningful compute cost.

> The most important lesson from OpenAI billing is not the token rate. It is the packaging strategy. Subscriptions, credits, and enterprise controls are all different wrappers around the same core compute engine.
>
> - Ayush Agarwal, Co-founder & CPTO at Dodo Payments

## What AI founders should copy from OpenAI billing

This is the part that actually transfers. A short list of mechanisms does most of the work, and each one is buildable in a sprint or two if you get the data model right at the start.

### Subscriptions for human-facing products

If your product is used like software rather than infrastructure, monthly plans create better buyer confidence than raw token pricing. That is why ChatGPT plans feel more natural than exposing end users to meter math. The rule of thumb: if the person paying is also the person clicking, sell a plan. If the payer is integrating you into their own system, sell a meter.

The subtlety is that a plan is not a promise of unlimited compute. Publish an included allowance in units your buyer understands, such as messages, documents, or minutes, and keep the token accounting private. You still meter everything internally, because you cannot price a plan you have never measured.

### Prepaid credits for API and agentic workloads

Credits solve three problems at once: they collect cash before you spend it on inference, they cap your bad-debt exposure to zero, and they give a buyer a hard ceiling that no runaway loop can breach. That combination is why every serious AI API converges on them.

A credit system that works in production needs a handful of concrete pieces:

- a ledger, not a balance column, where every top-up, consumption event, refund, and adjustment is an append-only row and the balance is derived
- idempotent debits keyed on the request ID, so a retried webhook or a timed-out call never double-charges
- an explicit policy on expiry, refundability, and whether promotional credits burn before purchased credits
- auto-recharge with a threshold and a top-up amount, plus a cooldown so a runaway agent cannot trigger dozens of charges in a minute
- low-balance and zero-balance webhooks that fire early enough for a human to react

Credits are also a cashflow instrument, not just a control, which is the argument laid out in [billing credits, pricing and cashflow](https://dodopayments.com/blogs/billing-credits-pricing-cashflow). If you are adding this to an existing app, the practical sequencing is covered in [how to add credits billing to an AI app](https://dodopayments.com/blogs/add-credits-billing-ai-app), and the primitives are documented in [credit-based billing](https://docs.dodopayments.com/features/credit-based-billing).

The pressure on this design is increasing because the spender is no longer always a human. When an autonomous agent holds the budget and decides when to spend it, a prepaid balance stops being a convenience and becomes the enforcement boundary. That shift is what [agentic billing](https://dodopayments.com/blogs/agentic-billing) is about, and the emerging machine-payment rails are worth understanding before you design the ledger: the [x402 protocol](https://dodopayments.com/blogs/x402-protocol) covers per-request payment over HTTP, and the [AP2 protocol for agent payments](https://dodopayments.com/blogs/ap2-protocol-agent-payments) covers how an agent proves it was authorised to spend on someone's behalf. If your product is the thing an agent calls rather than the agent itself, [MCP payments for AI agents](https://dodopayments.com/blogs/mcp-payments-ai-agents) is the closer read.

The catch is card-on-file reliability. When a customer's saved card expires or a top-up charge fails, that revenue silently disappears unless you have an [account updater service](https://dodopayments.com/blogs/account-updater-service) and [payment retry logic](https://dodopayments.com/blogs/payment-retry-logic) keeping stored credentials fresh.

### Usage metering you can defend in a dispute

Metering is where most AI billing stacks quietly break. The requirement is not "count tokens", it is "reconstruct any invoice line from raw events, months later, without the customer arguing".

Emit one usage event per request, and record at minimum:

- request ID, customer ID, API key ID, and project or environment
- model identifier and service tier used
- input tokens, cached input tokens, cache writes, and output tokens as separate fields
- tool calls, storage, and audio seconds as their own metered dimensions
- your upstream cost and your billable amount, stored separately
- timestamp and an idempotency key

Store the raw events immutably and aggregate for billing, never the reverse. Aggregates cannot be re-derived once the detail is gone, and the first serious customer dispute will ask for the detail. Reconcile your aggregate against the provider's own invoice on a schedule; a persistent gap between the two usually means dropped events, double counting, or a code path that bypasses your meter.

Streaming responses need special handling because the output token count is not known until the stream closes, and a client disconnect mid-stream still costs you money upstream. Meter on stream completion or abort, not on request start, and read [real-time streaming usage metering](https://dodopayments.com/blogs/real-time-streaming-usage-metering) before you design the event pipeline. The end-to-end implementation is walked through in Dodo's [usage-based billing guide](https://docs.dodopayments.com/developer-resources/usage-based-billing-guide).

### Hard caps and soft caps are two different products

Treating spend limits as one feature is the most common design mistake. They serve opposite purposes.

A soft cap is a communication tool. It fires notifications as consumption crosses a set of thresholds, shows the projected end-of-period spend in the dashboard, and gives a finance team time to decide. It never blocks a request.

A hard cap is a safety mechanism. It rejects requests once a budget is exhausted, returns an explicit and machine-readable error rather than a generic failure, and needs a documented path to raise the limit without a support ticket. Set it per project or per key rather than only per account, or one experiment can consume a production budget.

Both need to be visible in the customer's own dashboard before they are hit, not explained afterwards in an apology email. The interface patterns are worked through in [billing UX for usage caps and alerts](https://dodopayments.com/blogs/billing-ux-usage-caps-alerts), and [webhooks](https://docs.dodopayments.com/developer-resources/webhooks) are how you drive both without polling.

### Per-key attribution

Attribution is what turns a meter into a management tool. Every API key should carry an owner, a project, and an environment, and every usage event should record the key ID that produced it.

That single field gives you most of what enterprise buyers ask for: chargeback by internal team, separate budgets for staging and production, immediate blast-radius containment when a key leaks, and the ability to point at the exact agent loop that tripled last week's bill. Without it, a customer sees one large number and has no way to act on it, which is how usage-based pricing acquires a reputation for being unpredictable.

### Tiered rate limits as a growth mechanism

Rate limits are usually built as an abuse control and then left there. Tie them to billing instead and they become a promotion ladder: new accounts start with conservative throughput, limits rise automatically as verified spend or account age accumulates, and the highest tiers are negotiated.

This does three things at once. It caps your exposure to fraud and to a single customer saturating shared capacity, it gives a growing customer a visible reason to consolidate spend with you rather than spreading it across providers, and it removes an entire category of sales conversation because the upgrade happens on its own. Design the limits per key so a team can protect production from its own experiments, and document the tier thresholds publicly. [Usage limits and customer quotas](https://dodopayments.com/blogs/openai-usage-limits-customer-quotas) goes through how to expose these without creating support load.

### The margin math of reselling model access

If your product is a layer over someone else's model, your gross margin is a subtraction problem, and most teams get it wrong by leaving terms out.

Your true cost per billable user action includes:

- input tokens, including the entire conversation history resent on every turn
- output tokens, which are the expensive half and scale with how verbose your system prompt allows the model to be
- retries, failed generations, and agent loops that run several model calls per single user action
- tool calls, retrieval, storage, and any audio or image modality
- the payment processing fee on the revenue side

That last line is not a rounding error at low ticket sizes. Dodo Payments charges 4% + 40c per successful domestic US transaction, +0.5% for subscription and usage-based billing, and +1.5% for international cards and methods, with no monthly platform fee. On a small credit top-up, the fixed component matters more than the percentage, which is a direct argument for encouraging larger, less frequent top-ups rather than micro-charges.

Three habits keep the math honest. Measure cost per active user per month rather than cost per request, because averages across a request mix hide the heavy tail. Cap output length deliberately, since output is where cost concentrates. And route by task: send classification, routing, and extraction to the cheapest capable model, and reserve the flagship for work where quality is visibly worth the multiple.

Only after you know your loaded cost per user should you pick a price. The frameworks for that step are in [how to price an AI wrapper](https://dodopayments.com/blogs/price-ai-wrapper), and the comparison in [usage based billing vs flat fees for AI SaaS](https://dodopayments.com/blogs/usage-based-billing-vs-flat-fees-ai-saas) covers when a meter is worth the extra engineering at all.

### Spend controls for enterprise trust

Enterprise teams do not just buy access. They buy predictability. Project budgets, workspace rules, invoicing, and reporting are part of the product, and they are usually what closes the deal after the model comparison is already over.

See also [Dynamic pricing usage based SaaS](https://dodopayments.com/blogs/dynamic-pricing-usage-based-saas) for how these controls interact with a moving price.

## How to build an OpenAI-style billing stack with Dodo Payments

If you want to recreate this architecture, Dodo Payments gives you the major primitives out of the box:

- [credit-based billing](https://docs.dodopayments.com/features/credit-based-billing) for prepaid balances and subscription overage
- [usage-based billing](https://docs.dodopayments.com/features/usage-based-billing/introduction) for token or event metering
- [subscription billing](https://docs.dodopayments.com/features/subscription) for consumer-style monthly plans or seat-based team plans
- [webhooks](https://docs.dodopayments.com/developer-resources/webhooks) for low-balance and lifecycle automation

Pricing is +0.5% for subscription and usage-based billing on top of the base rate of 4% + 40c per successful domestic US transaction, with no monthly platform fee. International cards add 1.5%. Usage metering, invoicing, analytics, license keys, and tax management across 190+ countries are included rather than sold as separate modules, which matters when your billing surface has as many moving parts as the one described above. Current rates are on the [Dodo Payments pricing page](https://dodopayments.com/pricing), the [API reference](https://docs.dodopayments.com/api-reference/introduction) covers the endpoints behind each primitive, and the [integration guide](https://docs.dodopayments.com/developer-resources/integration-guide) walks through a first implementation end to end.

Because Dodo is a Merchant of Record, it becomes the seller of record on each transaction and assumes the tax liability that comes with it, which removes a registration and filing surface that grows with every country your API sells into. The model itself is explained in [what is a merchant of record](https://dodopayments.com/blogs/what-is-a-merchant-of-record), and the SaaS-specific version is in [merchant of record for SaaS](https://dodopayments.com/blogs/merchant-of-record-for-saas). Checkout reaches 220+ countries and territories with 40+ payment methods and 80+ currencies, which matters for a developer product where the buyer is rarely in the same country as the seller.

That combination is why Dodo works well for founders building hybrid AI billing instead of choosing only flat subscriptions or only usage pricing. The specific thing OpenAI does that most billing stacks cannot is run a subscription and a meter against the same account, with credits bridging the two. That requires entitlements, metering, and billing to share state.

For implementation paths, also read [Implement usage based billing](https://dodopayments.com/blogs/implement-usage-based-billing), [Monetize AI](https://dodopayments.com/blogs/monetize-ai), and [Subscriptions usage based billing SaaS](https://dodopayments.com/blogs/subscriptions-usage-based-billing-saas).

Worth being honest about the build-versus-buy decision here. Metering platforms and payment platforms solve adjacent but different halves of this problem: a metering engine aggregates events into invoice lines, while a payment platform also collects the money and, in a Merchant of Record model, owns the tax position on the sale. If you are evaluating the metering half on its own, the comparisons in [Orb billing alternatives](https://dodopayments.com/blogs/orb-billing-alternatives) and [Lago alternatives](https://dodopayments.com/blogs/lago-alternatives) set out where each product draws that line.

## Where OpenAI billing still creates friction

No billing system this complex is frictionless.

OpenAI still has to balance:

- customer confusion between ChatGPT plans and API access
- unpredictable API spend for developers
- multi-dimensional metering across text, voice, images, and tools
- enterprise governance without slowing product adoption

Those are normal tradeoffs in AI monetization. The key is to make them legible enough that buyers still trust the system.

More useful context: [Metered billing accurate billing](https://dodopayments.com/blogs/metered-billing-accurate-billing), [Tiered pricing model guide](https://dodopayments.com/blogs/tiered-pricing-model-guide), and [AI pricing models](https://dodopayments.com/blogs/ai-pricing-models).

### The compliance surface a billing model this size drags along

The pricing mechanics get the attention, but selling an API globally attaches a set of obligations that scale with the customer base rather than with engineering effort.

- **Business customers expect correct tax treatment.** Selling API access to an EU business means validating the VAT number and applying [reverse charge VAT](https://dodopayments.com/blogs/reverse-charge-vat) on every invoice, and selling to US businesses means handling [sales tax exemption certificates](https://dodopayments.com/blogs/sales-tax-exemption-certificate) rather than assuming a claim is valid.
- **Non-US sellers face withholding documentation.** Any developer outside the US billing US customers will eventually be asked for a [W-8BEN form](https://dodopayments.com/blogs/w-8ben-form-guide), and the default outcome of ignoring it is a flat deduction on payouts.
- **Onboarding is a gate, not a formality.** Platforms settling money to a business run [KYB verification](https://dodopayments.com/blogs/kyb-verification) on the entity and its beneficial owners before the first payout clears.

None of this is unique to AI products, but usage-based pricing amplifies it: a per-token model produces many small invoices across many jurisdictions, so an error in tax determination repeats at volume rather than once.

### The mobile channel splits the billing story in two

There is one more seam worth noting, because most AI products inherit it the moment they ship a mobile app. A ChatGPT subscription started inside the iOS or Android app is billed by the app store rather than by OpenAI directly, which means the store owns the payment relationship, the receipt, and the cancellation flow, and takes its platform commission on the way through. The same plan bought on the web runs through OpenAI's own checkout.

That split is why subscription state and payment state have to be modelled separately, a point covered in the architecture section above. It is also why teams weighing a mobile subscription stack end up comparing the infrastructure layer against a web checkout that keeps the billing relationship in-house, which is the trade-off in our [RevenueCat alternatives](https://dodopayments.com/blogs/revenuecat-alternatives) comparison and in [selling software outside the app store](https://dodopayments.com/blogs/sell-software-without-app-store).

## FAQ

### What is OpenAI billing?

OpenAI billing is a hybrid system that combines ChatGPT subscriptions, API token pricing, prepaid credits, and enterprise invoicing controls. It is not one single price sheet. It is several billing layers built for different customer types.

### How does OpenAI API billing differ from ChatGPT billing?

ChatGPT uses fixed monthly or per-seat plans, while open ai billing on the API side is metered usage pricing with model-specific token costs and account-level spend controls. The two systems share an account and nothing else: paying for ChatGPT grants no API credits, and an API balance does not raise a ChatGPT plan limit.

### How do OpenAI API credits work?

OpenAI API credits are a prepaid, dollar-denominated balance that each request draws down per token, with input and output tokens deducted at different rates for each model. Purchased credits expire one year after purchase, are non-refundable, and API calls fail once the balance reaches $0 unless auto-recharge tops the account up when it falls below a threshold you set. Usage tiers then raise rate limits as your total spend grows.

### How can I reduce OpenAI API costs?

The three largest levers are service tier, caching, and model choice: asynchronous batch processing is published at a discount against standard rates, cached input is billed at a fraction of fresh input, and routing simpler tasks to a smaller model in the same family cuts the rate sharply. Keeping requests below the published long-context breakpoint avoids the higher long-context rate, and capping output length attacks the most expensive component of a request.

### Can a startup copy the OpenAI API billing model?

Yes. The practical version is a USD fiat credit sold through top-up packs, token meters that deduct from that credit at your own per-token rate, a balance check before each request, and subscriptions for end users on top. Dodo Payments provides credit-based billing, usage meters, an LLM ingestion blueprint, and subscriptions as Merchant of Record, so you do not have to build the ledger, metering, and tax layer from scratch.

## Final thoughts

The reason **openai billing** is such a useful case study is that it shows AI monetization as system design, not just pricing-page design.

Subscriptions, prepaid credits, usage meters, and enterprise spend controls all exist because OpenAI sells to different buyers with different expectations. If you are building an AI product, that is the lesson to copy.

For the next step, compare [Dodo Payments pricing](https://dodopayments.com/pricing) and [pay-as-you-go AI SaaS pricing](https://dodopayments.com/blogs/pay-as-you-go-ai-saas) with Dodo's docs on [credit-based billing](https://docs.dodopayments.com/features/credit-based-billing), [usage meters](https://docs.dodopayments.com/features/usage-based-billing/introduction), and [subscriptions](https://docs.dodopayments.com/features/subscription).

If you are earlier than that and still deciding what to charge for, [usage-based billing for SaaS](https://dodopayments.com/blogs/usage-based-billing-saas) covers the model choice, and [how to monetize an AI agent](https://dodopayments.com/blogs/monetize-ai-agent) covers the case where the thing consuming your meter is software rather than a person.
---
- [More AI articles](https://dodopayments.com/blogs/category/ai)
- [All articles](https://dodopayments.com/blogs)