Per-Transaction Pricing: Examples & Companies

What is it

Per-Transaction Pricing is a billing unit where customers are charged per financial or billing transaction processed — the meter of billing and accounting platforms. The transaction is the moment money (or a claim on money) moves: an invoice issued, a usage record rated into a charge, a ledger entry booked. Pricing on it ties the vendor’s fee to the financial activity the product exists to handle, which is the closest available proxy for value delivered.

The billing-infrastructure cluster owns the unit. Metronome, Orb, Lago, m3ter, and Togai sell the metering, rating, and invoicing layer beneath other companies’ usage-based pricing, anchoring their own bills to billed events, invoices raised, and — increasingly — invoice value. The billing suites — Chargebee, Maxio, and Stripe Billing — carry the unit alongside recurring plan charges, while newer platforms Flexprice and Zenskar sell it to developer-first buyers who want to read the meter before they sign.

Three companies stretch the word past money entirely, and they are the sharpest lesson on the page. Puzzle, an AI-native accounting tool, gates a free tier on transaction volume rather than charging per transaction. PromptLayer folds three LLMOps workloads into a compute meter it literally calls a “transaction (txn).” Schematic counts feature-flag activations and entitlement crossings — product activity, not invoices. Same word; money, compute, or usage depending on the vendor.

How it works

Three distinct mechanics share the unit:

Worked example — count vs value. A marketplace issues 10,000 invoices a month averaging $40. On a count-based meter, it’s a 10,000-transaction customer; on a value-based meter, it’s a $400,000/month billings customer — and a SaaS issuing 200 invoices at $2,000 each ($400,000 too) prices identically on value and 50x cheaper on count. Which meter the vendor runs determines which of these two businesses subsidizes the other, the core trade the usage-metric guide frames as cost-proxy versus value-proxy.

Worked example — the value meter. Stripe Billing charges 0.7% of billing volume for recurring plus usage-based billing (with 100 million metered events per month included). A SaaS processing $2M/month in subscription billings therefore pays roughly $14,000 per month for the billing layer alone — calculable before a sales call. The pure metering cluster (Metronome, m3ter, Lago, Togai) publishes no rates at all; the equivalent quote is unknown without a discovery call, a transaction-value breakdown, and a minimum-commitment discussion.

Worked example — the count meter. PromptLayer runs the cleanest published count-based transaction meter in the cohort. A team on its Team plan ($500/mo) that runs ~250,000 requests and 40,000 eval-cell executions against a base of roughly 100k requests spills into overage: about 150,000 requests over base at $0.002/txn ($300) plus 32,500 eval runs over base ($65), for an all-in bill near $865/month. Because the rate drops from $0.003/txn on Pro to $0.002/txn on Team, the volume discount is baked into the tier rather than negotiated — a count meter behaving like a prepaid credit ladder.

Companies using this

Thirteen in-corpus companies meter transactions, in three camps: standalone metering platforms (Lago, m3ter, Metronome, Orb, Togai) that rate events and invoices as the core product; billing suites (Chargebee, Maxio, Stripe Billing) that embed metering in broader subscription management; and modern developer-first platforms (Flexprice, Zenskar). PromptLayer, Puzzle, and Schematic sit outside those camps, applying the same billing mechanics to units that aren’t invoices at all.

Patterns observed

The cluster keeps drifting from counts toward value. Orb is the cleanest arc: it once advertised billing “without charging a percentage of billings,” then made billings (total invoice value issued) a primary metric alongside events, added a platform fee on its Advanced and Enterprise tiers, and withdrew its briefly-published $1,750/month Core price entirely. Togai scales its platform fee with cumulative invoice value; m3ter bundles allowances for exactly the two things it does — data ingested and bills calculated. Counts are a cost proxy; the vendors that know billing best keep concluding that value is the defensible meter.

