Embedded payments revenue changes how a SaaS company is valued. Not incrementally — structurally. The multiple expansion for vertical SaaS platforms with mature payments programs is well-documented: 7–9.5x revenue for platforms with embedded fintech versus 4.8–6.2x for software-only businesses at similar scale.

That premium doesn't come from the payments revenue itself. It comes from what payments revenue signals: high-margin, transaction-linked income that scales with merchant growth, creates structural switching costs, and doesn't require proportional headcount to grow. Acquirers and investors model it differently because it behaves differently.

Why Payments Revenue Gets a Premium

Software subscription revenue is valued on retention and growth. Payments revenue is valued on those plus three additional dimensions:

Margin structure. Net payments revenue (after interchange and processor costs) typically runs at 70–85% gross margin — comparable to or better than software subscription margins. For platforms operating at PayFac-as-a-Service or full PayFac levels, the incremental margin on each new merchant is even higher because operating costs are largely fixed.

Volume correlation. Payments revenue scales with your merchants' business growth, not just your own customer acquisition. A merchant who grows their revenue by 20% generates 20% more payment volume — and 20% more payments revenue for you — without any action on your part. This "embedded growth" is something investors model explicitly.

Switching cost amplification. A merchant using your embedded payments has two reasons to stay: the software and the payment infrastructure. Migrating away means re-boarding with a new processor, changing their reconciliation workflows, and potentially disrupting their cash flow during transition. This compounds software-only retention and reduces churn risk in the acquirer's model.

How Acquirers Model Payments Revenue

Sophisticated buyers don't just add payments revenue to software revenue and apply a blended multiple. They model payments as a distinct revenue stream with its own growth drivers and cost structure.

Current state: What's the net take rate? What's the activation rate? How much of total merchant volume flows through embedded payments? What are the operating costs (support, compliance, chargeback losses)?

Upside case: What would revenue look like at 80% activation versus today's 40%? What would the economics look like under a more advanced model (PFaaS versus referral)? Are there merchant segments not yet activated? Is there pricing optimization available?

Risk assessment: Is the processor agreement transferable? Are there change-of-control provisions that could reset pricing? Is the revenue dependent on a single processor relationship? Could a better-funded competitor replicate the integration?

The buyer's model typically shows three scenarios: maintain (current trajectory), optimize (better activation + pricing), and transform (model upgrade). The spread between these scenarios is the "payments optionality" that drives premium pricing.

What Drives the Multiple

Not all payments revenue is valued equally. The factors that push the multiple higher:

• Ownership level. PayFac-as-a-Service revenue (you set rates, own the merchant relationship) is valued higher than referral revenue (processor owns the relationship, you earn a residual). The former is defensible. The latter can be repriced or eliminated by the processor.
• Activation rate. A platform with 60%+ merchant activation demonstrates execution capability. One with 15% has a roadmap, not a business line. Acquirers pay for proven activation, not potential.
• Net take rate trajectory. A net take rate that has expanded over time (through renegotiation, model upgrades, or pricing optimization) signals operational maturity. One that has contracted signals margin pressure.
• Revenue concentration. Payments revenue spread across hundreds of merchants is more valuable than the same revenue concentrated in a handful. Diversification reduces risk in the buyer's model.
• Contract structure. Multi-year processor agreements with favorable volume ratchets, no exclusivity, and clean change-of-control provisions are worth more than agreements that expire in 6 months or require processor consent to transfer.

Revenue Recognition and Reporting

How you report payments revenue matters for valuation. There are two approaches, and the difference affects perceived scale and margin:

Gross reporting: You report total payment volume processed or total merchant charges as revenue, then show processing costs as COGS. This inflates top-line revenue but compresses margins. Some platforms report this way to make their revenue number look larger.

Net reporting: You report only the net margin retained after interchange and processor costs. This shows a smaller revenue line but higher margins. Most sophisticated buyers prefer this because it reflects the economics you actually control.

If you're preparing for a fundraise or exit, align your reporting with how the buyer will model it. Most PE firms and strategic acquirers will restate to net regardless of how you present it — so reporting net from the start demonstrates financial sophistication and saves diligence time.

The Optionality Premium

The most interesting valuation dynamic is what we call the optionality premium: the value attributed to payments revenue that doesn't exist yet but is structurally available.

A platform processing $80M in merchant volume through ISV Referral at 15 bps is earning $120K in payments revenue. Under PayFac-as-a-Service at 55 bps, the same volume would generate $440K. The $320K gap is unrealized revenue — but it's not theoretical. The volume exists. The merchants are already there. The only question is execution.

A platform that has already made the structural decision — chosen a model, built the activation playbook, knows its net take rate — is a fundamentally different asset than one where payments is still a line item on the roadmap.

Buyers price this optionality into their model as "Year 2–3 upside." The platform that can demonstrate a credible path from current state to optimized state — with a plan, not just a projection — captures that optionality in the purchase price rather than giving it away to the buyer as their value creation thesis.

Preparing for the Conversation

If an exit or fundraise is on your horizon (12–24 months), the payments preparation checklist:

• Build a standalone payments P&L that isolates revenue, COGS, and operating costs
• Track net take rate monthly and show the trend
• Document your activation rate and the trajectory
• Clean up your processor agreement (termination rights, change of control, rate sustainability)
• Model the upside case and have a credible plan to capture it
• If you're in referral and your volume justifies PFaaS — make the move before the process, not during it

Related: Payments Due Diligence: What Acquirers Look At covers the operational diligence workstream. How to Read a Payments P&L is the framework for building the financial view investors expect. For M&A readiness advisory, see the advisory engagement.

This article was originally published on Margin Labs.

Chargebacks are the operational reality that most platforms discover after launching embedded payments — not before. Vendors don't lead with it. The integration docs gloss over it. And then a merchant calls about a disputed transaction and the team realizes there's no process for handling it.

Chargebacks are manageable. The platforms that stay healthy manage them proactively. The ones that run into problems treat them as exceptions until they become a systemic issue.

What a Chargeback Actually Is

A chargeback is a payment reversal initiated by a cardholder's bank. The cardholder disputes a transaction — claiming it was unauthorized, the goods or services weren't delivered, or the merchant misrepresented the transaction — and the bank reverses the payment, debiting the merchant's account and crediting the cardholder.

As a platform operating embedded payments, you sit between the merchant and the processor. When a chargeback is filed against one of your merchants, you're the first-line responder. You have a limited window — typically 5 to 7 calendar days from notification — to submit evidence challenging the dispute. If you don't respond in time, the chargeback defaults in the cardholder's favor.

Beyond the financial loss on an individual dispute, chargebacks carry fees ($15–$35 per dispute, regardless of outcome) and accumulate toward network thresholds that can put your entire payments program at risk.

The Thresholds That Matter

Visa and Mastercard monitor chargeback ratios at the merchant and facilitator level. Exceeding their thresholds triggers monitoring programs that are expensive and difficult to exit.

In a PayFac-as-a-Service or full PayFac model, your aggregate chargeback ratio across all sub-merchants is what the networks monitor — not individual merchant ratios in isolation. A single high-risk merchant with an elevated chargeback rate can push your program into monitoring territory if their volume is significant relative to your total. Underwriting quality and ongoing monitoring are your primary defenses.

Building a Response Process

The response process has three components: notification, evidence assembly, and submission.

Notification. Your processor or PFaaS provider will notify you when a chargeback is filed. Confirm how — email, dashboard alert, API webhook — and make sure the right person sees it within 24 hours. The response window is short and the default is losing.

Evidence assembly. What you submit depends on the chargeback reason code. For "unauthorized transaction" disputes, you need evidence the cardholder authorized the transaction: IP address, device fingerprint, billing address match, authentication records. For "goods not received" or "services not as described," you need delivery confirmation, service records, communications with the merchant's customer. Build templates for the most common reason codes in your vertical so responses can be assembled quickly.

Submission. Most processors accept evidence through a dispute portal. Some require specific file formats and page limits. Know your processor's requirements before you need them — not when you're 48 hours from a deadline.

Prevention Is Cheaper Than Response

The best chargeback management is keeping the chargeback rate low in the first place. The most effective levers:

• Clear merchant descriptors. The most common source of "unauthorized" chargebacks is a cardholder who doesn't recognize the transaction on their statement. The merchant's name as it appears on the cardholder's statement should match their DBA name and be recognizable. A cardholder who remembers paying "Riverside Plumbing" and sees "RVS PLB LLC" will sometimes dispute it. Simple to fix, often overlooked.
• Prompt refunds. A merchant who processes a refund quickly rarely generates a chargeback for the same transaction. Build refund capabilities into your platform so merchants can issue credits without going through a separate process. The chargeback fee ($15–$35) almost always exceeds the cost of the refund.
• Merchant screening. High-risk merchant categories — travel, event ticketing, subscriptions, digital goods — generate disproportionate chargeback volumes. Know which categories are in your merchant base and either apply tighter underwriting criteria or exclude categories that create risk you can't manage.
• Transaction velocity monitoring. Unusual transaction patterns — multiple charges in a short window, transactions far outside a merchant's normal ticket size, late-night processing spikes — often precede chargeback waves. Basic monitoring catches most of the obvious patterns.

Reserve Management

Processors hold rolling reserves — typically 5–10% of monthly processing volume, released on a 90–180 day rolling schedule — as a buffer against chargeback losses. Reserves are normal and expected, especially for new programs.

As your program matures and your chargeback history builds, reserve requirements should decline. If your processor hasn't reduced reserves in line with your performance, that's a negotiation conversation worth having. Reserves are capital you're not deploying elsewhere.

The platforms that manage chargebacks well aren't the ones with the most sophisticated tooling. They're the ones who built a process before they needed it.

Related: PayFac-as-a-Service covers the operational responsibilities that come with the PFaaS model, including chargeback first-response obligations. For a full review of your payments operations posture, see the advisory engagement.

This article was originally published on Margin Labs.

Most ISV processor agreements — whether with Fiserv, Global Payments (TSYS), Worldpay, or any other major acquirer — are signed once, filed away, and never revisited. The platform grows, volume increases, and the economics of the original deal become progressively worse relative to what the platform could now command. The processor is happy to let this continue.

Processor agreements are negotiable — at signing and at renewal. This article covers what's actually on the table, when you have leverage, and what platforms that negotiate well typically get.

Understand the Structure First

A processor agreement has three economic layers, and they're not all negotiable in the same way.

Interchange passthrough is set by the card networks (Visa, Mastercard, Discover, Amex). It's non-negotiable. Every processor pays the same interchange for the same card type and transaction. If a vendor tells you they're offering you "better interchange," they're either confused or misrepresenting how the system works.

Network assessment fees are also set by the card networks. NABU, APF, NNSS, cross-border fees — these are passthrough costs that legitimate processors pass through at cost. Watch for processors who bundle these into a single opaque rate; it obscures how much they're actually marking up.

The processor spread is the margin your processor earns above interchange and assessments. This is what you're negotiating. It's usually expressed as basis points above interchange, a flat per-transaction fee, or both. This is where the money lives.

When You Have Leverage

Leverage in processor negotiations comes from three sources: volume, competition, and optionality.

Volume is the primary lever. Processors model their pricing on expected volume. If your volume has grown significantly since signing, your original pricing reflects a risk profile and economics that no longer match reality. You're paying small-platform rates on large-platform volume. That gap is your negotiating position.

