Choosing a Payments Processor for a SaaS Platform Integration

Choosing a payments processor is not a procurement exercise, and platforms that treat it like one, comparing rates on a spreadsheet and picking the cheapest line item, tend to find out why about two years in. That's usually when the processor picked on price turns out unable to support payouts, can't handle KYB at scale, or won't let the platform touch its own pricing. The processor a platform picks determines how much of the payment margin it keeps, who owns the merchant relationship, how onboarding and risk get handled day to day, and whether payments scale with the product or end up holding it back.

This decision sits upstream of nearly everything else a platform does with money, including pricing models, the merchant's day-to-day experience, compliance exposure, and eventually the multiple the platform commands at exit. Get the processor wrong and every one of those downstream decisions gets harder to unwind later. The platforms now capturing the growth in embedded finance are the ones that picked their infrastructure early, with a clear view of what they wanted to own versus what they'd hand off. The rest are still trying to renegotiate contracts they signed for the wrong reasons, and renegotiating a payments contract after two years of merchant onboarding is a far worse position than picking correctly the first time.

What embedded payments generate for a platform, and the size of the gap from "integrated" to "embedded"

Two terms get used almost interchangeably in sales decks, and they shouldn't be. Integrated payments means a third-party processor runs the whole show while the platform collects a referral fee for pointing merchants at it. Embedded payments means the platform captures the margin itself, owns the merchant relationship, and controls the payment experience directly. Treating those as the same decision is the single most expensive mistake a platform can make in this space, and the mistake compounds with volume rather than staying fixed.

Take a home services or field-services platform earning 75 basis points on a solidly seven-figure annual processing volume. Moving from a referral arrangement to an embedded one on that same volume can nearly double the platform's revenue from that single line item, without adding a single new merchant. Real companies show what the ceiling looks like once a platform commits to owning that layer: embedded payments account for more than half of Mindbody's revenue, and Shopify's merchant solutions segment, with payment processing as the primary driver, made up 74% of total revenue in 2023.

The arithmetic runs the other way too, and it runs unforgiving. A platform pushing volume through a third-party processor at 2.5% while its own true cost is 2.0% is leaving $500,000 a month on the table, simply because nobody went back and renegotiated the architecture underneath it. None of this is a coincidence, and none of it is only about the revenue line. Payments doesn't just generate its own line item, it makes the rest of the product harder to leave, because a merchant who gets paid through the platform, sees reconciliation inside the platform, and disputes a chargeback inside the platform has three more reasons to stay than one who just logs software hours.

The three infrastructure models a SaaS platform must choose between before evaluating any specific processor

Before a platform compares vendors, it needs to pick a model, because the model decides which vendors are even relevant. There are three of them, and most platforms default to the wrong one out of inertia rather than picking it on purpose.

The referral, or ISV, model is the simplest: the platform refers merchants to a third-party processor and earns a modest fee for the introduction. No margin capture, no ownership of the merchant relationship, almost no compliance burden. It's the easiest way to get started, and it carries the lowest ceiling of the three. That's why so many platforms outgrow it within a couple of years and then scramble to migrate merchants off a system they never should have leaned on that long.

PayFac-as-a-Service, usually shortened to PFaaS, is in the middle, and for the vast majority of SaaS platforms it's the right answer, not full registration. The platform captures the spread between the wholesale rate it pays and the rate it charges sub-merchants, and it controls pricing, onboarding, and branding. An infrastructure partner handles the sponsor bank relationship, regulatory compliance, and underwriting, the parts that would otherwise take years to stand up. None of the 12-to-24-month registration timeline or full compliance obligation of becoming a registered PayFac applies here.

Full PayFac registration sits at the top of the stack, and it's the model most founders overrate. The platform owns all the margin and all the control, but it also owns all the risk and compliance responsibility that comes with it. That registration process runs 12 to 24 months and typically requires infrastructure investment north of £500,000. It makes sense only for platforms processing over a billion dollars annually, particularly ones that need hyper-niche payment configurations no standard API offers off the shelf. Below that volume, full registration is a vanity project dressed up as an ownership strategy, and the platforms that choose it anyway usually spend their second year of operation rebuilding compliance functions a PFaaS partner would have handled from day one.

