.png)
Frameworks, core principles and top case studies for SaaS pricing, learnt and refined over 28+ years of SaaS-monetization experience.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Which Pricing Metric Fits Neobanks SaaS Best per Seat per Transaction or per Outcome
Neobank software creates an unusual pricing problem. The buyer may employ only a few dozen or a few hundred people, yet the platform beneath that team can authorise millions of card purchases, move billions through payment rails and verify a rapidly expanding customer base. A pricing model tied to employee count therefore risks missing the very thing that makes the software valuable.
The alternative is not simply to charge for “usage”. Neobank infrastructure generates many kinds of activity: authorisations, settlements, ledger entries, account checks, KYC calls and payment instructions. Some create direct third-party costs even when the end customer never sees a successful result. Synctera, for example, says its card-processing invoices can charge for successful and failed or declined transactions, while Marqeta reports that both customer fees and important network and issuing-bank costs can scale with transaction volume or transaction count. Those mechanics matter because the pricing unit has to work for the software vendor and the neobank at the same time.
Monetizely's position is clear: transaction should rank first as the primary pricing metric for neobank SaaS, outcome second for a narrow set of products, and seat a distant third. The strongest commercial design is transaction-led pricing with an annual committed minimum and volume tiers - not a seat subscription with usage bolted on, and not a broad outcome fee whose definition becomes harder to defend as the product expands.
Neobank economics make activity the natural unit of value
For this discussion, we use “neobank SaaS” to mean the B2B software and financial infrastructure behind a digital banking proposition: core banking, ledgers, payment orchestration, card issuing, account infrastructure, fraud controls and identity workflows. The question is what should make the software bill rise as the customer succeeds.
Monetizely's 5-Step Pricing Framework treats that question as one part of a connected commercial system. Customer Segmentation identifies whose needs and economics the offer must serve. Positioning & Packaging decides which capabilities customers buy together. Pricing Metric selects the unit that makes the bill rise with value. Rate Setting establishes the price level, volume curve and discount logic. Operationalization makes the design workable in contracts, metering, invoicing and renewals. The discipline, also developed in Monetizing Agentic AI, matters here because a clever rate cannot rescue a weak meter: a £100-per-seat product still scales with headcount even when the bank's underlying transaction traffic scales tenfold.
The pricing-metric step therefore carries unusual weight. A neobank can add customers and transaction volume without adding operations staff in the same proportion. By contrast, the infrastructure vendor often performs more work whenever another payment, authorisation or verification hits its systems.
That asymmetry produces our ranking.
| Rank | Metric | Monetizely verdict | What to do in practice |
|---|---|---|---|
| 1 | Per transaction | Best primary meter | Define an auditable financial event, set an annual volume commitment, then use declining unit rates as volume grows |
| 2 | Per outcome | Useful only for bounded modules | Apply where both parties can independently verify success and agree what caused it |
| 3 | Per seat | Poor core meter | Include operational users within the package rather than making employee count the main growth engine |
The ranking reflects one central idea: the primary meter should follow the workload and customer value that actually scale. In neobank infrastructure, that is normally financial activity rather than the number of people permitted to log in.
Marqeta provides a useful real-world illustration. Its 2025 Form 10-K says processing and other fees can be priced as a percentage of processing volume or as a fee per transaction; the same filing says card-network and issuing-bank costs can also be based on processing volume or a fixed amount per transaction. For the quarter ended 30 June 2026, Marqeta reported $120 billion of total processing volume, up 32% year on year, and said higher volumes were the primary driver of its 17% net-revenue growth.
That is unusually clean pricing logic. Customer activity rises, value rises, vendor workload rises and commercial revenue can rise with the same underlying event.
Transactions connect willingness to pay with the costs of serving the bank
A good pricing metric has to solve two problems at once. Customers should understand why their bill rises, while vendors should avoid a situation in which the cost of delivering another unit grows but revenue stays flat.
Per-seat pricing performs poorly on the second test for transaction-heavy infrastructure. Imagine two banks with 80 operations, risk and finance users. One processes one million events a month; the other processes 20 million. A pure seat model treats them as nearly identical even though their demands on payment processing, network interfaces, compliance calls and transaction monitoring may differ by an order of magnitude.
Transaction pricing does not require every component to use exactly the same event. “Transaction” should be understood as a family of tightly defined billable financial events. A card processor may meter an authorisation or processed card transaction. A payment platform may meter an ACH instruction. A data provider may meter a successful API request. What matters is that each event can be counted from systems both sides can reconcile.
Our scoring makes the trade-off visible. The scores below are Monetizely's judgement on a five-point scale, not vendor-reported measures.
| Criterion | Per seat | Per transaction | Per outcome |
|---|---|---|---|
| Alignment with customer growth | 2/5 | 5/5 | 5/5 |
| Alignment with variable delivery cost | 1/5 | 5/5 | 2/5 |
| Ease of audit and reconciliation | 5/5 | 5/5 | 2/5 |
| Budget predictability with an annual commitment | 5/5 | 4/5 | 2/5 |
| Low risk of disputes over the billable unit | 5/5 | 4/5 | 2/5 |
| Overall fit for neobank SaaS | 18/25 | 23/25 | 13/25 |
Transaction wins because it captures more of the value of growth without forcing the vendor to absorb all of the cost and risk behind that growth.
The strongest evidence comes from cases where unsuccessful activity still creates work. Synctera's invoice documentation, accessed 12 August 2026, says Mastercard card spend can be billed per processed transaction whether successful or failed or declined. Its definition of a processed card transaction can include authorisation, settlement, approval, decline, refund, balance inquiry, chargeback and reversal activity. Its fraud-monitoring SKU can bill every call, while KYB verification can include both successful and failed verifications.
Outcome pricing would struggle with those economics. Suppose a card authorisation is declined because the customer lacks funds. The infrastructure still had to receive, route, evaluate and answer the request. Charging only when the cardholder completes a successful purchase would leave the supplier paying for part of the workload created by the bank.
Marqeta shows the same principle from the public-company side. Its 2025 filing says card-network fees and issuing-bank fees can be fixed per transaction or tied to processing volume. A pricing structure that bills only for a downstream business “outcome” could therefore disconnect revenue from costs that have already been incurred upstream.
Leading financial infrastructure vendors already price growth through activity
The market does not use one identical definition of transaction, which is healthy. Core banking, issuing and money movement have different cost structures. Yet the primary-source evidence repeatedly points towards activity rather than seats.
The following examples were drawn from company filings and official pricing or billing pages. Current webpage observations are dated 12 August 2026 unless the vendor provides another date.
Sources: Marqeta 2025 Form 10-K; Mambu pricing documentation; Synctera invoice documentation; Increase fee schedule; Modern Treasury pricing page; Stripe Issuing pricing page.
The important pattern is not that every company charges pennies per transaction. Mambu uses transaction throughput to place the buyer into an annual subscription tier, while Modern Treasury combines usage with a minimum commitment. Both still make activity the commercial anchor.
Modern Treasury is especially instructive for enterprise sellers. Its pricing page says annual contracts use flexible usage-based pricing, all platform and usage fees count towards one minimum commitment, and per-unit costs decrease as volume rises.
That structure solves one of the weaknesses of raw pay-as-you-go pricing. A vendor gains some revenue certainty and a customer gains a pre-negotiated cost curve. Neither party needs to pretend that 60 employees processing 50 million transactions should pay the same as 60 employees processing five million.
Pure outcome pricing creates a causality problem that banking cannot ignore
Outcome pricing has an intuitive appeal. If software saves £1 million of fraud losses, perhaps the supplier should take a percentage. If it improves successful onboarding, perhaps the bank should pay per verified customer. The language feels closer to business value than “API call”.
The difficulty begins when finance asks a seemingly simple question: which outcome did the software cause?
Consider fraud. A prevented £5,000 fraudulent transfer could reflect the software's detection model, a bank rule, a network control or the customer's own behaviour. A false positive, meanwhile, may prevent both a loss and a legitimate transaction. Turning that counterfactual into an invoice creates arguments that a transaction counter avoids.
Onboarding produces another problem. Should a KYC vendor earn an outcome fee when an applicant passes identity checks but abandons before funding the account? Should the vendor earn nothing when a legitimate applicant fails because the source data are incomplete? Synctera's 2026 invoice documentation charges certain KYB and KYC activity across successful and failed verifications, which demonstrates that the supplier's work does not disappear merely because the final outcome is negative.
Outcome pricing also concentrates economic risk in the vendor. A neobank might change its underwriting threshold, geographic mix or acquisition channels during a contract. Each can change downstream conversion without changing the quality or cost of the software.
For that reason, we rank outcome second rather than rejecting it entirely. It can work when the unit meets a demanding test:
- Both parties can identify the same result from an agreed system of record.
- The supplier has enough control over the result for payment to be fair.
- A failed result does not impose material unpriced cost on the supplier.
- The buyer cannot easily change policy in a way that alters the outcome definition after signing.
A successful payment initiation can sometimes meet those conditions. “Fraud prevented” usually does not. “Lifetime value created” is weaker still.
Outcome should therefore be an exception metric for bounded modules, not the main pricing unit for a neobank platform.
Seat pricing has one great advantage: everybody understands it. A bank buys 100 licences, the vendor charges £X per user, and the annual bill is easy to forecast.
Its weakness is equally straightforward. Headcount can move in the opposite direction from the value created by automation and software.
Zoom provides a documented example of how exposed seat economics are to customer workforce changes. In its Form 10-K for the year ended 31 January 2025, Zoom said subscription revenue was primarily driven by paid licences and additional products. It also reported that slower hiring and higher seat-count downsells among enterprise customers had affected expansion, with trailing twelve-month enterprise net dollar expansion falling to 98% at January 2025 from 115% two years earlier.
A seat-priced neobank platform would inherit the same weakness in a market where automation is part of the product's value. If the platform enables the bank to process twice as many payments without doubling operations staff, the customer has gained more value while the vendor's primary bill barely moves.
That problem becomes more acute as software spreads across risk, finance, compliance and customer operations. Charging for every internal user gives the bank a reason to restrict access. Yet broader access can improve investigation, reconciliation and operational control.
Seats therefore belong in packaging, not in the core pricing metric. Enterprise plans can include role-based access, security administration and defined permission levels without charging another full licence every time someone in finance needs to inspect a transaction.
The broader SaaS market already demonstrates the need to soften raw seat economics. Slack's Pro pricing page, accessed 12 August 2026, prices on an active user basis rather than simply charging for every possible account, a design that ties the bill more closely to actual participation.
For neobank infrastructure, we would go further. Make operational seats generous or unlimited within the contracted platform package. Let financial activity drive expansion.
Committed transaction pricing fixes the weakness of pure consumption
Choosing transaction does not mean accepting an unpredictable monthly bill.
Pure consumption pricing can create legitimate planning problems. Snowflake's 2025 Form 10-K says its consumption model gives customers flexibility over when they use compute, storage and data transfer resources, which means the company has less visibility into revenue timing than a typical subscription business. Snowflake also says most revenue comes from capacity arrangements where customers commit to consumption, generally over one to four years.
Twilio makes the same tension explicit. In its 2025 Form 10-K, filed in 2026, it reported that 74% of 2025 revenue came from usage-based fees. The company said usage revenue can create variability between forecasts and actual results; larger usage customers commonly enter contracts that include minimum revenue commitments.
These are not arguments against transactions. They are arguments against uncommitted transactions.
For neobank SaaS, the stronger architecture keeps transaction as the primary meter while adding contractual predictability around it.
| Pricing layer | Recommended treatment | Why it belongs there |
|---|---|---|
| Platform access | Annual committed minimum | Pays for baseline infrastructure, support, security and contractual capacity |
| Primary variable unit | Billable financial transaction with volume bands | Tracks customer growth and much of the vendor's incremental workload |
| Direct rail or network costs | Separately identified pass-through | Prevents third-party cost changes from being confused with SaaS price increases |
| Seats | Included generously within the contracted service | Encourages adoption without disconnecting revenue from transaction growth |
| Outcome components | Narrow add-ons or performance credits only where causality is clear | Preserves value alignment without putting the whole contract into dispute |
| Volume expansion | Pre-agreed declining unit rates | Rewards scale while keeping marginal economics visible |
The table represents a transaction-led pricing architecture, not an attempt to avoid choosing a primary meter. The transaction remains the unit that expands the commercial relationship; the commitment simply makes that expansion financeable and forecastable.
Marqeta already discloses minimum processing fees when processing falls below thresholds, while Modern Treasury's current pricing describes a single minimum commitment against which platform and usage charges apply. Twilio likewise reports minimum commitments for many larger usage customers.
Operationalization then becomes critical. “Transaction” must not become a vague umbrella that buyers understand only after the first invoice. Synctera's billing documentation shows the level of detail required: separate definitions cover processed card transactions, network fees, fraud calls, KYC/KYB checks and other activity.
A neobank SaaS vendor should therefore give procurement and finance a billable-event dictionary before signature. Failed events, reversals, retries and third-party pass-throughs need explicit treatment. The customer should be able to reproduce the monthly usage count from its own records.
Monetizely's position for 2026 is consequently more specific than “use usage pricing”. Use an auditable transaction as the primary meter, protect both parties with an annual volume commitment, and let the unit price fall at agreed scale thresholds. Seats should govern access rights rather than revenue growth. Outcomes should command a premium only where success has a narrow, shared definition.
For operators deciding what to change, we would make five moves:
Standardise the company around a billable financial event. Product teams can define different events for issuing, payments and verification, but finance should govern one common rule: the charged unit must be observable and reconcilable by the customer.
Make scale create a better unit price rather than a new licence negotiation. Publish or contract the volume curve in advance so a neobank knows what happens when traffic doubles.
Treat third-party rail economics separately from software value. Card-network, bank and payment-rail fees should be visible enough that procurement can distinguish a vendor price increase from an externally imposed cost change.
Remove seat scarcity from day-to-day operations. Risk, finance, compliance and support teams should not have to share credentials or ration access because the vendor chose employee count as its growth lever.
Demand stronger proof before monetising an outcome. Where a vendor cannot show that both buyer and seller can independently verify success and attribute it to the product, keep the commercial meter on the underlying transaction.
Assumptions
“Neobank SaaS” here covers B2B software and financial infrastructure used to run digital banking products, rather than consumer banking fees. Transaction refers to a contractually defined, auditable financial or processing event; it need not mean only a successfully settled purchase. Metric scores and rankings are Monetizely judgements. Vendor pricing is stated in the currencies and regions shown on the cited primary sources and is dated as noted; enterprise negotiated rates can differ from public pricing.
Footnotes
https://www.amazon.com/Monetizing-Agentic-AI-Handbook-Transformation/dp/B0H7Z13VKJ/
Marqeta, 2025 Annual Report / Form 10-K:
https://investors.marqeta.com/static-files/6080c3b0-c03b-4c1f-87e1-18c37f2a94d3Marqeta, second-quarter 2026 SEC filing and financial results:
https://investors.marqeta.com/node/11061/htmlMambu, “Pricing and Consumption”, updated 13 April 2026:
https://docs.mambu.com/docs/insights-pricing-and-consumption/Synctera, “Invoice Details”, accessed 12 August 2026:
https://docs.synctera.com/docs/invoice-detailsIncrease, technology fee schedule, accessed 12 August 2026:
https://increase.com/feesModern Treasury, pricing, accessed 12 August 2026:
https://www.moderntreasury.com/pricingStripe Issuing pricing, European page accessed 12 August 2026:
https://stripe.com/issuingZoom Communications, Form 10-K for the fiscal year ended 31 January 2025:
https://www.sec.gov/Archives/edgar/data/1585521/000158552125000042/zm-20250131.htmSnowflake, Form 10-K for the fiscal year ended 31 January 2025:
https://www.sec.gov/Archives/edgar/data/1640147/000164014725000052/snow-20250131.htmTwilio, Form 10-K for the year ended 31 December 2025:
https://www.sec.gov/Archives/edgar/data/1447669/000144766926000021/twlo-20251231.htm