A rough rule: renegotiate every time your annual volume doubles, or every two years, whichever comes first. Most platforms that do this recover 3–8 basis points on the spread — which at $50M in volume is $15K–$40K per year for a conversation that takes a few weeks.

Competition creates urgency. A processor who knows you're evaluating alternatives — whether that's another traditional processor like Worldpay or Fiserv, or a modern platform like Stripe that publishes pricing publicly — will move faster and offer more than one who thinks you're locked in. You don't have to be serious about switching. You have to credibly signal that you're willing to. Stripe's transparent pricing model (2.9% + $0.30 standard, lower for custom deals) has become a de facto benchmark that gives you a comparison point even if you never intend to use them.

Optionality matters at contract signing. Once you've signed a three-year exclusive agreement with an early termination fee, your leverage is effectively zero until renewal. The time to negotiate termination rights, volume flexibility, and rate adjustment clauses is before you sign, not after.

What's Negotiable

Processor spread. The most direct lever. Push for basis points above interchange rather than a blended rate — it's more transparent and easier to benchmark. Get competitive quotes and use them.

Per-transaction fees. Often overlooked because they seem small. $0.05 per transaction on 100,000 monthly transactions is $5,000/month — $60,000/year. These are negotiable, especially at volume.

Volume ratchets. A clause that automatically reduces your spread as your volume crosses defined thresholds. You want these in the contract so you don't have to renegotiate every time you grow. Processors resist them because they reduce future pricing power. Push hard for them anyway.

Exclusivity terms. Some processors require exclusivity as a condition of favorable pricing. Be cautious. Exclusivity eliminates your leverage at renewal and limits your ability to run multi-processor strategies as you scale.

Termination rights. Aim for a termination for convenience clause with no more than 90 days notice and no early termination fee, or a fee that scales down over the contract term. Processors prefer longer notice periods and meaningful ETFs. This is a negotiating point, not a given.

Reserve requirements. Processors hold reserves against chargeback and fraud risk. The percentage and release schedule are negotiable, especially for established platforms with clean chargeback histories. Lower reserves improve your cash flow.

Settlement timing. Standard is T+2 (funds settled two business days after transaction). Next-day or same-day settlement is available and sometimes negotiable, particularly if you're willing to pay a small fee or your volume justifies it as a standard term.

What You Should Never Accept

Blended rate pricing without interchange passthrough. A blended rate bundles interchange, assessments, and processor spread into a single number. It's easier to understand but impossible to benchmark or audit. As your transaction mix shifts — more premium cards, more e-commerce, more international — a blended rate works against you. Insist on interchange-plus pricing.

Automatic renewal without rate review. Agreements that auto-renew lock in pricing that was negotiated under different volume conditions. Require a rate review trigger at renewal.

Vague chargeback liability language. Understand exactly what your exposure is. What's the chargeback threshold that triggers enhanced monitoring or reserve increases? What happens if you exceed it? These terms have real financial consequences and should be explicit, not left to processor discretion.

How to Run the Process

Get three competitive quotes before your primary negotiation — from processors like Fiserv, Global Payments, and Worldpay, or from PFaaS providers if you're evaluating a model change. Use them as anchors. Most processors will match or beat a competitive offer if the volume is meaningful and you're credible about alternatives.

Negotiate the economics first, then the contract terms. Getting alignment on spread and fees before engaging legal counsel keeps the process moving and signals that you're serious but efficient.

The platforms that get the best processor deals aren't the ones with the most volume. They're the ones who negotiate like they know what the deal is worth.

Related: How to Read a Payments P&L — understanding your current net take rate is the foundation for knowing whether your processor agreement is competitive. The advisory engagement includes processor agreement review and negotiation support.

This article was originally published on Margin Labs.

Integrated Payments: Connection

Integrated payments means your software connects to a payment processor. The merchant can accept payments without leaving your application. But the payment experience is the processor's — their boarding flow, their settlement schedule, their merchant portal, their support line.

You've built a bridge between your software and a payment system. The bridge is valuable. Merchants prefer paying inside the software they're already using. But the payment system on the other side of the bridge belongs to someone else.

In an integrated model, you're typically earning referral residuals (5–25 basis points) because the processor owns the merchant relationship, the pricing, and the risk. Your role is distribution. You send merchants to the processor through your integration, and you earn a share of the volume they generate.

Examples: a scheduling platform with a Stripe Connect integration that lets merchants accept deposits; a field service tool that connects to a processor's gateway for invoice payments; a POS system that pairs with a third-party terminal for card-present transactions.

The integration makes the merchant's life easier. But the payment experience is modular — it could be swapped for a different processor without fundamentally changing how the software works.

Embedded Payments: Ownership

Embedded payments means the payment experience is native to your product. You own merchant onboarding, you set the pricing, you manage the settlement experience, and you participate in the economics at a level that reflects that ownership.

The payment experience isn't bolted on — it's woven into workflows. When a merchant creates an invoice, the payment link is generated automatically. When a customer pays, reconciliation happens in real time within the same system. When a dispute occurs, the merchant manages it from your dashboard, not the processor's.

In an embedded model, you're typically earning 25–90+ basis points because you're carrying operational responsibility and the merchant's relationship is with you, not with a processor they may never interact with directly.

Why the Distinction Matters: Three Dimensions

On economics: integrated payments gives you referral-level revenue (5–25 bps). Embedded payments gives you facilitation-level revenue (25–90+ bps). On $50M in merchant volume, that's the difference between $25K–$125K and $125K–$450K annually. Same merchants. Same volume. Different architecture, different economics.

On competitive position: integrated payments can be replicated by any competitor who connects to the same processor. The integration is valuable but not defensible. Embedded payments — where the payment experience is specific to your vertical workflows, your data model, and your merchant relationships — creates switching costs that compound over time. A merchant leaving your platform doesn't just lose payment processing. They lose the integrated workflows that depend on it.

On exit value: acquirers and investors model embedded payments revenue differently than referral revenue. Referral residuals are viewed as low-margin distribution income that can be renegotiated or eliminated by the processor. Embedded payments revenue — where you own the merchant relationship and the economics — is valued as high-margin, recurring, and defensible. The multiple is materially different.

The Spectrum, Not the Binary

In practice, most platforms sit somewhere on a spectrum between fully integrated and fully embedded. You might own the boarding experience but use the processor's settlement dashboard. You might set the merchant rate but rely on the processor for dispute management. You might embed the payment flow in your product but not participate in the economics at facilitation levels.

The question isn't "are we integrated or embedded?" The question is: "How much of the payment experience do we own, and are the economics aligned with that level of ownership?"

If you're doing the operational work of an embedded program but earning referral-level economics, you have a structural problem worth solving. If you're earning embedded-level economics but the merchant experience still feels bolted on, you have a product problem that will show up in activation rates and churn.

Moving from Integrated to Embedded

The transition from integrated to embedded payments is one of the most valuable — and most underestimated — strategic moves a platform can make. It involves four components:

Taking ownership of merchant onboarding. Instead of sending merchants to the processor's boarding flow, you build or configure a boarding experience within your product. This is where the merchant relationship begins, and it sets the tone for everything that follows.

Setting merchant pricing. Instead of accepting the processor's standard rate card, you negotiate wholesale pricing and set your own merchant rates. This is where the economics shift — and where most platforms leave money on the table by not understanding interchange well enough to price profitably.

Managing the post-transaction experience. Settlement visibility, reconciliation tools, dispute management, and deposit reporting — these are the day-to-day touchpoints that determine whether payments feels like part of your product or a third-party add-on.

Building operational capacity. Embedded payments requires someone who understands chargebacks, compliance basics, and merchant support workflows. This doesn't mean building a payments company. It means having enough operational awareness to manage the 80% of cases that are straightforward and escalate the 20% that aren't.

Integrated payments is a feature. Embedded payments is a business line. The difference is ownership — and ownership is what creates both margin and moat.

The Margin Multiplier shows you the revenue difference between referral-level and facilitation-level economics on your specific volume. Start there if you want to see what the ownership gap is costing you. For more on what this transition looks like in practice, see How SaaS Companies Make Money from Payments and the advisory engagement overview.

This article was originally published on Margin Labs.

Without this model, every other decision is downstream of a guess. You can't evaluate processor proposals, you can't justify implementation investment, and you can't set internal targets that mean anything.

This article walks through the framework. The same inputs. The same math.

Step 1: Start with Gross Merchant Volume

Everything in payments economics starts with volume. Not revenue. Not merchant count. Gross payment volume — the total dollar amount your merchants process through or alongside your platform.

If you don't know average monthly volume, estimate from your vertical's benchmarks. A single-location restaurant processes $30K–$80K/month. A field service company processes $15K–$50K/month. A property management company processes $50K–$200K/month. Use the midpoint and refine with real data later.

Step 2: Apply Your Activation Rate

Not every merchant will use your embedded payments. Some have a processor they're happy with. Some won't switch until you give them a compelling reason. Realistic activation rates by model:

If you're pre-launch, use 30% for year one and 50% for year two. Conservative, but grounded in what platforms typically see across verticals.

Step 3: Model Revenue Under Each Approach

Apply the net take rate for each model to your active GMV. Using our $9M year-one example:

Year three assumes 60% activation and 15% organic merchant growth. The compounding effect of activation growth plus merchant growth is the most underappreciated dynamic in payments monetization.

Step 4: Subtract Operating Costs

Revenue is only half the equation. Each model carries operating costs that don't appear in the vendor pitch deck:

• ISV Referral: Near zero. The processor carries everything. Your only cost is engineering time to maintain the integration.
• Enhanced Residuals: Minimal. Light merchant support responsibility, some compliance overhead. Budget $15K–$30K annually.
• PayFac-as-a-Service: Meaningful. Merchant support (0.5–1.0 FTEs), compliance ($5K–$15K/year), chargeback tooling ($3K–$10K/year), integration maintenance. Budget $60K–$120K annually depending on merchant count.
• Full PayFac: Significant. Dedicated compliance and risk staff, sponsor bank fees, network reporting, reserve management. Budget $150K–$300K annually as a baseline.

This is why model transition thresholds matter. PayFac-as-a-Service costs $60K+ to operate. If your gross payment revenue under that model is $54K in year one, you're losing money. At $90K in year two, you're marginally profitable. At $124K in year three, the economics are clear. The crossover point — where PFaaS net revenue exceeds ISV Referral net revenue after operating costs — typically falls between $40M and $70M in total GMV, depending on activation rates.

Step 5: Calculate the Opportunity Cost

The number that should drive urgency isn't what you're earning. It's what you're not earning.

If you're in ISV Referral at 15 bps with $15M in active volume, you're earning $22,500. Under PayFac-as-a-Service at 60 bps on the same volume, you'd earn $90,000. The annual gap is $67,500 — growing every year.

Over three years, assuming modest growth, that cumulative gap is typically $200K–$500K. That's capital that funds product development, sales hires, or market expansion. It's not abstract. It's real money you're choosing not to capture.

What the Model Doesn't Tell You

Revenue modeling is necessary but not sufficient for making the decision. The model doesn't capture:

