Mastering AI Pricing — Mayank Pant, Stripe

How do you establish a sustainable price when customers, compute consumption, and international demand are all scaling at once? Mayank Pant, introducing himself as a billing solution architect at Stripe, draws on two years of Stripe research and customer experience to examine that problem. Pant reports that the top 100 AI companies reached $20 million ARR in 20 months, versus 65 months for the top 100 SaaS companies—roughly three times faster. Faster growth compresses the time available to prepare for global customers and revise pricing.

Pant contrasts traditional SaaS gross margins of 80–85% with lower AI margins that change with usage. A fixed subscription does not necessarily cover the cost of a highly active customer: in his example, 5–10% of users can consume 80% of compute. External infrastructure prices add another source of uncertainty. Passing those costs through as usage charges addresses part of the margin problem, but creates a different problem for the buyer.

A Gamma customer wants useful slides and presentation decks. The number of API calls behind a deck says little about its quality or relevance. The unit that explains your cost may not explain the customer’s value. Meanwhile, a feature that commands a premium today may become standard within six months, leaving yesterday’s packaging attached to a different product.

Pant reports three concerns from Stripe’s research into AI-powered businesses:

Together, these describe a pricing system pulled in three directions: changing costs, uncertain customer value, and rapid feature releases.

Pricing must evolve with the product. Weekly or monthly releases can change which capabilities deserve a premium, so the initial price should be a hypothesis that can be revised. That requires billing infrastructure designed to accommodate changes without a lengthy engineering project.

Pant’s pricing-frequency chart examines three or more pricing changes over the preceding two years and defines hypergrowth as at least 100% year-on-year growth. He cites 49% for a high-growth group and 22% for low-growth companies making that many changes. He interprets less frequent repricing as a sign of a more static product; the comparison itself does not establish that repricing causes growth.

The reported movement is toward hybrid pricing. Pant describes adoption rising from 6% in 2024 to 41%, approximately a sevenfold increase, with outcome-based pricing at 5%. He separately cites 56% adoption among AI company leaders, a figure also reported in Stripe’s pricing framework; that survey figure is not established as the same population as the 41% figure. Seat-based and subscription approaches decline in the comparison he presents.

Pant names Intercom, Lovable, ElevenLabs, OpenAI, and Anthropic as Stripe billing customers using hybrid approaches. The same pressure reaches established workflow software: adding LLM features introduces usage-sensitive costs into products whose subscriptions were designed for different economics. The practical question becomes how to choose a price, a billable unit, and a way to revise both.

Begin with what the customer gets, rather than what the software does internally. For the Gamma customer, the result is a presentation whose quality and relevance justify the purchase; the API calls are implementation details. Pant reports that 53% of hypergrowth companies offer clear, understandable value-based pricing, compared with 26% of low-growth peers.

Four categories help identify that value:

• Automation: Save time, which the customer translates into lower costs.
• Augmentation: Keep the same headcount while improving output. A campaign team might produce better images or deliver better campaigns faster.
• Enhanced service: Provide access to proprietary software or data the customer otherwise could not use. Pant points to Stripe’s payment volume as an advantage in recognizing fraud.
• Improved results: Charge around a business result. Pant’s Intercom example is tickets resolved without human involvement, directly connecting the charge to the customer’s bottom line.

Identifying the category clarifies what the customer will pay for and what evidence can justify the price.

A charge metric turns value into a billable unit. Its suitability depends on the product and the buyer:

Consumption can be natural for infrastructure buyers who understand the resource being purchased. Workflow units describe completed work. Outcome units move further toward the business result: a hiring tool might distinguish candidates proposed from candidates actually hired.

The tradeoff is between implementation and attribution. Consumption is easier to meter, but an allowance of 1,000 API calls does not tell a presentation buyer how many decks they can create. An outcome promise is easier to connect to a purchasing decision, but proving that the product caused a hire or another business result requires data. Moving closer to customer value makes the measurement problem more demanding.

Credits offer a common currency across features. A plan can include 100 credits per month while internal rules determine how different operations consume that allowance. The abstraction is useful when customers can translate the balance into work or results they understand; the credit count alone does not supply that explanation.

The charge metric answers what is counted. The pricing model answers how that count becomes a bill.

A customer who cannot anticipate the invoice may avoid exploring the product, even when more usage would be valuable. A provider charging a flat fee faces the opposite exposure: enthusiastic use may create costs the subscription cannot cover.

A hybrid model combines a base fee with a scaling fee. The base establishes the ongoing relationship; the variable component charges for additional value consumed. Pant presents this as a way to accommodate both lighter users and customers who want to go deeper without making every customer’s economics depend on the heaviest users.

Flexible pricing needs spending controls. An incorrect or unexpectedly high bill in the sixth month can undo several months of trust. Fair pricing must also be predictable enough for customers to remain in control.

Pant’s example is a $20 plan with 100 credits. Once those credits are exhausted, the customer can pay for more or stop until the next month. A cap makes that choice explicit instead of silently converting activity into an open-ended bill.

