← All articles

Two Exchange Rates That Drive Credit-Based Pricing for SaaS and AI

Two Exchange Rates That Drive Credit-Based Pricing for SaaS and AI

Decorative credit pricing title card

Credit-based pricing is a prepaid internal currency model: customers buy a pool of credits up front, then spend them on individual product actions. It fits products with variable-cost or heterogeneous features, most commonly SaaS and AI tools built on compute, API calls, or per-unit work. The appeal is simple. You get prepaid cash flow, and pricing tracks actual usage instead of a flat seat fee that ignores what customers actually do.

TL;DR:

  • Using a unit based on the cheapest atomic action ensures consistent pricing across different features and simplifies cost normalization.
  • Building a metering and ledger system before launch is crucial for accurate consumption measurement and avoiding billing surprises.
  • Repricing actions without grandfathering current customers can lead to support issues and customer churn, so policies should be set before changes occur.
  • Rollover policies boost customer trust but can complicate accounting, especially under revenue recognition standards like ASC 606.
  • Complexity in meter infrastructure and precise consumption tracking are key operational requirements for successful credit-based pricing.

Table of Contents

How Credit-Based Pricing Works: Units, Exchange Rates, and Customer Flows

Every credit system runs on two exchange rates. The first is dollar to credit: how many dollars buy one credit. The second is credit to product: how many credits a given action costs. Chargebee’s pricing guide treats these as separate levers on purpose. Keep the dollar to credit rate stable so procurement stays simple, and adjust the credit to product rate when you need to reprice specific features without touching the base contract.

Unit design is the first real decision, and it shapes everything downstream:

  • Dollar-denominated credits (1 credit = $1) feel transparent but expose your raw cost structure to customers.
  • Token or compute units work well for AI products where usage maps directly to infrastructure cost, though customers find them abstract.
  • Action-based units (1 scan, 1 report, 1 API call) are the easiest for non-technical buyers to understand, but they require you to normalize wildly different costs into one number.

Once the unit is set, the customer flow is predictable: purchase a credit pack, watch the balance drop as they consume, get warned as it runs low, then top up or auto-refill. Stripe’s guidance on credits models is blunt about this: flexibility for the vendor becomes confusion for the customer unless the UX makes balance and burn rate obvious at every step.

Core Design Choices: Unit, Consumption, Packaging, and Change Management

Pick your unit around the cheapest atomic action in your product, the lowest common denominator, then price everything else as a multiple of it. A support ticket lookup might cost 1 credit; a full AI-generated report might cost 40. Steven Forth’s design framework treats unit design, consumption mapping, and packaging as interdependent choices. Get the unit wrong and every layer above it inherits the problem.

A practical sequence for building this out:

  1. Map every billable action to a credit cost, including partial or failed runs.
  2. Decide whether failed operations refund credits automatically or require support intervention.
  3. Choose packaging: entry packs for new customers, bundled subscriptions for predictable revenue, or a hybrid of both.
  4. Set a repricing policy before you need one, with grandfathering rules for existing customers.

Pro Tip: Never change the credit cost of an action without grandfathering existing customers for at least one billing cycle. Silent repricing is the fastest way to generate support tickets and churn.

Setting Conversion Rates, Discounts, and Rollover Policies

Price your dollar-per-credit rate by starting with your marginal cost per unit action, then layering in the value the action delivers, not just the compute bill. A credit that triggers a $200 outcome for the customer can carry margin well above raw infrastructure cost.

A few commercial rules worth deciding early:

  • Volume discounts make sense for storage or seats, but they get risky on compute-heavy actions where your own costs rise linearly with usage.
  • Rollover policies (credits carry into the next period) build trust but extend how long unused credits sit on your books.
  • Expiring credits simplify accounting but frustrate low-usage customers who feel penalized for buying ahead.
  • Auto-refill and recurring bundles smooth revenue forecasting and cut the operational load of manual top-ups.

Adjusting the credit-to-product rate, rather than the dollar-to-credit rate, lets you raise effective prices on premium features without reopening every customer’s base contract, as Chargebee notes in its practitioner guidance.

What Operational Requirements Does Credit-Based Pricing Demand?

Credits look simple to the customer and complicated behind the curtain. Metering has to be accurate at the event level, and every action needs an idempotency key so a retried request doesn’t double-charge a customer’s balance.

The infrastructure checklist looks like this:

  • A ledger that records every credit purchase, consumption event, and adjustment with a timestamp and reason code.
  • Customer-facing balance visibility, usage velocity, and a depletion projection so nobody gets surprised by a zero balance mid-task.
  • Integration points across billing, payment processing, and webhooks so top-ups and auto-refills fire without manual intervention.
  • Spend caps and admin alerts to prevent runaway consumption on shared team accounts.
  • A clear policy for failed runs: refund the credit, void it, or flag it for manual review.