• Implementation timeline. A PayFac-as-a-Service integration takes 3–6 months of engineering time. What else could that team be building?
• Merchant churn risk during migration. Moving from referral to PFaaS means re-boarding merchants. Some percentage will use the transition as a reason to evaluate alternatives.
• Strategic value beyond revenue. Owning the payment experience creates data advantages, merchant stickiness, and competitive moats that don't show up in a revenue model but matter enormously at exit.

The model gives you the math. The strategy gives you the decision. Both are necessary.

The Margin Multiplier runs this calculation in about 60 seconds — enter your merchant count, average volume, and current take rate and it shows you the revenue under all four models side by side. If you want to work through the operating cost and transition timing questions, that's what the advisory engagement is built for.

Related: How to Read a Payments P&L — once you've modeled the opportunity, this is the framework for tracking whether you're capturing it.

This article was originally published on Margin Labs.

The model exists because there's a wide gap between the economics of ISV Referral (5–25 basis points) and the cost of becoming a full registered PayFac ($500K+ implementation, 12–18 months to launch, dedicated compliance staff). Most platforms fit somewhere in the middle — they've outgrown referral economics but can't justify the investment of full facilitation. PayFac-as-a-Service fills that gap.

How It Works

In a PayFac-as-a-Service arrangement, a registered Payment Facilitator — providers like Stripe Connect, Finix, Tilled, or Payrix — provides the infrastructure: sponsor bank relationships, card network registrations, compliance frameworks, settlement systems. You operate as a sub-facilitator or managed partner under their umbrella. Adyen for Platforms offers a similar outcome through a different architecture, combining processing and facilitation under one roof.

You handle merchant-facing operations: onboarding, pricing, first-line support, and in some cases, underwriting decisions within pre-approved parameters. The PFaaS provider handles the regulatory layer: network reporting, reserve calculations, compliance monitoring, and the relationship with the acquiring bank.

Merchants are boarded as your sub-merchants. You set the rate. You collect the spread between what you charge and what you pay the provider. The provider earns their margin from the processing cost you pay them — typically interchange plus 10 to 20 basis points, depending on volume and risk profile. Stripe Connect charges differently (a per-transaction platform fee of 0.25% + $0.25 on top of standard processing), while Finix and Tilled price on an interchange-plus model that can be more economical at scale.

The Economics

PFaaS economics sit between ISV Referral and full PayFac:

On $50 million in annual merchant volume, the difference between referral at 15 bps ($75K) and PFaaS at 50 bps ($250K) is $175K per year. That gap grows with every merchant you add.

Implementation costs for PFaaS typically range from $50K to $200K, depending on the provider, your integration complexity, and whether you need custom boarding flows or can use their standard tools. Stripe Connect sits at the lower end for time-to-market; Finix and Payrix offer more white-label control but longer integration timelines. Time to launch is 2 to 6 months — significantly faster than the 12–18 months for full registration.

What You're Taking On

PFaaS isn't a referral program with better economics. You're taking on real operational responsibility.

Merchant onboarding. You manage the boarding experience, collect merchant information, and in many cases make preliminary underwriting decisions. The PFaaS provider approves or flags merchants based on risk criteria, but the merchant experience is yours.

First-line support. When a merchant has a question about their deposit, a chargeback notification, or a rate inquiry, they come to you. You'll need internal tooling or access to the provider's dashboard to handle these.

Pricing management. You set merchant rates. This means you need to understand interchange economics well enough to price profitably across different card types and transaction patterns. Getting this wrong is the most common source of margin compression in PFaaS programs.

Chargeback response. You're the first responder for disputes. In most PFaaS arrangements, you have a window — typically 5–7 days — to respond to chargebacks before they default. This requires process and tooling.

What the Provider Handles

Card network registration and reporting. They maintain the PayFac registration with Visa, Mastercard, and other networks, and handle the quarterly and annual reporting requirements.

Sponsor bank relationship. The acquiring bank relationship — which is the legal foundation for the entire processing chain — belongs to the provider. This is the single most complex and expensive element of becoming a PayFac, and it's what you're outsourcing.

Compliance framework. PCI compliance, AML monitoring, OFAC screening, and suspicious activity reporting are handled by the provider's compliance infrastructure. You feed data into it; they manage the regulatory obligation.

Settlement and funding. The provider manages the settlement cycle, holds reserves where required, and distributes funds to merchants according to the agreed schedule.

When PFaaS Makes Sense

The model fits a specific profile:

• Annual merchant volume between $30M and $200M
• 150 to 1,000+ merchants processing
• At least one person (internal or contracted) who understands payment operations
• You've been in ISV Referral and the economics no longer justify the simplicity
• Full PayFac registration isn't justified by your volume or timeline

PFaaS does not make sense if your volume is under $20M — the operational overhead isn't worth the incremental revenue over referral. And if you're above $200M and growing fast, the economics of full PayFac registration likely justify the investment at that scale.

Managed PayFac vs. Full PayFac: The Real Difference

The question isn't which is better. It's which matches your scale and trajectory.

Full PayFac gives you maximum economics and maximum control. But it requires a sponsor bank relationship (which takes 6–12 months to secure), card network registration ($50K+ in fees), dedicated compliance staff, and ongoing regulatory obligations that don't scale down if your volume dips.

PFaaS gives you 60–80% of the economics at 20–30% of the cost and complexity. For most platforms between $30M and $200M in volume, that trade-off is correct.

The transition from PFaaS to full PayFac is possible but nontrivial. It typically involves migrating your merchant portfolio to a new processing infrastructure, securing your own sponsor bank, and building the compliance and reporting systems the PFaaS provider was handling. Plan for 12–18 months.

PFaaS is the right model when referral economics feel like leaving money on the table, but full PayFac feels like building a payments company instead of a software company.

If you're evaluating the transition from referral to PFaaS, start with the Margin Multiplier to model the revenue difference. If you want to think through the operational readiness and provider selection questions, that's what the advisory engagement is built for.

Related: ISV Referral vs. PayFac-as-a-Service: How to Choose — a side-by-side comparison of the two most common transition points.

This article was originally published on Margin Labs.

Your merchants are in a single industry. Your competitive set is narrow. Your switching costs are structural, not just contractual. Your payment volume is concentrated and predictable. All of this affects which monetization model to choose, how to price it, how to activate merchants, and where the real risks live.

This article is for platform leaders — product, finance, partnerships — at vertical SaaS companies who are either launching embedded payments or trying to improve an underperforming program.

Why Vertical SaaS Is Different

Horizontal platforms serve merchants across industries. Their payment volume is diversified but unpredictable. A merchant might churn for reasons that have nothing to do with the software.

Vertical platforms are the opposite. You serve one industry. Your merchants look alike. Their volume patterns are similar. Their pain points are shared. This concentration creates advantages that most payments advice ignores.

Your activation playbook can be hyper-specific. You know exactly which workflow creates the most payment friction, which reconciliation gap costs merchants the most time, and which reporting limitation drives them to keep a separate processor. Horizontal platforms have to generalize. You can build merchant-specific value propositions with industry language.

Your competitive moat is deeper. When payments are woven into industry-specific workflows — not just a generic checkout widget — switching costs compound. A merchant leaving your platform doesn't just lose payment processing. They lose the integrated scheduling, invoicing, compliance reporting, and reconciliation that your vertical product provides. That's a switching cost no standalone processor can replicate.

Your volume is predictable. Vertical markets have seasonal patterns, average transaction sizes, and growth rates that are well-understood. This makes financial modeling more reliable and negotiating with processors more informed. You can project your three-year volume curve with reasonable confidence — which is a powerful tool in processor negotiations.

Choosing the Right Model for Your Stage

The four monetization models — ISV Referral, Gateway/Enhanced Residuals, PayFac-as-a-Service, and Full PayFac — apply to vertical platforms the same as horizontal ones. But the decision thresholds are different.

Vertical platforms tend to have higher average merchant volumes and lower merchant counts than horizontal platforms at the same total GMV. A vertical platform with 300 merchants processing $200K each has $60M in volume. A horizontal platform might need 2,000 merchants to reach the same number.

This means vertical platforms hit PayFac-as-a-Service economic thresholds sooner — with fewer merchants generating more concentrated volume. The operational burden is also lower because merchant profiles are homogeneous. Underwriting 300 similar businesses is simpler than underwriting 2,000 diverse ones.

If you're a vertical platform above $30M in merchant volume, you should be actively evaluating the transition from referral to PayFac-as-a-Service. The economics are likely already compelling.

Pricing Strategy for Vertical Markets

Vertical platforms have a pricing advantage that most don't exploit: you know your merchants' margins, transaction sizes, and payment cost tolerance better than anyone.

Generic payment pricing (2.9% + $0.30) was designed for horizontal platforms that can't predict what their merchants look like. You can do better. Industry-specific pricing — whether that's a lower flat rate for high-volume merchants, a bundled price that includes payment processing in the software subscription, or tiered pricing based on volume — signals that you understand the business.

Bundled pricing is particularly powerful for vertical SaaS. Instead of charging software fees and payment processing as separate line items, you roll payments into the subscription at a price point that's competitive with standalone processing. The merchant sees one bill instead of two. You capture payments revenue that might otherwise go to a competitor. And you create structural switching costs that protect both revenue streams.

The Activation Challenge in Vertical Markets

Vertical platforms face a specific activation dynamic: your merchants are often small businesses with an existing processor relationship and a high threshold for switching.

The standard activation approach — send an email, offer a lower rate, hope for conversions — works poorly in verticals where merchants have been using the same processor for years and the payment amount is a small fraction of their overall business costs.

What works instead is workflow-native activation. Identify the specific moment in your product where the merchant's current payment setup creates friction — manual reconciliation, split reporting, delayed deposits, separate logins — and surface the embedded option exactly there. Not as a marketing message. As a product experience.

The platforms with the highest activation rates in vertical markets got there by solving a workflow problem, not by offering a lower rate. The rate gets them to listen. The workflow improvement gets them to switch.

Competitive Dynamics to Watch

Vertical SaaS markets are increasingly attracting payments-first competitors. These are companies that start with payment processing and build vertical software around it — approaching the market from the opposite direction. Toast in restaurants, ServiceTitan in home services, and Mindbody in fitness are examples of platforms that have made embedded payments a core part of their value proposition and competitive moat.

This trend is most advanced in restaurants, retail, and health and wellness — verticals where payment volume is high and transaction frequency creates strong data advantages. Square and Clover both started as payments-first platforms and have expanded into vertical software that competes directly with established SaaS players. It's expanding into field service, property management, legal, veterinary, and other verticals where embedded fintech is the next competitive frontier.

If you're a vertical platform without a payments strategy, this is the risk: a competitor builds a payment-native platform in your vertical and uses payments economics to subsidize the software — the same playbook Toast used to disrupt legacy restaurant POS vendors and Square used to enter appointment-based verticals. They offer a lower software price because they're making their real margin on transactions. Your merchants start evaluating the switch not because the software is better, but because the total cost of ownership is lower.

The best defense is offense. Build your payments program before a payments-first competitor builds your software.

In vertical markets, payments isn't a feature. It's a competitive moat — but only if you build it before someone else does.

The Margin Multiplier can show you what your merchant volume is worth under each monetization model. If you haven't run the numbers yet, that's the first step. If you want to think through what the model transition looks like for your specific vertical, that's what the advisory engagement is built for.

This article was originally published on Margin Labs.

