SaaS and iPaaS platforms were built on one quiet assumption: serving a customer costs roughly the same whether they use the product a little or a lot. AI breaks that assumption. And once it breaks, the billing architecture has to change with it.

In AI FinOps: The Economics of AI at Scale I looked at what one AI outcome really costs. This article is about what happens next: how you turn that cost into a price, and which systems you need to do it.

How the old model worked

A classic SaaS product charges per user or per plan. An iPaaS platform charges per connector, per environment or per volume tier. Either way, the price is fixed for the month.

That works because the cost behind it is mostly fixed too. Servers, support and development are shared by all customers. One extra login or one extra sync costs almost nothing.

The architecture is simple to match:

  • The application knows which plan a customer is on.
  • A subscription in Stripe (or a similar tool) charges the same amount every month.
  • Finance looks at revenue per customer. Cost per customer is an average nobody needs to calculate.

What AI changes

Add an AI step and every action gets a price tag. Enriching a product record, mapping a data field, summarising a ticket: each one calls a model, and the model provider bills you for it.

Three things follow:

  1. Cost per customer is no longer flat. A heavy user can cost ten times more than a light one.
  2. Your cost keeps moving. Model prices change, you switch models, retries go up or down.
  3. A flat price stops being safe. Your most active customers can become your least profitable ones.

So the price has to follow usage, at least partly. Most AI companies now land on a mix: a fixed monthly fee, an included amount of usage, and a price per unit above that.

  Old SaaS / iPaaS With AI
Cost per customer Roughly fixed Varies with every action
Price Per seat, plan or tier Base fee plus usage
What you measure Logins, seats, connectors Every billable action and what it cost
Billing system Subscription only Subscription plus metering and rating
Changing the price Rarely, by hand Often, through versioned rate cards

The new architecture: four layers

A subscription tool alone cannot do this. You need four layers, each with one clear job.

  ┌──────────────────────────┐
  │ 1. Model gateway         │  OpenRouter, LiteLLM
  │    routes calls, reports │  → cost per call
  │    cost per call         │
  └────────────┬─────────────┘
               ▼
  ┌──────────────────────────┐
  │ 2. Your application      │  tags customer + feature,
  │    decides what counts   │  decides "accepted",
  │    as a billable unit    │  sends ONE usage event
  └────────────┬─────────────┘
               ▼
  ┌──────────────────────────┐
  │ 3. Metering and rating   │  Metronome
  │    counts usage, applies │  → contracts, rate cards,
  │    the price             │    credits, invoice lines
  └────────────┬─────────────┘
               ▼
  ┌──────────────────────────┐
  │ 4. Payments and finance  │  Stripe
  │    invoice, tax, payment,│  → collections,
  │    revenue recognition   │    paid / failed back up
  └──────────────────────────┘

1. The model gateway sits between your application and the AI providers. Tools like OpenRouter and LiteLLM route each call to the right model and give you the cost of every call. This is your cost side.

2. Your application is the only layer that knows what the work was for. It attaches the customer, the plan and the feature, decides whether the result counts (an accepted record, a completed mapping), and sends exactly one usage event for it. This layer stays yours. No tool can decide what your customer is paying for.

3. The metering and rating engine turns usage into money. Metronome, now part of Stripe, describes itself as “infrastructure for modern monetization”: metering, pricing, billing and reporting in one platform. In Stripe’s own description, Metronome “collects, aggregates, and rates the usage according to the contract and rate card.” It handles the things a plain subscription cannot: billable metrics, reusable rate cards, prepaid credits that draw down, minimum-spend commitments and automatic top-ups when a balance runs low. This is your price side.

4. Payments and finance collect the money. Metronome computes and finalizes the invoice, creates the line items in Stripe, and Stripe takes over presentation, tax, payment collection, retries, dunning and revenue recognition. Stripe then reports back whether the invoice was paid or failed.