PFaaS can collapse time to market from months to weeks and cut merchant onboarding time from weeks down to minutes. Building the equivalent infrastructure in-house can run past $1 million in development cost and take 12 to 24 months to ship, while a PFaaS partnership can get a platform live in a fraction of that time. Stax Payments found that 91% of independent software vendors expect embedded payments to play a bigger role in their growth strategy over the next year, and most of that 91% are nowhere near ready for full PayFac registration. PFaaS is doing the heavy lifting across the market right now, and for most platforms reading this, it should be the default starting point.

Merchant onboarding and KYB: the first dimension where processors diverge in ways that cost platforms revenue

Onboarding is the moment a merchant either goes live and starts generating revenue for the platform, or gets stuck in a queue and churns before processing a single transaction. There's no partial credit here. A platform either gets this moment right, or it loses the merchant before the relationship starts.

The compliance floor itself is fixed and not up for negotiation. FinCEN's Customer Due Diligence Rule and the Beneficial Ownership Reporting Rule, alongside card network rules, require due diligence on every merchant before it can be boarded, and no processor gets to skip that step.

How a processor implements that requirement varies enormously though, and that variation raises lost revenue, not just inconvenience, and it is visible in the platform's monthly numbers. Sumsub's European KYB Benchmark Survey found that verifying a corporate client takes longer than a day for a large share of businesses, and 81% of businesses report losing clients to onboarding delays. Research has found that 73% of compliance teams consider merchant onboarding the single most time-consuming process they manage. Those figures describe a systemic failure point built into how most processors handle this step, not an occasional edge case that only shows up under stress.

A platform evaluating a processor on this dimension needs specific answers about how onboarding actually works. Does the processor run API-driven KYC and KYB that pulls and verifies merchant data in the background, so a merchant starts accepting payments in minutes instead of days? Is onboarding white-labeled inside the platform's own interface, or does it kick the merchant out to a third-party page that breaks the product experience they were promised? How much of the underwriting decision runs automated, and what does the escalation path look like when a case doesn't fit the standard model? Does the processor support perpetual KYB, with ongoing monitoring after approval, rather than a single point-in-time check that goes stale the moment risk factors change?

Revenue control and pricing architecture: how much margin the platform captures depends on the processor's model

Two fundamentally different economic arrangements exist here, and platforms that don't know which one they're in tend to find out only once volume has grown large enough for the difference to hurt. In one, the processor sets pricing and the platform earns a fixed referral fee or revenue share: predictable, but capped, with zero pricing leverage. In the other, the platform sets its own merchant-facing rates, pays a wholesale rate to the processor, and keeps the spread. That second arrangement is the PFaaS model, and it's the one that scales with volume instead of staying flat. If the growth plan depends on payments revenue compounding alongside processing volume, the first arrangement can't deliver that, full stop, and no amount of contract renegotiation later fixes a model built the wrong way from the start.

A platform needs firm answers before signing with any processor. Does the platform set its own rates, or does the processor dictate them from above? Is the wholesale rate fixed for the life of the contract, tiered by volume, or open to renegotiation as the platform grows? Are there per-merchant minimums, monthly account fees, or platform fees baked in that quietly erode margin before volume ever builds? Are value-added services like reporting, dispute management, or a card vault bundled into the base rate, or billed separately on top of it?

A lot of the real margin lives in interchange optimization, and most evaluations skip it. Platforms that understand interchange categories, and that can influence how a transaction gets routed and coded, capture meaningfully more margin on the same gross volume than platforms that leave that decision entirely to the processor. A processor offering interchange-plus pricing with real transparency and advisory support is structurally more useful here than one offering flat-rate pricing that hides the true cost underneath a simple-looking number, and platforms that pick flat-rate pricing for its simplicity are usually the ones leaving margin on the table without knowing it.

The commonly cited range of 30 to 100 basis points a platform earns on card volume isn't a fixed feature of the market. It reflects how much pricing control the platform negotiated up front, and whether the processor's own economics were built to protect platform margin or protect processor margin. Those are not the same design goal, and no processor optimizes for both equally, so a platform that assumes its processor is on its side by default is making an assumption the contract almost never supports.