The problem isn't that platforms choose bad providers. The problem is that most evaluations focus on the wrong things. Rate sheets and feature lists are table stakes. The questions that actually determine whether a payments partnership works are harder to ask and harder to compare — but they're the ones that matter 18 months in.

Here are the eight questions we use when evaluating embedded payments providers for our advisory clients.

1. What Is the Full Cost Stack — Not Just the Headline Rate?

Every provider will quote you a rate. Interchange-plus pricing, flat rate, or a blended rate — the headline number is designed to be comparable. It's also designed to be incomplete.

The full cost stack includes interchange (non-negotiable, set by card networks), the processor markup above interchange, per-transaction fees, monthly platform fees, PCI compliance fees, chargeback fees, batch settlement fees, and sometimes gateway fees on top of processing fees. Stripe Connect, for example, charges a platform fee on top of standard processing. Adyen for Platforms bundles differently than Finix or Tilled. Traditional processors like Fiserv and Global Payments itemize more aggressively. Some providers bundle these. Others itemize them. The ones who bundle are usually hiding the most margin.

Ask for a complete cost breakdown on a sample month of transactions — not a rate card. Provide your actual merchant mix (average ticket size, card-present vs. card-not-present, debit vs. credit split) and ask them to model the effective cost. If they won't do this, they know the answer isn't favorable.

2. Who Owns the Merchant Relationship?

This is the single most consequential question in any payments partnership, and most platforms don't ask it directly enough.

In some arrangements, the processor owns the merchant relationship. They can contact your merchants directly, market to them, and — in some cases — migrate them to another platform's integration. In others, you own the merchant relationship and the processor is an infrastructure provider behind the scenes.

The answer determines your competitive exposure. If the processor can see your merchant data, understand your vertical, and reach your merchants directly, you've handed them a map to compete with you or to sell that intelligence to someone who will. Ask specifically: can the processor market directly to merchants boarded through your integration? What data do they retain? What happens to the merchant relationship if you terminate the agreement?

3. What Does the Migration Path Look Like?

Your payments strategy will evolve. You might start in ISV Referral with Fiserv or Global Payments and move to PayFac-as-a-Service through Finix, Tilled, or Payrix. You might outgrow a managed PayFac provider and want to register directly. You might simply want to switch processors because the economics no longer work.

Before you sign, understand what migration looks like. Some providers make it straightforward — they'll export your merchant portfolio, provide a transition timeline, and cooperate with the receiving processor. Others make it deliberately painful. Merchant data is locked, re-boarding is required from scratch, and the contractual exit terms include volume commitments or early termination fees that make switching economically irrational.

Ask for the specific migration process in writing. If the answer is vague or the contract includes a long exclusivity period with steep exit penalties, factor that into your evaluation — because you're not just choosing a provider, you're choosing how hard it will be to leave.

4. What Is the Merchant Onboarding Experience?

The boarding experience is the first thing your merchants see of your payments program. If it's clunky, slow, or requires information they don't understand, you'll lose merchants before they process a single transaction.

Evaluate the provider's boarding flow from the merchant's perspective. How many fields? How long does approval take? Is there a sandbox you can test? Does it support progressive boarding — where merchants can start processing before full KYC is complete? Can you customize the flow, or are you locked into their standard form?

The providers with the best boarding experiences have invested in pre-fill, real-time verification, and instant approval for low-risk merchants. The ones with the worst experiences are the ones that built compliance-first and never came back to fix the UX.

5. What Happens When Something Goes Wrong?

Payments problems are urgent. When a merchant's deposit doesn't arrive, or a transaction is declined incorrectly, or a chargeback is filed, the clock is ticking. Your merchant isn't going to wait 48 hours for an email response from a support queue.

Ask about support SLAs — not the marketing version, the contractual version. What is the guaranteed response time for critical issues? Is there a dedicated support contact for your integration, or are you in the general queue? Can your team access the provider's internal tools to troubleshoot, or do you have to relay everything through their support team?

The best providers give you direct access to a dashboard where your team can investigate deposit timing, transaction status, and chargeback details without opening a ticket. The worst ones make you a middleman between your merchants and their support team.

6. How Mature Is the API and Developer Documentation?

If your engineering team is going to build against this API for the next 3-5 years, the quality of the developer experience matters more than any feature on the marketing site. Stripe Connect and Adyen for Platforms are widely regarded for developer documentation; newer PFaaS providers like Finix and Tilled have invested heavily in catching up. Enterprise gateways like FreedomPay tend to have more complex integration requirements.

Look at the documentation before the sales process, not after. Is it public? Is it complete? Are there working code examples in your stack? Is there a sandbox environment you can test against without signing a contract? How frequently does the API change, and how much notice do they give before breaking changes?

Talk to other platforms who have integrated with this provider — not the references the sales team gives you, but platforms you find independently. Ask them about the integration timeline versus what was quoted, the quality of technical support during the build, and the stability of the API post-launch.

7. What Are the Contract Terms That Will Hurt You Later?

Five contract clauses that platforms consistently overlook:

• Auto-renewal: Most agreements auto-renew for 2-3 years with a 90-day notice window. Miss the window and you're locked in at the original terms even if your volume has tripled.
• Volume commitments: Some providers require minimum processing volumes. If you don't hit them, the rate changes or penalties apply. Push back on these, especially if you're early-stage.
• Exclusivity: Some agreements require all merchants boarded through your platform to process exclusively with that provider. This limits your ability to offer merchant choice or add a second processor.
• Rate escalation: Check whether rates are fixed for the contract term or whether the provider can adjust them with notice. "With 30 days' notice" means your economics can change at any time.
• Data ownership: Who owns the transaction data and merchant information after termination? If the provider retains it, they retain leverage.

None of these are deal-breakers on their own. All of them are negotiable. But you have to know they're there to negotiate them.

8. Does This Provider's Roadmap Align with Yours?

The payments landscape is evolving. Real-time payments, A2A (account-to-account) transfers, embedded lending, and card issuing are all becoming part of the embedded finance stack. Your provider today might not have the capabilities you need in two years.

Ask about their product roadmap. Not the slide deck version — the real version. Are they investing in the capabilities that matter for your vertical? Do they have a track record of shipping what they promise? Are they building for platforms like yours, or are you a secondary use case for a provider that primarily serves enterprise merchants?

A provider that is perfectly adequate today but has no roadmap alignment with your needs will become the provider you're migrating away from in 24 months — and by then, the migration cost is real.

The Evaluation That Matters

Rate comparisons are necessary but insufficient. The providers who quote the best rate are often the ones who make it up in hidden fees, restrictive contracts, or poor support. The providers with slightly higher rates but better APIs, clearer migration paths, and genuine support infrastructure are almost always the better long-term partners.

The best payments partnerships are the ones where the economics improve as you grow. The worst ones are the ones where the contract prevents you from capturing that improvement.

If you're evaluating providers and want an independent assessment of proposals you've received, that's one of the most common use cases for a Margin Labs Quick Start Call. We review processor proposals, identify the contract terms that matter, and help you compare options without vendor bias.

This article was originally published on Margin Labs.

If you run product, finance, or partnerships at a software company and you're trying to figure out what payment facilitation actually means for your business, this is the plain-language version. No jargon ladders. No sales positioning disguised as education.

The Basic Concept

A Payment Facilitator is an entity registered with the card networks (Visa, Mastercard) that is authorized to board merchants under its own merchant identification number (MID) and process payments on their behalf.

In plain terms: instead of each of your merchants getting their own individual merchant account with a processor — which involves separate applications, separate underwriting, and separate agreements — a PayFac aggregates merchants under one umbrella. Your merchants become "sub-merchants" under the PayFac's master account.

This matters for software companies because it changes the economics. When a processor gives each of your merchants their own account, the processor owns the relationship and keeps most of the margin. When merchants are aggregated under a PayFac structure, the PayFac — which could be you, or a service you use — controls the pricing and keeps a larger share.

Why It Exists

Before the PayFac model, getting a merchant account was slow and painful. Every business that wanted to accept card payments had to apply individually, go through underwriting, wait days or weeks for approval, and sign a direct agreement with a processor. For a software platform trying to enable payments for hundreds or thousands of small businesses, this was a dealbreaker.

The PayFac model was created to solve this. By allowing one entity to aggregate merchants and take responsibility for their risk, the card networks enabled faster boarding, simpler onboarding, and a better merchant experience. Square was one of the first companies to popularize this model at scale — every small business swiping through a Square reader is a sub-merchant under Square's PayFac registration.

For vertical SaaS platforms, the PayFac model unlocked the ability to embed payments into their product and participate in the economics — not just connect merchants to a processor and collect a referral fee.

The Spectrum of Payment Facilitation

This is where the terminology gets muddy. "Payment facilitator" describes a spectrum of arrangements, not a single model. Here's how to think about it:

Full / Direct PayFac

You register directly with Visa and Mastercard as a Payment Facilitator. You get your own MID, you underwrite merchants yourself, you manage compliance and reporting to the card networks, and you handle settlement. You buy processing at wholesale rates from a sponsor bank and keep maximum margin.

This is the most control and the best economics — net margins of 50 to 100+ basis points on volume. It's also the most expensive and complex to set up: $500K to $2M+ in implementation, 12-18 months to launch, and ongoing compliance obligations that require dedicated staff.

Full PayFac makes sense at $100M+ in annual processing volume. Below that, the infrastructure cost outweighs the economic benefit.

Managed PayFac / PayFac-as-a-Service

A registered PayFac provides the infrastructure — sponsor bank relationships, card network registrations, compliance frameworks — and you operate as a partner under their umbrella. You handle merchant-facing operations (onboarding, pricing, first-line support) and they handle the regulatory layer.

You're not registered with the card networks yourself. But you set merchant rates, control the boarding experience, and keep the spread between what you charge and what you pay the provider. Net margins typically range from 25 to 70 basis points.

This model — sometimes called PayFac Lite — is the fastest-growing segment in embedded payments because it gives platforms PayFac-level economics without PayFac-level infrastructure requirements. Implementation costs range from $50K to $200K, and you can be live in 3-6 months.

ISV Referral (Not PayFac)

For comparison: in an ISV Referral arrangement, you're not a PayFac at all. You refer merchants to a processor, the processor boards and underwrites them, and you collect a residual — typically 5 to 25 basis points. You don't control pricing, you don't own the merchant relationship in payments terms, and your economics are a fraction of what a PayFac arrangement would produce.

Referral is the right starting point for many platforms, but it's important to understand that it is fundamentally different from payment facilitation — even though some processors blur the line in their marketing.

What a PayFac Is Responsible For

Whether you're a full PayFac or operating under a managed PayFac arrangement, someone is carrying these responsibilities. Understanding them helps you evaluate what you're taking on versus what your provider handles:

• Merchant underwriting: Evaluating each merchant's risk profile before allowing them to process. This includes identity verification (KYC), business verification, and risk assessment based on industry, volume, and transaction patterns.
• Transaction monitoring: Watching for suspicious activity, unusual volume spikes, and potential fraud — both to protect your merchants and to meet your obligations to the card networks.
• Chargeback management: Handling disputes when a cardholder contests a transaction. The PayFac is the first responder and carries financial exposure if chargebacks exceed network thresholds.
• Settlement and funding: Managing the flow of money from card networks to your merchants' bank accounts, including holding reserves where required.
• Compliance reporting: Filing regular reports with the card networks and your sponsor bank, including transaction volumes, chargeback rates, and risk metrics.
• PCI compliance: Maintaining PCI DSS compliance at a level appropriate for your processing volume — which in the case of a full PayFac means Level 1, the highest standard.