Transparency tracks the distribution motion, not the mechanic. The published rates in this cohort all belong to vendors who sell without a sales call: the billing suites (Chargebee 0.75% overage, Maxio’s billing-scaled bands, Stripe Billing 0.7%) serving an SMB-and-mid-market base that expects posted prices, and the open-core newcomers — Flexprice (free AGPLv3 self-host, then event-scaled cloud) and Zenskar, which markets its quotes as explicitly not a percentage of your revenue. Meanwhile Metronome, m3ter, Lago, and Togai publish no per-transaction rate at all: value mix varies so much by customer that a public card would be wrong for most of them, and an enterprise-sales motion lets them stay opaque. Two of the opaque cluster — Metronome and Togai — have already been acquired, a signal about the strategic value of owning the metering layer even when the rate stays private.

Counterexamples & variants

The two cleanest counterexamples are false friends — vendors that borrow the word “transaction” for something that isn’t money. PromptLayer folds three unrelated LLMOps workloads (API requests, agent-node runs, eval-cell runs) into one normalized “txn”: nothing has been invoiced, no money has moved, no ledger entry is booked, yet the mechanics apply perfectly — count, aggregate, charge on total. Schematic does the same with product activity: a “transaction” is a feature-flag activation or entitlement crossing, its tiers gated on monetized subscriptions and monthly events (Free at 10 subscriptions / 500K events, Growth $200/mo at 10M events). The pair gives buyers the sharpest lesson on the page — recognizing when “transaction” denominates money versus compute versus feature usage is a skill the unit’s own ambiguity forces on you.

The deeper variant is definitional drift within the billing cluster itself: an Orb billings percentage, a Togai invoice count, a Chargebee overage, and an m3ter bill-calculation allowance are all “transaction pricing” yet produce incomparable quotes for the same workload. The drift has a direction — counts toward value — that the Orb arc makes visible, which is the corpus’s clearest evidence that count-based transaction pricing is a transitional state rather than a stable equilibrium. Whether the newcomers’ transparency survives the enterprise sales motion at scale is the open question: Orb itself published rates early and removed them as it moved upmarket.

What this means for buyers vs vendors

For buyers

First establish which of the three mechanics you’re being quoted — count, value, or gate — because they price the same business by orders of magnitude apart. If there’s a percentage-of-billings component, model it against your growth plan and negotiate caps or declining tiers: that line scales with your revenue, not the vendor’s costs. For the quote-only cluster (Metronome, m3ter, Lago), arrive with both your transaction count and value distribution — the quote is built on both, and the invoicing and billing-cycles guide covers the mechanics worth probing.

Match your scorecard to the camp. A billing suite is evaluated on subscription-lifecycle depth; a metering platform on rating-engine performance and invoice accuracy at volume. And when a vendor’s “transaction” isn’t an invoice — a normalized compute txn, a feature activation, a volume gate — do not benchmark its per-txn rate against a billing platform’s per-invoice rate; that comparison flatters whichever vendor you spoke to last. Two vendors here (Metronome, Togai) have already been acquired, so weigh roadmap independence and contract transferability in diligence — and note the revenue-recognition risk when a billed “transaction” doesn’t map to a line in your ledger.

For vendors

Decide early whether you’re pricing the count or the value, and say so publicly — Orb’s reversal worked but cost it its published $1,750/month price. Value-scaled fees align you with customer success but antagonize high-volume/low-margin segments; offer them a capped or count-based track rather than losing the segment, since Zenskar’s “not a percentage of your revenue” pitch proves buyers will pay to avoid the value line. If your “transaction” is really a compute unit (PromptLayer) or a feature activation (Schematic), be candid that the unit is doing metaphor work — the mismatch surfaces at revenue-recognition time when finance can’t reconcile it against the ledger.

On transparency, the segment decides the play. Enterprise buyers accept opacity when the product is specialized and switching costs are high; SMB and mid-market make buy decisions from a rate card. Stripe Billing can post 0.7% only because a payments relationship already absorbs the cost — for a standalone vendor the analog is a free open-source tier or a published starter price, the play Flexprice and Lago are running. It’s unproven at enterprise scale, but the direction matches how infrastructure categories mature: opacity works until a credible transparent alternative exists, then only at the high end.

Explore this theme in the knowledge graph →