Practitioner guidance on AI pricing points to balance visibility and low-balance warnings as the difference between a usable product and a support queue full of billing disputes.

Pro Tip: Build your metering and ledger system before you finalize pricing tiers. If you can’t measure consumption accurately on day one, no packaging decision will save you later.

Financial and Accounting Implications: Deferred Revenue and ASC 606

Prepaid credits create a liability, not revenue, the moment a customer buys them. Revenue recognizes only as credits get consumed, which means your finance team needs precise consumption records tied to each ledger entry, not just aggregate sales totals.

Rollover policies extend how long that deferred revenue liability stays open. A credit that never expires can sit on the balance sheet indefinitely, which complicates forecasting and audit prep under ASC 606 revenue recognition guidance. Promotional credits, given free as incentives, get treated differently from paid credits since no cash changed hands. Get your accounting policy signed off by finance before launch, not after your first quarterly close, when a mismatch between ledger data and recognized revenue turns into a much bigger cleanup job.

Weighing the Pros and Cons of Credit-Based Pricing

The upside is real: prepaid cash lands before you deliver the service, pricing aligns with variable-cost features instead of penalizing light users, and one credit system can price wildly different actions without a dozen separate SKUs. Industry data shows usage-based pricing is growing but rarely replacing subscriptions outright — most vendors blend the two.

The downside is complexity. Customers have to learn a new mental model, forecasting gets harder when usage is lumpy, and a poorly chosen unit makes every future pricing decision harder to explain.

Run this quick checklist before committing:

  • Does your cost structure vary meaningfully by action, or is it flat enough that a subscription works fine?
  • Are your features heterogeneous enough that one flat price undercharges some users and overcharges others?
  • Is your buyer sophisticated enough to plan around a variable credit balance?
  • Is your metering infrastructure ready to track consumption at the event level?

If the answer to most of these is no, a hybrid model, subscription plus overage credits, often beats a pure credit system.

How to Implement Credit-Based Pricing: A Prioritized Checklist

Getting from concept to a working credit system follows a fairly consistent order across SaaS and AI teams that have done this well.

  1. Workshop your unit design with product, finance, and engineering in the room, and map every representative action to a credit cost before writing a line of billing code.
  2. Build a metering and ledger prototype, then run billing simulations against real historical usage to catch pricing surprises before customers do.
  3. Set rollover, expiry, and refund policies in writing, and get finance sign-off on the accounting treatment before launch.
  4. Design the UX for balance visibility, low-balance alerts, and one-click top-ups; this is where most credit systems succeed or fail with customers.
  5. Pilot with a small customer segment, watch consumption patterns closely, and adjust the credit-to-product rate before a full rollout.

Pro Tip: Run your billing simulation against your ten most usage-intensive existing customers first. If the math breaks on them, it will break in production too.

Per-Scan Credits in a Grid Scan SaaS: A Practical Example

Grid-based rank tracking tools show this model in a clean, concrete form. Each credit maps to one scan of a defined grid size, so a 25-point grid burns more credits than a 5-point grid. That direct link between grid size and credit cost means agencies can predict their monthly burn before running a single scan, plan client billing around it, and avoid the per-location fees that make traditional rank trackers hard to budget for. Refund handling for failed scans and clear per-scan visibility both matter here, since agencies are reselling this data to clients under white-label reports.

Comparison of grid sizes and credit usage

What Actually Matters When You Build Credit-Based Pricing

What Actually Matters When You Build Credit-Based Pricing — overview diagram

Most credit systems fail for boring reasons: the unit was too complicated, nobody instrumented usage before launch, or a repricing update landed without warning. Start with the simplest unit that maps to your cheapest atomic action, build telemetry before you build packaging, and tell customers exactly what changed when you adjust rates.

The mistake I see most often is treating the credit-to-product rate as something you can tune quietly. It never stays quiet. Customers notice when a report suddenly costs 60 credits instead of 40, and if you haven’t grandfathered them, you’ll spend more time in support tickets than you saved in margin. Get balance visibility and one-click top-ups right before you obsess over the perfect price point. A confusing but fairly-priced system loses to a clear, slightly generous one every time.

— Local

See Per-Scan Credit Pricing in Action

Maprank runs on the same principle covered throughout this article: straightforward, per-scan credits instead of the per-location fees and bundled-tier guesswork that make traditional rank trackers hard to budget for. Every scan against a grid draws from a transparent credit balance, agencies get unlimited businesses on every plan, and white-label reports go out under their own brand without extra line items showing up later.

Maprank

For agencies managing dozens of client accounts, that predictability is the whole pitch. You know what a scan costs before you run it, you know what your credit burn looks like at scale, and you’re not negotiating a new fee every time you onboard another location. If you’re evaluating how per-scan credit pricing would play out for your own client roster, take a look at the Google Maps rank tracker product page and see how the grid scans, credit balance, and reporting fit together.

Sources