In a managed PayFac arrangement, the provider handles most of the compliance and regulatory reporting. You handle merchant onboarding, first-line support, and pricing. The split varies by provider, and understanding exactly who owns what is critical before you sign.

The Economics in Simple Terms

Here's why payment facilitation matters financially. On a $100 credit card transaction at a merchant rate of 2.75%:

The merchant pays $2.75. Interchange (paid to the card-issuing bank) might be $1.70. The card network takes about $0.02. Your processing cost (interchange + processor markup) might be $1.85. You keep the remaining $0.90.

That $0.90 on a single transaction doesn't sound transformative. But multiply it across $50 million in annual volume at roughly the same margin, and you're looking at $300,000 to $450,000 in annual net payments revenue. In an ISV Referral arrangement on the same volume, you'd earn $25,000 to $125,000.

The difference — $175,000 to $325,000 per year on $50M in volume — is why the PayFac model exists for software companies. And that gap widens every year as your volume grows.

Common Misconceptions

"We need to become a PayFac." Maybe. But for most platforms between $30M and $200M in volume, a managed PayFac arrangement gives you 60-80% of the economics at 20-30% of the complexity. Full registration is the end state, not the starting point.

"PayFac means we're a payments company now." No. It means you're monetizing the payments flowing through your platform. You're still a software company. The payments program is a revenue line, not a pivot.

"It's too complex for our team." A managed PayFac provider handles the regulatory complexity. Your operational addition is merchant onboarding, basic support, and chargeback response — which at most platforms translates to 0.5 to 1.5 FTEs depending on merchant count.

"We should wait until we have more volume." The threshold is lower than most teams assume. At $30-50M in annual volume with 150+ merchants, the economics of managed PayFac typically justify the move. The Margin Multiplier can show you the specific numbers for your volume.

Where to Go from Here

If you're trying to decide whether payment facilitation makes sense for your platform, start with two questions:

1. What is your annual merchant payment volume? If you don't know, estimate it: merchant count times average monthly volume times 12.
2. What are you earning on that volume today? If the answer is nothing, or a referral residual of 5-15 basis points, there is likely a significant revenue opportunity you're not capturing.

Payment facilitation isn't about becoming a payments company. It's about capturing the economics of the payments already flowing through your software.

The Margin Multiplier models your revenue across all four monetization approaches — ISV Referral, Enhanced Residuals, PayFac Lite, and Full PayFac — in about 60 seconds. Start there, then read our comparison of PayFac vs. ISO for the full decision framework.

This article was originally published on Margin Labs.

Most platforms know payments is a revenue opportunity. Fewer can explain how the money actually flows. This article breaks down the four models, the economics of each, and the thresholds where each one starts to make sense.

Model 1: ISV Referral

The simplest path. You partner with a payment processor, embed their acceptance tools in your product, and earn a residual on merchant volume. The processor handles everything — underwriting, compliance, settlement, support.

Your revenue: 5 to 25 basis points on gross merchant volume. On a platform with 200 merchants processing $150K each ($30M annual volume), that's $15K to $75K per year. It's low-touch, low-risk, and you can be live in weeks.

The ceiling is real. You don't control merchant pricing, you don't own the processing relationship, and your share of the margin is typically 15–25% of the total payment economics. But for platforms under $50M in volume, the simplicity is worth it.

Model 2: Gateway / Enhanced Residuals

A step up from basic referral. You partner with a gateway provider or negotiate enhanced terms with a processor that give you a larger share of the payment margin. You may take on some merchant-facing responsibilities — boarding, first-line support — in exchange for improved economics.

Your revenue: 15 to 40 basis points net. On the same $30M in volume, that's $45K to $120K per year. Implementation is more involved ($25K–$75K), and you'll need at least one person who understands the payment flow. But the economics are 2–3x better than basic referral.

This model works well for platforms in the $20M to $75M volume range that want better economics without the full operational weight of payment facilitation.

Model 3: PayFac Lite / Managed PayFac

You become a sub-merchant aggregator under a registered payment facilitator. You own merchant onboarding, set merchant pricing, and keep the spread between what you charge and what you pay the processor at wholesale (interchange plus a small markup).

Your revenue: 30 to 90+ basis points net. On $30M in volume, that's $90K to $270K. On $100M, it's $300K to $900K. The economics are 4–5x better than referral at scale.

You take on merchant underwriting (within parameters), compliance monitoring, chargeback first-response, and settlement management. Implementation costs $50K to $200K, and you need operational capacity — either internal or through a managed service provider.

This is the model that changes payments from a feature into a business line. Most platforms that reach $50M+ in volume and have the operational maturity to support it should be evaluating this transition.

Model 4: Full Payment Facilitation (Direct PayFac)

You register directly with Visa and Mastercard as a Payment Facilitator. You own the full stack: underwriting, compliance, settlement, dispute management, network reporting. You buy processing at the lowest possible rate and keep maximum margin.

Your revenue: 50 to 100+ basis points net. The economics are the best available. But the cost to get here is significant: $500K to $2M+ in implementation, 12–18 months to launch, dedicated compliance and risk staff, and ongoing regulatory obligations.

This model only makes sense at $100M+ in annual volume. Most platforms that pursue full PayFac too early delay revenue by 12–18 months and burn capital that should go into the core product. It's the end state, not the starting point.

The Revenue Curve Is Not Linear

The economics of each model look like steps, not a slope. You don't gradually earn more by processing more volume under the same model. You earn meaningfully more by moving to the next model when your volume justifies it.

This is why the most important discipline in payments monetization is re-evaluating annually. The platform that was right to start in ISV Referral at $15M in volume is leaving $100K+ on the table by staying there at $60M.

The Costs Everyone Forgets

Revenue is only half the equation. Each model carries operating costs that don't appear in the vendor pitch deck:

• Merchant support: you're now first-line for payment questions. Budget 0.5 to 1.5 FTEs depending on merchant count.
• Compliance: $5K to $25K annually for PCI compliance, depending on your model and volume.
• Integration maintenance: 10–20% of your initial build cost annually. Payment APIs change, card network rules update, and edge cases surface.
• Chargeback management: in PayFac models, you carry first-response responsibility and potentially reserve exposure.

Smart operators focus on operating costs first because those determine long-run economics. Implementation costs are one-time. Operating costs are forever.

Where to Start

If you're not monetizing payments today, start by quantifying the opportunity. Take your merchant count, multiply by average monthly volume, and model the revenue under each approach.

The gap between what most platforms earn on payments and what they could earn is usually the most surprising number in any strategy conversation.

The Margin Multiplier does this calculation in about 60 seconds. It won't tell you which model to choose, but it will show you the size of the opportunity you're either capturing or leaving on the table.

This article was originally published on Margin Labs.

Most of the content explaining these models is written by companies that sell one of the two. That's a problem, because the answer isn't which model is better — it's which model matches where you are right now and how much of the payment margin you're ready to capture.

What an ISO Actually Does

An Independent Sales Organization is a registered entity that refers merchants to a payment processor. The ISO doesn't process payments itself. It acts as a distribution channel — finding merchants, boarding them onto a processor's platform, and earning a residual on the processing volume those merchants generate.

For a software company, the ISO path usually takes the form of an ISV Referral program. You partner with a processor (Fiserv, Worldpay, Global Payments, or others), embed their payment acceptance into your product via APIs, and earn a revenue share on merchant volume. The processor handles underwriting, compliance, settlement, risk management, and merchant support.

The economics are straightforward: you earn 5 to 25 basis points on gross volume, depending on the processor and your negotiating position. On $30 million in annual merchant volume, that's $15,000 to $75,000 per year. Essentially free money — you carry no operational burden and no risk exposure.

The trade-off is equally straightforward: you don't control the merchant experience, you don't own the merchant relationship in payments terms, and you're earning a fraction of the total margin on each transaction.

What a Payment Facilitator Does

A Payment Facilitator is a registered entity that aggregates merchants under its own merchant ID. Instead of referring merchants to a processor, the PayFac boards merchants as sub-merchants, underwrites them (within parameters set by the acquiring bank and card networks), manages compliance, handles disputes, and processes payments on their behalf.

The PayFac owns more of the stack — and earns more of the economics. Instead of collecting a residual, you set the merchant rate, buy processing at wholesale (interchange plus a processor spread), and keep the difference. Net margins typically range from 30 to 90+ basis points depending on volume, vertical, and how you've structured your pricing.

On that same $30 million in volume, PayFac economics produce $90,000 to $270,000 in annual net revenue. The ceiling is meaningfully higher.

The trade-off: you're now responsible for merchant onboarding, KYC/AML compliance, transaction monitoring, reserve management, chargeback response, and regulatory reporting. You need staff — or a managed service provider — who understands payment operations. Implementation costs range from $50K for managed PayFac services to $500K+ for a full direct registration.

The Economic Comparison

The math is simple but often ignored. Here's a side-by-side at three volume levels:

At $10M annual volume: ISO earns $5K–$25K. PayFac earns $30K–$90K.
At $50M annual volume: ISO earns $25K–$125K. PayFac earns $150K–$450K.
At $100M annual volume: ISO earns $50K–$250K. PayFac earns $300K–$900K.

The gap widens with every dollar of volume. At smaller scales, the ISO model is efficient — you're earning revenue with no operational cost. As volume grows, the opportunity cost of staying in ISO becomes the dominant factor.

When to Choose the ISO / Referral Path

The ISO model is right when your payments volume is under $30–50 million annually, you have fewer than 200 merchants processing, your team has no payments operations experience, or you're early enough in your product lifecycle that payments is a feature, not a business line.

It's also the right choice if your vertical carries elevated risk — high average ticket sizes, high chargeback rates, or regulatory complexity. In those cases, letting the processor carry the risk exposure is worth the economic trade-off.

The ISO model lets you generate payments revenue in weeks rather than months, with minimal implementation cost and zero ongoing operational burden. For many platforms, this is the correct starting point.

When to Choose the PayFac Path