Pay Out and Pay Ops capabilities: why processors that only handle acceptance leave platforms with half a product

Most processor evaluations stop at card acceptance, at taking money in from the end customer. That's the wrong place to stop. The platforms that build the stickiest products own the money-out and money-management layer too, and that's exactly where a lot of processor comparisons quietly fall apart once someone actually checks the fine print.

On the Pay Out side, a few questions separate a full platform from a half-built one. Can the processor disburse funds to merchants, vendors, or service providers, not just move money from customer to platform? What rails does it support (standard ACH, same-day ACH, push-to-card, wire), and what are the actual settlement timelines on each one? Is accounts payable automation part of the offering, or does the platform have to bolt on a second vendor just to pay its own merchants?

On the Pay Ops side, the questions run just as deep. Does the processor surface transaction-level reporting and reconciliation directly inside the platform's UI, or does engineering have to build that reporting layer itself from raw data? Is there real tooling for managing disputes and chargebacks, or does that workload land back on the platform's own operations staff by default? Can the processor support platform-generated invoices and recurring billing, or is acceptance limited strictly to a checkout flow?

A platform processing payments already holds the transaction data and merchant relationship needed to offer capital advances, working capital, or embedded lending down the line. That opportunity only materializes if the processor's infrastructure was built to support it from the start. A processor that only handles acceptance isn't a neutral choice on this point, it quietly caps how far the platform can go later, and that cap becomes visible only when the platform is already trying to launch the lending product and discovers the rails simply aren't there.

AI and automation in payment operations: what processors deliver versus what they claim

2026 is shaping up as a pivotal year for what the industry calls agentic payments: AI systems that initiate, manage, and execute transactions with delegated authority, acting on a user's behalf toward a defined goal without a human approving every step. That's the pitch, at least, and most of the market simply isn't there yet.

A lot of tools marketed as agentic are, in practice, decision-support and acceleration layers. They automate the analysis, the summarizing, and the drafting, while a human still signs off on the final call, and that distinction matters enormously because a platform evaluating processors on AI capability needs to know which one it's actually buying. The marketing language almost never makes the difference obvious on its own.

What's demonstrably real right now is narrower, but genuine. 87% of global financial institutions have deployed some form of AI or machine-learning-driven fraud detection. GenAI-assisted dispute and chargeback management, summarizing evidence, drafting responses, classifying case types, is offered by major processors including PayPal and by specialized vendors such as Chargepay, Chargeflow, and Justt. Automated merchant risk monitoring, watching live transaction streams for anomalies, is running in production today, not sitting in a pilot somewhere.

So the questions to put to a processor claiming AI capability need to cut past the marketing copy directly. Is the AI native to the underlying infrastructure, or is it a dashboard bolted on top of a system that wasn't built for it? Does the AI layer expose actual tools or APIs the platform's own engineers can build against, or is it locked inside the processor's interface with no way out? Can AI agents, whether voice agents or workflow automation agents, actually connect into payment operations through standardized tool integrations? And is the processor's agentic commerce roadmap running in production today, or is it still a slide in a pitch deck?

Developer experience and integration architecture: how the processor's API and SDK quality affects time-to-revenue

A processor is a long-term technical dependency, not a one-time integration checkbox. The quality of that integration decides both how fast a platform gets to revenue and how much engineering time gets consumed maintaining the connection for years afterward, and that second cost rarely appears in the initial vendor comparison.

API design matters most, because it decides whether engineers build on top of the platform or work around it. A RESTful structure with clear documentation, consistent versioning, and a deprecation policy a team can actually plan around beats a patchwork of endpoints bolted on over a decade with no consistent pattern between them. SDK coverage across the languages and frameworks the engineering team actually uses matters just as much: a missing SDK means someone on staff is now maintaining a wrapper library that was never in the original project plan. Sandbox and testing environments need to mirror production closely enough that what works in staging actually works on launch day, and webhook reliability (how consistently the processor notifies the platform when a payment status changes) decides whether reconciliation logic can be trusted or needs constant manual double-checking.

None of this appears on a rate sheet, and none of it gets negotiated in the first sales call. But a well-built integration ships in a single quarter, while a poorly built one consumes a platform's engineering roadmap for a year, with the rest of the product waiting in line behind it.