Payments Monetization Readiness Assessment for SaaS Platforms
Boost SaaS payments revenue by fixing infrastructure, product design, pricing, and operations.
Embedded payments is not a side project for a SaaS platform that executes it well. It becomes the largest line on the income statement, bigger than the subscription business that the company was originally built around. In 2024, Toast processed billions of dollars in payments revenue, but only hundreds of millions in subscription fees, and that ratio flips the traditional software revenue model on its head. Payments revenue scales with how much money moves through a customer's business, not with how many seats that customer buys. A subscription line is capped by headcount and renewal cycles. A payments line grows every time a merchant rings up a sale, with no new contract required and no sales team involved.
Most platforms never get near that outcome, and the shortfall has nothing to do with the size of the opportunity. It comes down to a handful of decisions that can be named, measured, and fixed. The referral or ISO model, still the default arrangement at many platforms, produces a fraction of the revenue that a PayFac-as-a-Service setup generates on the exact same processing volume. The model choice alone multiplies or divides the outcome before attach rate, pricing, or anything else even enters the picture. None of this means a platform has to copy Toast or Shopify feature for feature. You need to take an honest look at where the platform actually stands across the dimensions that decide whether payments becomes a real revenue line or stays a footnote, and then close the gaps in the right order.
The four dimensions a payments monetization readiness audit must cover
A readiness audit that only looks at one or two of these dimensions will give a distorted picture, because revenue leakage can originate from any of them, and they do not operate independently. Infrastructure model asks which monetization architecture a platform is actually running, whether that's referral, integrated markup, PayFac-as-a-Service, or full PayFac registration, and whether that architecture matches the platform's current scale and its ambition. Attach rate asks what share of eligible merchants are actively processing payments on the platform today, and whether the product itself is built to drive that number up or to let it stall. Pricing asks whether the take rate reflects the value the platform delivers or whether it left basis points on the table by anchoring pricing to a processor's rate card. Operational readiness asks if onboarding, risk monitoring, and compliance infrastructure can support growth, or if they drag on the merchant experience or sit as a liability on the balance sheet.
These four dimensions also run in a useful sequence. Infrastructure model sets the ceiling on what a platform can possibly earn. Attach rate determines how much of that ceiling actually gets reached. Pricing governs how much of the volume that attaches turns into margin. Operations determines how well the whole structure holds up as volume grows. Revenue leakage in one of the four often masks what is happening in another. The audit has to run across all four together.
Dimension 1 - Infrastructure model: whether your monetization architecture matches your scale
The infrastructure model a platform runs sets the ceiling on what it can earn before a single merchant signs up. A 5 to 10x difference in revenue on identical processing volume is common between models, and that gap is driven by the model itself, not by how much volume moves through it.
Under a referral or ISO arrangement, the platform sends merchants to a processor and collects a small residual on the volume that results. The platform does not underwrite merchants, does not hold the merchant accounts, and in any meaningful sense, it does not own the merchant relationship. An integrated or fee-on-top markup model is a step up: the platform sets a price above its processing cost and keeps the spread, though it still lacks the pricing flexibility, control over the merchant experience, and access to transaction data that the embedded models below it offer. PayFac-as-a-Service lets a platform capture the economics and the experience control that come with being a payment facilitator, without registering as one directly. This is the model that fits most vertical SaaS platforms, and it's reachable in months rather than the year or more a full PayFac build typically takes. The net take rate under PFaaS is meaningfully higher than what a referral deal produces. Full PayFac registration puts the platform in the position of merchant of record: full control, full economics, and full liability. Setup and upkeep cost real money, so you need substantial volume before registration pencils out, and you need even more once you price headcount honestly into the comparison.
A platform must know which model it is actually running, and whether the net take rate it earns lines up with that model's real economics. One useful test: ask any PFaaS provider whether the arrangement is a genuine processing-margin revenue share, where the platform can price merchants above the provider's cost and keep the difference, or a fixed referral fee dressed up in better branding. The two look similar in a sales deck and produce very different numbers over a year of volume. Platforms at early stages of GPV should optimize for speed and low fixed cost rather than maximum margin capture, which makes PFaaS close to the default right answer at that stage. When a platform nears or passes a significant GPV threshold, it should run the full PayFac math honestly, counting headcount, compliance infrastructure, and liability exposure before it concludes registration is worth it. If a platform says it's running PFaaS but can't state its net take rate or say whether it controls merchant pricing, then in structural terms it is almost certainly still running a referral arrangement.
Payabli is one example of infrastructure built for that last path, offering onboarding, payment acceptance, and payout functions on a single platform.
Dimension 2 - Attach rate: whether your product design drives merchant adoption
Attach rate, the share of eligible merchants actively processing payments on the platform, is the single highest-leverage number in this entire exercise, and most platforms stall well below where they should sit for a reason that can be found and fixed. Most platforms top out at a fraction of eligible merchants actually processing on-platform, and the revenue sitting behind that gap is large: moving a mid-sized customer base from a low attach rate to a high one can add millions of dollars in monthly GPV without signing a single new customer.
The cause is almost always architectural. Payments gets built as a secondary menu item instead of as a step embedded directly into the workflow the merchant is already running, the quote, the invoice, the booking confirmation, the point where service gets delivered. Platforms that break through this ceiling treat payment collection as a native part of the primary workflow rather than a feature a merchant has to go find and opt into on their own.
You can run a real audit of attach rate through a specific set of questions. What percentage of eligible merchants are processing through the platform right now, and if that number isn't known, that absence is itself a finding worth acting on. Where in the product does a new merchant first run into the option to process payments, inside the main workflow or down a secondary navigation path they may never click? Is the path from signup to an activated payment account short enough that a motivated merchant can finish it without leaving the product or waiting on manual review? Is payment activation a standard part of onboarding every new merchant, or a separate step they have to choose to take? And for merchants who never activate, is there a re-engagement path bringing them back, or do they just sit unattached indefinitely, uncounted and unmonetized?
Attach rate also does something beyond adding revenue. A merchant whose money runs through the platform is defending a treasury relationship, not just a piece of software, and treasury relationships are far harder to walk away from than a subscription. Embedding financial services into the product builds a switching cost that software alone, no matter how good, rarely produces on its own.
Dimension 3 - Pricing: whether your take rate reflects the value your platform delivers
The ceiling on what a platform can charge for embedded payments is set by the total value the platform delivers to the merchant, not by the rate card of a standalone payment processor, and platforms that understand that distinction price differently and keep more margin for it. A platform with deep workflow integration has a structurally higher pricing ceiling than a processor that sells payments alone, so if it prices to match the standalone processor's rate, it leaves real margin on the table unclaimed.
A pricing audit should work through several concrete questions. What is the platform's current effective take rate, meaning net payment revenue as a share of GPV, and does that number fall where its infrastructure model says it should? Is merchant pricing set above the platform's own processing cost with the spread retained, or is it a pass-through fee dressed up as pricing? And does the pricing model account for every payment method and channel the platform supports, or are some of those channels quietly subsidized without anyone noticing?
Revenue recognition, gross versus net, doesn't change the cash that is in the bank, but it changes how growth looks to anyone who evaluates the business from outside. Investors and acquirers who evaluate embedded payments businesses tend to anchor on GPV as the measure of scale and take rate as the measure of efficiency, so a platform that can't state both numbers clearly is simply harder to value correctly.
Dimension 4 - Operational readiness: whether onboarding, risk, and compliance infrastructure can support growth
A platform can get the infrastructure model right, build a strong attach rate, and price well, and still fail at scale if the operational layer isn't built to carry the weight. The compliance and operational surface that comes with embedded payments runs wider than most platforms expect going in, and skimping on it doesn't save money. It produces the liability events and the merchant experience failures that quietly erode the revenue the first three dimensions worked to build.
Any platform that stores, transmits, or facilitates payments is operating inside regulated financial services, whether it thinks of itself that way or not. KYC and KYB checks on onboarded merchants, AML transaction monitoring, and PCI DSS requirements for any card data all come into play depending on how the platform is built. When platforms still rely on manual underwriting, they see higher merchant drop-off during activation, and that friction suppresses the attach rate built up in dimension two.
VAMP, the Visa Acquirer Monitoring Program, measures fraudulent transactions and non-fraud disputes as a share of total Visa transactions settled, and if a platform facilitates Visa transactions, it has to monitor it. Split-payment funding, reconciliation down to the cent, and dispute handling are ongoing operational responsibilities rather than tasks finished once at setup, and platforms that don't staff or automate them accumulate errors that get larger as volume grows.
A full operational audit should answer several direct questions. How long does it take a new merchant to complete payment activation from the start of onboarding, and what share of merchants who begin that process actually finish it? Is KYC and KYB verification automated, or does it depend on manual review steps that introduce delay and drop-off? Does the platform monitor fraud and chargeback ratios in real time, with a defined escalation path once thresholds get close? Is reconciliation current and automated, or is the finance team sitting on a manual backlog? Who carries financial liability for sub-merchant chargebacks and fraud losses under the current arrangement, and does the platform's leadership know what that exposure is? Is the platform's PCI DSS scope clearly defined, and is it currently certified at the right level?
Artificial intelligence and agentic automation are moving from concept into early production use inside payment operations specifically, with treasury management, payment routing, exception handling, and reconciliation as the first areas where automation is cutting real operational burden. Platforms building out this layer now should design it to support automation from the start rather than building manual processes they'll have to tear out and replace later. Payment messaging now carries richer, more standardized data, and that has already removed a major obstacle to that kind of automation, because it makes transaction data structured enough for systems to act on it directly.
Revenue leakage across these four dimensions rarely stays contained to one. A gap in attach rate becomes a pricing problem later, because low volume makes it harder to justify a higher take rate; a gap in operational readiness becomes an attach rate problem later, because merchants abandon a slow or manual onboarding flow before they ever process a transaction. A unified platform built to span infrastructure, attach, pricing, and operations together, the approach Payabli takes as an AI-native fintech operating system, lets builders audit and close these gaps as one connected system rather than patching each one with a separate point solution. The audit itself is the starting point. What a platform does with what it finds decides whether payments becomes the revenue line Toast built, or stays the afterthought most platforms leave it as.