PayFac economics become compelling when your annual merchant volume exceeds $50 million and is growing, you have 150+ merchants processing consistently, you can staff at least one person who understands payment operations (or you're willing to use a managed PayFac service), and the checkout and payment experience is core to your product differentiation.

The managed PayFac model — sometimes called PayFac-as-a-Service or PayFac Lite — has made this path accessible to platforms that previously couldn't afford or staff a full PayFac registration. You get most of the economics with a fraction of the operational burden.

The Migration Question

Can you start as an ISO and move to PayFac later? Yes. Many platforms do. The transition involves re-boarding merchants under new agreements, which creates some operational friction and occasional churn. Plan for 3–6 months of migration work depending on merchant count.

The smart approach: if you have any visibility into your volume trajectory, choose your initial ISO partner with future migration in mind. Some processors offer a clear path from referral to their own managed PayFac program. Others make migration deliberately difficult. Ask about the migration path before you sign your first referral agreement.

The Decision That Matters More Than the Model

The most common mistake is treating ISO vs. PayFac as a permanent, binary choice rather than a stage-appropriate one. Companies get comfortable in referral programs, the residuals start to feel meaningful, and they stop evaluating whether they've crossed the threshold.

Run the math annually. The economics shift faster than most teams realize, especially in high-growth verticals where merchant count and average volume are both increasing.

The right model today should match where you are. The mistake is staying in it after you've outgrown it.

The Margin Multiplier models revenue across all four embedded payments approaches — ISV Referral, Enhanced Residuals, PayFac Lite, and Full PayFac — in about 60 seconds. Start there if you want to see where you fall.

This article was originally published on Margin Labs.

Both models work. Both generate revenue. But they are built for fundamentally different companies at fundamentally different stages. Choosing the wrong one doesn't just leave money on the table — it can create operational drag that takes years to unwind.

This article lays out the two models side by side, explains the economics of each, and gives you a practical framework for deciding which one fits where you are right now.

The Baseline: What Both Models Have in Common

Before comparing them, it's worth grounding the conversation in what's shared. Both ISV Referral and PayFac Lite involve a software company embedding payment acceptance into its platform. In both cases, merchants process transactions through your product, not through a separate payment app they found on their own.

The difference is in who owns what. How much of the payment stack is yours, how much revenue flows to you versus the processor, and how much operational responsibility you carry. That's where the models diverge sharply.

ISV Referral: The Low-Friction Entry Point

In an ISV Referral arrangement, you partner with a processor — Stripe, Fiserv, Worldpay, TSYS, and others all have formal ISV programs — and refer your merchants to them for payment processing. The processor handles underwriting, compliance, settlement, and support. You embed the payment experience into your software through APIs. When your merchants process, you collect a residual.

The Economics

Residuals in referral programs typically range from 10 to 25 basis points on gross volume, depending on the processor, your vertical, and the volume you bring. Some programs pay a flat per-transaction fee instead of or in addition to basis points.

On a merchant processing $500,000 annually, a 20-basis-point residual produces $1,000 per year per merchant. With 200 merchants on payments, that's $200,000 in annual recurring revenue — essentially pure margin, since you're not carrying any payments infrastructure.

The ceiling, however, is real. You don't own the rate. You don't own the relationship with the processor on behalf of each merchant. And if you build volume under one processor's program, switching later is nontrivial.

What You're Giving Up

The flip side of low operational burden is limited economics. The processor is taking the majority of the margin — often 60 to 80 percent of net revenue on a transaction — because they're carrying all the risk and infrastructure. You're essentially a distribution channel, and distribution channels get distribution-channel economics.

You also don't control the merchant experience end to end. Boarding, underwriting decisions, hold policies, dispute handling — those belong to the processor. If a merchant has a problem, they may not even know you're involved. That can create friction in the customer relationship you've worked hard to build.

Referral is the right entry if you're under 200 merchants on payments or under $50M in aggregate GMV. Above that, the math starts to favor a bigger move.

PayFac Lite: More Control, More Margin, More Responsibility

PayFac-as-a-Service — sometimes called Managed PayFac or Payment Facilitator as a Service — is a model where you become a sub-merchant aggregator under a registered payment facilitator, typically a company like Stripe Connect, Adyen for Platforms, or purpose-built PFaaS providers like Finix, Tilled, or Payrix that have built managed facilitator infrastructure specifically for software platforms.

You take on merchant onboarding, underwriting decisions (within approved parameters), and the first line of support. In exchange, you own the economics more fully. Instead of collecting a residual on someone else's spread, you set the merchant rate, buy processing at a wholesale interchange-plus rate, and keep the difference.

The Economics

A typical PayFac Lite arrangement involves buying processing at something like interchange plus 10 to 15 basis points, then charging merchants 2.5 to 2.9 percent. On a $100 transaction at 2.75 percent, you collect $2.75. You pay the processor perhaps $1.85 (interchange plus your cost). You keep $0.90.

Scale that across $50 million in GMV and you're looking at roughly $450,000 in net payments revenue. In the ISV Referral model at 20 basis points, that same volume generates $100,000. The economics are four to five times better at scale — which is why the model exists.

What You're Taking On

PayFac Lite isn't free money. You're now responsible for merchant onboarding accuracy, KYC/AML compliance, reserve management, and chargeback first response. You carry reserve exposure on merchants who underperform. You need someone — internally or through a third-party service — who understands chargebacks, disputes, and the basic fraud patterns in your vertical.

None of this is unmanageable. There are platforms specifically built to handle the operations layer for PayFac Lite programs. But it is real work, and it requires more internal attention than a pure referral arrangement.

The Decision Framework

Here's how to think about the choice:

Choose ISV Referral if:

• Your payments GMV is under $30–50M annually
• You have fewer than 100–200 actively processing merchants
• Your team has no payments operations experience and no near-term plans to hire it
• You're in an early product stage and want revenue without operational complexity
• Your merchants are high-risk or in a vertical with elevated chargeback rates

Choose PayFac Lite if:

• Your payments GMV is above $50M and growing
• You have 150+ merchants processing consistently
• You can staff or contract at least one person who understands payment operations
• Checkout and post-transaction experience are core to your product differentiation
• You're in a vertical where you control the category and aren't worried about losing merchants to the processor

The Migration Question

One question that comes up constantly: can you start in ISV Referral and migrate to PayFac Lite later? Yes — and many companies do exactly that. The transition isn't painless, but it's manageable. The main challenge is merchant migration: your existing merchants are typically boarding new contracts under the new model, which means some operational friction and occasional churn.

The smarter play, if you have any foresight about your volume trajectory, is to choose your referral partner with future migration in mind. Fiserv and Global Payments both offer ISV referral programs that can transition to their managed PayFac offerings. Stripe's upgrade path from standard Connect to custom Connect is relatively well-documented. Others make migration deliberately difficult. Ask about migration paths before you sign your first referral agreement.

The One Thing Most ISVs Get Wrong

The most common mistake is treating this as a permanent choice rather than a stage-appropriate choice. Companies get comfortable in referral programs, the residuals start to feel meaningful, and they stop evaluating whether they've crossed the threshold where the economics of PayFac Lite would justify the move.

Run the math every year. At 200 merchants processing $150,000 each, you have $30 million in GMV. In referral at 20 basis points, that's $60,000 annually. In PayFac Lite at 90 basis points net, that's $270,000. The difference is $210,000 per year — and that number grows with every merchant you add.

The model you choose today should match where you are. But you should be actively managing toward where the economics get meaningfully better.

The Margin Labs Strategic Decision Framework covers every model in detail — economics, implementation costs, decision frameworks, and the math behind the margin. Get the Framework →

This article was originally published on Margin Labs.

This is not a hypothetical. It's the median outcome for ISVs that launch payments without a deliberate activation strategy. And the frustrating part is that the problem rarely has anything to do with the product. The payments feature itself is often fine. The failure is almost always upstream — in how merchants are asked to adopt it, in the friction they encounter when they try, and in the incentive structure that's asking them to change something that already works.

This article breaks down the real reasons merchants don't convert to embedded payments — not the surface-level explanations, but the structural ones — and offers a framework for addressing each.

Reason 1: They Already Have a Processor They Trust

For many of your merchants, payment processing is a solved problem. They have a relationship with a processor, a terminal they know how to use, and a rate they negotiated three years ago. It's not optimal, but it's theirs.

Asking them to switch means asking them to trust a new provider for something that touches their revenue directly. That's a high-stakes request. Processors have burned merchants before — with unexpected holds, sudden rate increases, and support teams that disappear when chargebacks spike. The merchant's instinct to stay put isn't irrational. It's pattern-matched caution from real experience.

What actually works:

Don't lead with the switch. Lead with the pain their current setup creates. Reconciliation time. Deposits that don't match invoices. Running a report in the processor's portal and another one in your software because the data doesn't sync. The pitch isn't "our payments are better." It's "you shouldn't have to manage two systems for one business."

When you make the problem concrete, the solution sells itself.

Reason 2: The Onboarding Ask Is Too Heavy

Most embedded payments onboarding flows were designed by engineers who understand KYC compliance, not by product people who understand merchant attention spans. The result is a form that asks for a business EIN, a bank account number, the last four digits of an owner's SSN, a voided check, and a photo ID — before the merchant has any idea whether the feature is worth it.

Every field you add to the boarding flow is a percentage point of drop-off. Treat it like a checkout funnel, not a compliance checklist.

Merchants abandon long boarding flows for the same reason consumers abandon shopping carts: each step is a decision point, and enough decision points eventually produce a decision to stop. The fact that your processor requires the information doesn't mean you have to collect it all at once in a single form.

What actually works:

Progressive boarding. Collect what you need to get the account open. Get them processing on a small transaction. Collect the rest as you go. Some processors support phased onboarding natively. Others require you to build it yourself. Either way, the activation lift from reducing upfront friction is consistently one of the largest levers available.

For merchants in your vertical who are lower risk, explore whether instant approval workflows are available. The difference between "you'll hear back in 2–3 business days" and "you're approved" is not incremental. It's the difference between activation and abandonment.

Reason 3: They Don't Understand What They're Signing Up For

Most merchants don't understand interchange. They don't understand what a basis point is. They definitely don't understand what "interchange plus 30 basis points" means compared to "2.75 percent flat." And they are deeply, justifiably suspicious of any payment arrangement that they don't fully understand.

The default response to confusion is inaction. If a merchant can't quickly calculate whether your rate is better than what they have today, they won't switch. Not because your rates are worse — in most cases they're not — but because they can't tell.

What actually works:

Build a simple comparison tool. Show them what they paid last month and what they would have paid with you. Not in basis points. In dollars. "Based on your volume, you would have saved $340 last month" is a message that requires no financial sophistication to evaluate.

If you don't have access to what they currently pay, ask them to input their current rate and calculate it for them. The act of building this tool forces your team to internalize the economics, which is a side benefit you'll use in every merchant conversation afterward.

Reason 4: The Sales Team Isn't Selling It

This one is uncomfortable but true. Embedded payments adoption at most ISVs correlates more closely with whether the sales team is actively promoting it than with any product attribute. And sales teams don't promote things they don't understand, don't believe in, or don't get credit for.

If payments is mentioned as a footnote at the end of a demo — "oh, and we also have payments built in" — adoption will be footnote-level. If it's framed as a core workflow solution with a clear before-and-after, adoption looks different.

What actually works:

Solve the knowledge problem first. Your sales team needs to be able to explain the economics in plain language, run a basic savings calculation on the spot, and handle the three most common objections cold. That's a training and enablement investment, not a messaging problem.

Then solve the incentive problem. If the rep gets quota credit for the software sale and nothing for payments activation, you've told them where to spend their time. Commission structures that reward payments adoption — even modestly — change behavior consistently and fast.

Reason 5: The Product Doesn't Make the Case

The final reason is the hardest to hear: sometimes merchants don't adopt because the integrated experience isn't noticeably better than what they have.

If switching to your embedded payments means they get payments in the same interface as their software — but reconciliation still requires manual effort, reports still don't cross-reference properly, and tipping or surcharging still requires a workaround — then the value proposition isn't strong enough to justify the switching cost. You've built integration, not workflow improvement.

What actually works:

Audit the post-payment experience, not just the payment acceptance experience. Where does money movement data need to go in your software? What does the merchant have to do today to reconcile a day's deposits against invoices? What's their end-of-month close process look like?

The stickiest embedded payments implementations are the ones that eliminate work the merchant was doing anyway — not just the ones that consolidate where they swipe a card. If your payments feature can close a reconciliation loop that currently requires 45 minutes of manual work, that's your pitch. Not convenience. Recovered time.

The Number That Should Keep You Up at Night

Take your current payments adoption rate. Multiply it by your average merchant GMV. That's your current payments revenue base.

Now apply that same adoption rate to your total merchant base. The gap between those two numbers is your activation opportunity — the revenue you're already entitled to, in merchants who already pay you, who already trust you enough to run their business on your software.

No new product. No new customers. Just a more deliberate approach to getting existing customers to use a feature you've already built.

That math, done honestly, is usually the most compelling thing in any payments strategy conversation. Run it before your next planning cycle.

The Margin Labs Strategic Decision Framework covers every model in detail — economics, implementation costs, decision frameworks, and the math behind the margin. Get the Framework →

This article was originally published on Margin Labs.

If you've ever tried to get a straight answer on what it costs to add embedded payments to a vertical SaaS platform, you know the experience: vague ranges, "it depends" answers, and a request to get on a call with a solutions engineer before anyone will give you real numbers.

Some of that complexity is genuine — costs do vary meaningfully based on volume, vertical, and program structure. But a lot of it is deliberate obfuscation. Payment processors and PayFac-as-a-Service providers have strong incentives to get you into a sales process before you have enough information to negotiate effectively.

This article lays out the real cost structure across all four embedded payments models. You should be able to read this and walk into any vendor conversation with a clear understanding of what you're paying for, what's negotiable, and what's a red flag.

The Two Categories of Cost

Before we get into model-specific numbers, it's worth separating embedded payments costs into two categories that often get conflated: implementation costs and ongoing operating costs. They're different decisions with different timelines and different ROI calculations.

Implementation costs are one-time or ramp-period expenses — the investment required to build the program, integrate the technology, and reach steady-state operations. Operating costs are ongoing — the fees, splits, and costs that repeat every month as long as the program is running.

Most vendors lead with implementation costs because those are the scariest-sounding numbers. Smart operators focus first on operating costs because those determine the long-run economics of the business.

Model 1: ISV Referral — The Low-Cost, Low-Return Option

Implementation Costs

An ISV referral arrangement has minimal implementation cost — typically $5,000 to $15,000 for basic integration work, legal review of the referral agreement, and merchant communication. You're not building payment infrastructure; you're connecting merchants to a partner's infrastructure. Processors like Fiserv, Global Payments, and Worldpay all have standard ISV referral programs with well-documented APIs.

Ongoing Costs

There are essentially no ongoing costs in a referral model. You're receiving a share of the economics the processor earns. If volume drops, your revenue drops but so does your cost basis — there's no fixed cost structure to worry about.

The Real Cost

The real cost of the ISV referral model isn't a line item — it's opportunity cost. You're trading long-run economics for short-run simplicity. At meaningful volume, the difference between referral economics (5–15 basis points) and PayFac-lite economics (15–40 basis points) compounds into a significant gap.

Model 2: Gateway Integration / Enhanced Residuals

Implementation Costs: $20,000–$75,000

The primary implementation costs in a gateway model are engineering time and integration work. If you're using a well-documented gateway API, a competent engineering team can complete the integration in 4 to 12 weeks. At typical fully-loaded engineering costs, that's $20,000 to $60,000 in internal labor.

Add legal review of the gateway agreement ($2,000–$5,000) and any UX/design work for the payment flow, and total implementation cost typically lands in the $25,000–$75,000 range.

Ongoing Costs

Gateway models have three ongoing cost components. First, the gateway fee itself: usually $0.05–$0.15 per transaction, or a small monthly platform fee. Second, passthrough costs from the card networks — these run 0.10%–0.14% of volume and can't be negotiated. Third, your processor spread — the margin your processor earns above interchange. This is your primary negotiating lever.

The processor spread is where you need to pay close attention. A spread of 15 basis points on $30M in volume costs you $45,000 per year. A spread of 25 basis points on the same volume costs you $75,000. That $30,000 annual difference is entirely negotiable, and most platforms either don't negotiate it or don't go back to renegotiate as their volume grows.

What's Negotiable

In a gateway model, the processor spread is your primary negotiating lever. Passthrough costs aren't negotiable (they're set by Visa and Mastercard). Gateway transaction fees have some flexibility but less than the spread. If your volume has grown meaningfully since you signed your agreement, you should be renegotiating.