The cap can be expressed as a small admission decision. This TypeScript example uses the same 100-credit allowance and an illustrative request costing one credit. It decides whether work may proceed; it does not debit the account or execute the work.

type UsageDecision = "allow" | "top-up-or-wait";

function checkUsageCap(
  usedCredits: number,
  requestedCredits: number,
  creditLimit: number,
): UsageDecision {
  const values = [usedCredits, requestedCredits, creditLimit];
  if (values.some(value => !Number.isFinite(value) || value < 0)) {
    throw new RangeError("Credit values must be finite and nonnegative");
  }

  return usedCredits + requestedCredits <= creditLimit
    ? "allow"
    : "top-up-or-wait";
}

const decision = checkUsageCap(100, 1, 100);
// decision: "top-up-or-wait"

The important boundary is before additional paid usage is admitted: an exhausted allowance requires a customer decision.

Make that boundary visible before the customer reaches it:

1. Notify as usage accumulates. Pant suggests alerts at 50%, 70%, and 90% of the allowance.
2. Offer explicit next actions. Customers can top up manually, enable automatic top-ups, or pause until monthly credits replenish.
3. Rate-limit requests. A faulty loop should not burn through the allowance unchecked.

The cap controls total consumption; notifications help the customer plan; rate limiting constrains how quickly erroneous code can consume the budget.

Pant reports that 84% agree fast pricing adaptation is a key competitive advantage. Put a plausible price into the market instead of spending a year searching for a perfect one, then test the hypothesis against customer behavior.

Interview customers who churn to distinguish a product-market-fit problem from a price problem. Interview customers who upgrade as well: understanding why they buy more helps identify where value is strongest. Use pricing A/B tests to explore alternatives, and prioritize learning quickly enough to keep pace with releases.

Credits provide another place to adjust the relationship between features and value. Pant illustrates 100 credits mapping to five API calls of one category or ten image generations of another. Those are example conversions, not a fixed exchange rate: as features evolve, the underlying mapping can evolve too.

Pricing iteration depends on the system that implements it. If each revision takes three or four months of engineering work, the organization cannot test prices at the pace its product changes. Billing needs to accommodate new units, packages, and rules without turning each experiment into a rebuild.

Pant positions Stripe as more than a payments provider, pointing to its investment in AI billing and customers including Anthropic, OpenAI, Lovable, ElevenLabs, and Intercom. His adoption figure needs a narrower denominator: Stripe’s published 78% figure refers to the Forbes AI 50, not all AI companies.

Stripe Billing is presented as supporting subscription, usage, and hybrid pricing. Pant describes AI companies moving from retail or product-led growth into enterprise sales within 10–15 months. Enterprise contracts add minimum commitments, pre-commitments, and overage prices—the complexity he associates with Metronome. Stripe had completed that acquisition before the conference, although the acquisition announcement described further integration prospectively. Payments, tax, invoicing, and revenue recognition complete the broader platform picture.

The first audience question exposes the tension in frequent iteration: changing prices can frustrate customers who need predictable costs. Pant returns to credits. Imagine a unique premium feature in January that consumes five credits. Six months later, competitors offer it as standard and the product has introduced new premium features. The customer can retain a visible 100-credit allowance while the feature-to-credit mapping changes underneath. Pant presents this as a way to keep the arrangement fair and understandable while adapting the product’s economics.

A separate option is grandfathering: introduce a new pricing version for new customers while existing customers retain their previous price. That preserves an established customer’s terms rather than requiring every pricing change to apply to the entire customer base at once.

Asked what annual contract value or payment volume unlocks enterprise management and better Stripe rates, Pant identifies payment volume, billing volume, and the combination of products used. A company might use payments and billing without using tax; the commercial discussion considers the selected services together. He does not supply a discount threshold, referring that question to sales while noting that public sticker prices are available.

Another audience member points out that large AI providers often keep recognizable plans while releasing features first into expensive tiers and later into cheaper ones. Pant uses ElevenLabs to illustrate tiers he calls good, better, best, and enterprise. Features can be added or moved between tiers, with credits abstracting how those capabilities consume the allowance.

The follow-up sharpens the distinction: a stable plan is not a promise of a permanently fixed price. Pant corrects his wording to say the customer-facing plan remains constant; its price may still change, and the feature allocation can continue evolving beneath the credit system. Iteration includes packaging and entitlement changes, not only changing the number on the pricing page.

The final question asks whether every chargeable prompt or transaction can be tracked for a user. Pant’s answer describes an application-to-billing flow: the application sends usage from its LLM calls and identifies the applicable pricing. He names tiered, dynamic, and dimension-based pricing as supported approaches.

The billing system then rates the submitted usage, prices it, and produces detailed reporting explaining the invoice amount. That makes usage submission part of the product’s responsibility: an understandable invoice depends on the application supplying the activity that should be charged and the rules that apply to it. The customer should be able to follow the bill back to the usage that produced it.