The key point: cost comes in at layer 1, price is applied at layer 3, and layer 2 connects them with one event. If that event carries the customer, the feature and the cost, finance can see margin per customer without building anything extra.

One action, followed through

Take a product-information platform with an AI feature that enriches product records.

  1. A customer uploads a catalogue. The application sends each record through the gateway, which reports a cost of €0.35 per record.
  2. The application checks the result. Accepted records produce one usage event: customer, plan, feature, “1 record”, cost €0.35.
  3. Metronome counts the record against the contract: 3,000 records included in a €1,500 plan, €0.60 for each record above that.
  4. At month end Metronome finalizes the invoice and Stripe collects it, adds tax and books the revenue.

Because cost and price travel in the same event, the margin is visible straight away: €0.60 charged, €0.35 spent, per extra record. When model costs rise, you see it in the next report, not the next quarter.

What this means for SaaS and iPaaS

For SaaS, you don’t have to throw out what works. Stripe describes a setup where Stripe Subscriptions keeps billing the fixed fee and Metronome runs alongside it for usage, both on the same Stripe customer. Your existing checkout and plans keep working. Usage gets added on top.

For iPaaS, the shift is bigger than it looks. Integration platforms already count tasks and runs, so the metering habit exists. But an AI step inside a flow, such as mapping fields, cleaning data or translating content, makes some runs far more expensive than others. A flat “per task” price no longer covers that. AI steps need their own billable metric, their own rate, and cost tracked per customer through the gateway.

In both cases, the price list moves out of the code and into versioned rate cards. That makes it possible to change a price, test a new plan or give a customer a custom deal without a software release.

Watch out for

  • Two counters. If engineering counts usage for cost and the billing tool counts it separately for invoices, they will drift apart. Send one event, used by both.
  • Gateway cost is an estimate. Reconcile it each month against the real provider invoices. Discounts, caching and retries create differences.
  • Invoice sync runs one way. Per Stripe’s documentation, Stripe does not send invoice data back to Metronome, and a voided invoice has to be voided in both systems.
  • Failed payments. Metronome records a failed payment but does not retry it. Retries and dunning are Stripe’s job, so set them up there.
  • Changing the model is not changing the price. Switching to a cheaper model is your decision. The customer’s price only changes through a new rate card version.

Where to start

  1. Put a gateway in front of your AI calls and tag every call with customer and feature.
  2. Define one billable unit per AI feature and send one usage event for it, including its cost.
  3. Keep your subscription for the base fee. Add metering and rating for usage alongside it.
  4. Check margin per customer every month, and change the price through a new rate card version when it drifts.

The first article asked whether you can explain what one AI outcome costs. This one asks whether your systems can turn that cost into a fair price, automatically, for every customer. Old SaaS and iPaaS stacks were not built for that. With a gateway, a metering engine and a payments platform each doing one job, they can be.

Rebuilding a SaaS or iPaaS platform around this is the kind of architecture work I take on as a fractional CTO.

Questions people ask about AI billing architecture

Why can’t a normal subscription handle AI pricing?

A subscription charges a fixed amount per period. AI features have a cost that changes with every action, so pricing usually needs a usage component on top of the fixed fee. That requires counting usage, applying a rate per unit and handling credits or commitments, which is what a metering and rating engine does.

What does Metronome do compared to Stripe?

According to Stripe’s documentation, Metronome handles usage-based billing, credit-based pricing, enterprise contracts and rating. Stripe handles payment collection, tax, revenue recognition and fraud screening. Metronome creates the invoice, Stripe collects it.

What is a model gateway in AI FinOps?

A model gateway, such as OpenRouter or LiteLLM, sits between an application and AI model providers. It routes each call to a chosen model and records usage and cost per call, which gives the business the cost side of every AI action.

Does this apply to iPaaS platforms?

Yes. Integration platforms already bill per task or run, but AI steps inside a flow make some runs much more expensive than others. Those AI steps need their own billable metric, rate and per-customer cost tracking.

Sources