Model 3: PayFac-Lite (Sponsored PayFac)

Implementation Costs: $50,000–$200,000

PayFac-lite is where implementation costs start to get serious — but also where the economics justify them. The major cost components are:

• Engineering integration: Your team needs to build merchant onboarding flows, handle KYC/KYB data collection, integrate with your PayFac-as-a-Service provider's API, and build the settlement and reporting infrastructure. Plan for 3–6 months of engineering work, which translates to $40,000–$150,000 depending on your team's cost structure and the complexity of your existing platform.
• Compliance and legal: You'll need a legal review of the sub-merchant agreement you'll present to merchants, compliance review of your KYC flows, and ongoing monitoring obligations. Budget $10,000–$30,000 for initial setup.
• Reserve requirements: Most PayFac-as-a-Service providers require a cash reserve — typically $25,000–$100,000 depending on your volume profile. This isn't a cost per se, but it's capital you need to have available.

Ongoing Costs

The ongoing cost structure in a PayFac-lite model is more complex than a gateway model. You're paying your PayFac-as-a-Service provider a platform fee (usually $500–$2,000/month), a per-transaction processing fee, and a share of the net economics. The economics you retain depend heavily on how your agreement is structured.

A typical PayFac-lite economics structure: the provider earns 40–60% of the net spread above passthrough costs, and you retain 40–60%. On $50M in annual volume with a net spread of 40 basis points, that's $200,000 gross margin to split. Your share — at a 50/50 split — is $100,000 per year.

This is also where chargeback costs matter. In a PayFac-lite model, you share in the chargeback liability. Depending on how the agreement is structured, you may absorb losses above a certain threshold. Understand this clearly before you sign.

What's Negotiable

The economics split between you and the PayFac-as-a-Service provider is negotiable — and your negotiating leverage increases with volume. If you're bringing $20M+ in volume to a provider, you should be negotiating for a more favorable split than their standard terms. Stripe Connect charges 0.25% + $0.25 per transaction on top of standard processing fees — a known quantity but less negotiable. PFaaS providers like Finix and Tilled typically charge interchange plus 10–20 bps, with pricing flexibility at meaningful volume levels. Payrix offers similar flexibility.

Model 4: Direct PayFac

Implementation Costs: $500,000–$2,000,000+

Direct PayFac is in a different cost category entirely. The primary cost components are: registration fees with Visa and Mastercard ($5,000–$10,000), dedicated payments engineering (typically 2–4 full-time engineers for 18–24 months), legal and compliance infrastructure, underwriting and risk systems, and reserves capital.

When you add it all up — internal labor, systems, legal, compliance, and reserve requirements — most platforms building a Direct PayFac from scratch spend $500,000 to $2M before they reach steady-state operations.

Ongoing Costs

The ongoing cost structure for a direct PayFac is essentially that of running a small financial services business: payments operations staff, compliance monitoring, risk management, chargeback handling, and the ongoing cost of regulatory relationships.

The reason platforms build to Direct PayFac despite these costs is that the economics are proportionally larger. On $200M in annual volume, the difference between a PayFac-lite take rate of 25 basis points and a Direct PayFac take rate of 60 basis points is $700,000 per year. At that scale, the investment pays back.

Who Should Actually Do This

Direct PayFac is the right answer for a narrow set of platforms: those with $100M or more in annual payment volume, strong technical teams, and the organizational capacity to run a payments business alongside a software business. For everyone else, the math almost never works.

We see early-stage platforms pursue Direct PayFac because it sounds like the most serious, most sophisticated option. That's usually a mistake that delays revenue by 18 months and consumes capital that could have been deployed in the core product.

The Hidden Costs Everyone Forgets

Beyond the model-specific costs above, there are recurring costs that apply regardless of which path you choose — and they're almost always underestimated in initial business cases.

Merchant Support

When you embed payments, you become the first line of support for payment-related questions. How long does a settlement take? Why was this transaction declined? What do I do about this chargeback? Your current support team isn't trained for this, and payment support tickets are higher-effort than typical software support tickets. Budget for training and potentially for headcount.

Compliance Overhead

PCI DSS compliance costs money — security scans, annual assessments, potential pen testing. At the gateway level, you're mostly protected by your processor's compliance posture, but you still have obligations. At the PayFac-lite level, you're taking on more compliance responsibility. Budget $5,000–$25,000 annually depending on your volume and risk profile.

Integration Maintenance

Payment APIs change. New card brands get added. Regulations update. The ongoing engineering cost of maintaining a payments integration isn't zero — it's typically 10–20% of the original build cost per year. Factor this into your ROI model.

How to Think About the ROI

The right way to evaluate embedded payments cost is not "can we afford to build this" but "what is the payback period relative to the annual revenue opportunity."

A gateway integration that costs $50,000 to build and generates $80,000 in net annual payment revenue pays back in about 7 months. After that, it's essentially pure margin on existing volume. That's a strong business case.

A PayFac-lite program that costs $150,000 to implement and generates $200,000 in net annual revenue at steady state has a similar profile. The implementation looks expensive until you model the 5-year return.

The programs that don't have good ROI are the ones where the implementation cost is out of proportion to the volume — usually because the platform tried to build too sophisticated a program too early, or because they signed a processor agreement with economics that were too favorable to the provider.

This article was originally published on Margin Labs.

If you've ever looked at a payments settlement report and felt like you were reading a foreign language, you're not alone. The payments industry has a talent for complexity — multiple fee types, passthrough costs, residual splits, interchange categories — and most of the people who built these revenue streams weren't thinking about how a CFO would want to see them on a P&L.

But if you're running a vertical SaaS business with embedded payments, or evaluating whether to add them, understanding how to read a payments P&L isn't optional. It's the difference between knowing whether your payments program is actually working and just assuming it is because the deposits keep showing up.

This is the framework we use at Margin Labs when we assess a platform's payments health. Walk through it once and you'll never look at a settlement report the same way again.

Start With Gross Volume, Not Revenue

The first number most people focus on is the revenue line. That's a mistake. Start with gross payment volume — the total dollar amount of transactions processed through your platform in a given period.

Gross volume is your raw material. Everything else is derived from it. A platform processing $40M in annual volume has a fundamentally different business than one processing $4M, even if their ARR is identical. Volume is the asset. Revenue is just one expression of how you've chosen to monetize it.

Once you have gross volume, the next question is: what percentage of your merchants are actually using your embedded payments solution? This is your attachment rate, and it tells you two things at once — how much of the opportunity you've already captured, and how much upside is still sitting in your installed base.

Volume is the asset. Revenue is just one expression of how you've chosen to monetize it.

A platform with 70% attachment is in a very different conversation than one at 30%, even if they report similar payment revenue. The first has a mature program. The second has a significant growth opportunity — or a product or pricing problem they haven't diagnosed yet.

The Three Layers of Payments Revenue

Once you understand your volume, you need to understand where your revenue is actually coming from. Payments revenue almost always has three layers, and conflating them creates blind spots.

1. Net Interchange

Interchange is the fee paid by the merchant's bank to the cardholder's bank on every transaction. For most payment programs, interchange is the largest component of gross revenue. But you never keep all of it.

