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 all sell the metering, rating, and invoicing layer beneath other companies’ usage-based pricing, and all of them anchor their own bills to some combination of billed events, invoices raised, and — increasingly — invoice value. Puzzle brings the unit to AI accounting from the other side: the transactions it categorizes are the workload, and its free tier ends precisely when the books cross $20,000 in transaction volume.

The seventh member, PromptLayer, is the deliberate odd one out: its “txn” is a normalized unit folding API requests, agent runs, and eval cells into one meter at $0.003 each — a transaction in name only, included here because the corpus qualifies companies by their declared billing unit, and a useful warning that the same word can denominate money or compute 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 normalized txn. A team on PromptLayer Pro ($49) running 60,000 requests, 5,000 agent-node runs, and 10,000 eval cells a month is billed for 75,000 txns: the included base plus overage at $0.003 ≈ $49 + ~$217. Upgrading to Team ($500) drops the marginal rate to $0.002 and raises the included pool — the volume discount lives in the tier, not in negotiation.

Companies using this

7 in-corpus companies meter transactions: the billing-infrastructure cluster (Metronome, Orb, Lago, m3ter, Togai), the AI accounting platform Puzzle, and PromptLayer’s normalized txn unit.

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 a primary metric alongside events and withdrew its 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 bill calculations performed. Counts are a cost proxy; the vendors that know billing best keep concluding that value is the defensible meter.

The second pattern is opacity as house style: Metronome, m3ter, Lago, and Togai publish no per-transaction dollar rates at all, quoting instead — transaction-value mix varies so much by customer that a public rate card would be wrong for most of them. The exceptions prove it: the published rates in this cohort belong to PromptLayer (whose txn is compute, not money) and Puzzle (whose transaction volume gates a flat subscription rather than metering a fee).

Counterexamples & variants

Puzzle is the structural variant: transactions never appear as a rate on its bill. The $20,000-transaction-volume line decides when the free tier ends, and flat tiers (from $30/month with bundled AI credits) take over from there — transaction volume as a qualification gate, not a meter, which converts the unit’s forecasting problem into a one-time threshold question. PromptLayer is the semantic counterexample noted above — a “txn” with no money in it. And the deepest variant is definitional drift within the billing cluster: an Orb billings percentage, a Togai invoice count, and an m3ter bill-calculation allowance are all “transaction pricing” yet produce incomparable quotes for the same workload — this is one billing unit where the label tells you almost nothing until you’ve read the meter’s definition.

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 differently by orders of magnitude. If there’s a percentage-of-billings component (Orb, Togai), model it against your growth plan and negotiate caps or declining tiers: that line item scales with your revenue, not the vendor’s costs. For quote-only vendors (Metronome, m3ter, Lago), arrive with your transaction count and value distribution — the quote will be built on both, and the invoicing and billing-cycles guide covers the mechanics worth probing in the contract.

For vendors

If transactions are your meter, decide early whether you’re pricing the count or the value, and say so publicly — Orb’s reversal worked but cost it its published price. Value-scaled fees align you with customer success and antagonize high-volume/low-margin segments; offer a capped or count-based track for them rather than losing the segment. And if your “transaction” is actually a normalized compute unit, name it something else: the unit borrows financial credibility it hasn’t earned, and the mismatch surfaces at revenue-recognition time when finance teams try to reconcile a txn count against a ledger that doesn’t contain it.