Your net interchange is what's left after your processor takes their cut and after passthrough costs — primarily card network fees from Visa, Mastercard, and others — are deducted. For most vertical SaaS platforms operating under a sponsored PayFac model, net interchange lands somewhere between 0.15% and 0.40% of volume, depending on the industry, average ticket size, and how the program was structured.

If your settlement reports show gross interchange without clearly breaking out passthrough costs, you're flying blind. You might think your take rate is healthy when the real number is significantly lower.

2. Processing Fees

In addition to interchange, most payment programs charge a flat per-transaction fee or a small basis point adder on top of interchange. This is where the economics get interesting.

Processing fees are more predictable than interchange because they don't vary by card type. A $0.20 per-transaction fee on 50,000 monthly transactions is $10,000 in highly reliable monthly revenue — essentially an annuity. For platforms with high transaction frequency but low average ticket, this can be the dominant revenue line.

3. Ancillary Revenue

The third layer includes everything else: chargeback fees, monthly account fees, hardware margins, next-day funding premiums, international transaction fees. These are often the highest-margin items in a payments P&L because they carry minimal incremental cost.

They're also the easiest to miss in aggregate reporting. If you're only looking at a top-line payments revenue number, you're probably undervaluing your ancillary revenue and making it harder to diagnose where margin is actually being created or lost.

The Number That Actually Matters: Net Take Rate

All three of those revenue layers collapse into one number that tells you the most about the health of your payments program: your net take rate.

Net take rate is your total payments revenue — after all costs — divided by gross payment volume. It's expressed in basis points (one basis point = 0.01%).

Why does this matter so much? Because it's the only way to compare your payments program to benchmarks, to evaluate the impact of program changes, and to model the value of your payments business in an acquisition or investment conversation.

A platform at 15 basis points net take rate with strong volume is a very different asset than one at 30 basis points with weak volume. PE firms and strategic acquirers look at both numbers. Most founders only track one.

How to Read the Cost Side

The payments P&L isn't just about revenue. The cost structure is equally important, and it's where most programs have the most room for improvement.

There are three categories of costs to track separately.

Passthrough Costs

These are costs you can't negotiate — card network fees, dues and assessments, PCI compliance fees charged by the networks. They typically run 0.10% to 0.14% of volume depending on card mix. If your passthrough costs are materially higher than that range, you either have an unusual mix of premium cards or your processor is marking up network fees, which happens more often than most platforms realize.

Processor Fees

This is your negotiable cost layer. Your processor charges you for access to the rails, for risk management, for settlement, and for the infrastructure that makes the program run. These fees should be negotiated, benchmarked regularly, and renegotiated as your volume grows.

Many vertical SaaS platforms signed their initial processing agreements when they were small. They haven't gone back to renegotiate as volume scaled. That's usually a 3–8 basis point improvement waiting to happen.

Chargeback Losses

Chargebacks are transactions that get reversed because a cardholder disputed them. You're on the hook for the transaction amount plus a dispute fee, typically $15–$25 per occurrence. For most platforms, chargebacks run between 0.05% and 0.15% of volume. If you're above 0.20%, you have a risk management problem that's eating margin and putting your processing agreements at risk.

Benchmarks Worth Knowing

When you put this all together, here's what a healthy payments P&L looks like across the most common program structures:

These ranges aren't universal — industry vertical, average ticket size, and card mix all affect where you land. But if your numbers are materially below these ranges, you're likely either misclassifying costs or leaving significant margin on the table.

The Questions a Payments P&L Should Answer

A well-structured payments P&L should let you answer six questions without having to dig through settlement reports:

1. What is my current net take rate, and how has it trended over the past 12 months?
2. What percentage of my merchants are using embedded payments?
3. What is my payments revenue as a percentage of total ARR?
4. Where are my highest-cost transaction categories, and are they negotiable?
5. What is my chargeback rate, and is it trending in the right direction?
6. What is my total addressable payment volume across my entire merchant base?

If you can't answer all six from your current reporting, that's the first thing to fix. The data is there — it just needs to be structured so it's actually useful for decisions.

Why This Matters More Than You Think

Payments is increasingly being underwritten as a standalone business within vertical SaaS. PE firms model it separately. Acquirers pay multiples on it. Banks want to partner around it.

But none of that value creation is possible if you don't have clean, structured visibility into how the program actually performs. A payments P&L isn't just a finance exercise. It's the foundation for every strategic decision about how to grow, monetize, and eventually maximize the value of what you've built.

If you want help building one or auditing what you have, that's exactly what we do at Margin Labs.

This article was originally published on Margin Labs.

Every vertical SaaS company that processes payments on behalf of its merchants is sitting on a revenue stream it hasn't fully monetized. Not most of them — all of them.

The question isn't whether the opportunity exists. It does. The question is how large it is relative to your current business, what it would take to capture it, and whether the math is compelling enough to act on now versus later.

The Margin Multiplier is the framework we use to answer those questions quickly. It starts with a simple premise: your platform already mediates payment volume. What you do with that volume — and how you structure your relationship with the payment infrastructure underneath it — determines how much of the economics you actually capture.

Where the Name Comes From

The word "multiplier" is intentional. We're not talking about a new revenue line you have to go build from scratch. We're talking about applying a different monetization layer to volume that already exists.

Think about it this way. If you have 200 merchants on your platform, and each of those merchants processes an average of $15,000 per month in payments, you're mediating $3M in monthly volume — $36M annually. That volume exists today. Your merchants are already swiping cards, running transactions, settling funds.

The question is: who's capturing the economics of that activity?

In most cases, the answer is your payment processor. They're earning 0.20% to 0.50% on volume that flows through your software, while you're collecting a flat SaaS subscription that doesn't scale with that activity at all. The Margin Multiplier is the process of changing that equation.

The volume exists today. The question is: who's capturing the economics of that activity?

The Four Ways to Capture Payments Margin

There are exactly four models for monetizing payments as a vertical SaaS company. Every program — from a simple referral arrangement to a full payment facilitator license — fits into one of these structures. The right model for your business depends on your volume, your stage, your technical capacity, and how much you want to own the merchant relationship.

Model 1: ISV Referral

You refer your merchants to a payment processor or ISO in exchange for a revenue share on the volume they process. You don't touch the money, you don't own the merchant relationship, and you don't take on any underwriting risk. In exchange, your economics are limited — typically 5 to 15 basis points on referred volume.

This is the lowest-friction entry point. It's also the lowest-margin model, and it gives away the merchant relationship in a way that's hard to undo. We see it used most often as a starting point for early-stage platforms or as a bridge while a more sophisticated program is being built.

Model 2: Enhanced Residuals / Gateway Integration

You integrate a payment gateway or processor directly into your platform and earn enhanced residuals on transactions processed through your software. You have more control over the merchant experience than in a referral model, but the processor still owns the underwriting and risk. Take rates in this model run from 10 to 25 basis points net.

This is the most common model for mid-market vertical SaaS. It's relatively fast to implement, doesn't require specialized payments expertise, and generates meaningful recurring revenue at scale. The trade-off is a ceiling on how much margin you can ultimately capture.

Model 3: PayFac-Lite (Sponsored PayFac)

You partner with a PayFac-as-a-Service provider — companies like Finix, Payrix, or Payroc — to become a sub-merchant aggregator. You onboard merchants under your master merchant account, you own more of the customer experience, and you capture meaningfully higher economics: typically 15 to 40 basis points net after processing costs.

This is where the Margin Multiplier really starts to compound. At $50M in annual volume, the difference between a gateway model at 15 basis points and a PayFac-lite model at 30 basis points is $75,000 in incremental annual revenue — on the same volume, with the same merchants, without adding a single new customer.

Model 4: Direct PayFac

You register as a payment facilitator with Visa and Mastercard, build or buy the infrastructure to underwrite and board merchants directly, and capture the maximum available economics on your volume. Net take rates in this model run from 30 to 80 basis points, but the investment is substantial: 18 to 24 months to build, $500K or more in upfront costs, and dedicated payments engineering and compliance resources.

Direct PayFac is the right answer for platforms processing $100M or more annually that have the organizational capacity to operate a payments business alongside their software business. It's not the right answer for most companies, and pursuing it too early is one of the most common expensive mistakes we see.

How to Calculate Your Multiplier

The multiplier itself is straightforward. Take your total annual payment volume, multiply by your target net take rate for each of the four models, and compare the result to your current payments revenue (or zero, if you haven't started).

A healthy payments program typically represents 10% to 30% of ARR within 18–36 months of launch. Platforms that have operated mature programs for several years often see payments revenue approaching 50% of software ARR — or exceeding it.

The multiplier matters for a reason beyond current revenue: it affects your company's valuation. Payments revenue gets valued differently than pure SaaS subscription revenue. It's high-margin, highly predictable, and scales with merchant activity without requiring proportional headcount. Acquirers and investors know this, and they model it separately.

The Volume Underestimation Problem

Before you can calculate your multiplier, you need an accurate picture of your payment volume — and most platforms underestimate it by a significant margin.

The most common mistake is calculating volume only from merchants who are actively using your integrated payments solution. That gives you your captured volume, not your total addressable volume. The difference is the opportunity you haven't monetized yet.

Total addressable volume includes every merchant on your platform who processes payments through any method — your integration, a competing payment provider, manual methods, cash. If 40% of your merchants are using your embedded payments and 60% are using something else, your actual opportunity is 2.5x larger than what your current revenue reflects.

The second underestimation problem is growth. Payment volume grows faster than merchant count for most platforms because existing merchants tend to grow over time. A merchant who processed $8,000 per month when they first joined is probably processing more now. If you haven't refreshed your volume estimates in 12 months, you're working with stale numbers.

Why Now

The question we hear most often isn't whether to add embedded payments — most vertical SaaS operators understand the opportunity. The question is when.

The honest answer is that the cost of waiting is higher than most people appreciate. Every month you're not capturing payments economics is a month of volume that passed through your platform at a take rate of zero. That's not an abstraction — it's a real number. Take your monthly volume, multiply by 20 basis points, and that's approximately what you left on the table last month.

The implementation timeline for a gateway model is 4 to 12 weeks. For a PayFac-lite model, 3 to 6 months. These are not long projects. The delay usually isn't the build — it's the decision. And the decision gets harder to make as time passes because you've already built a merchant base that's accustomed to your current payment experience.

Take your monthly volume, multiply by 20 basis points. That's approximately what you left on the table last month.

The market has also shifted. Investors and PE sponsors now underwrite payments revenue as a core part of the vertical SaaS value proposition. It shows up in due diligence. It shows up in multiples. Platforms that have built mature payments programs command meaningfully higher valuations than those that haven't, even at identical ARR.

Where to Start

The Margin Multiplier assessment starts with three numbers: your total merchant count, your estimated monthly payment volume per merchant, and your current net take rate (if you have an existing program) or zero (if you don't).

From those three inputs, you can model what each of the four program structures would generate in annual revenue, what it would cost to build, and how long the payback period would be. That's enough to make a decision or at least to know which decisions are worth making.

If you want to run that assessment, the tool on our website will walk you through it in a few minutes. If you want a deeper analysis of what your specific program should look like — which model, which partners, which implementation sequence — that's what the Margin Labs playbook covers in detail.

This article was originally published on Margin Labs.