- Model choice, not API selection, is the real decision: referral, ISV, PayFac-as-a-service, full PayFac, and Merchant of Record each carry different margin potential, compliance burden, and onboarding friction for your sub-merchants.
- Stripe Connect is a PayFac-as-a-service product, not a category. Treating it as the default answer skips the model decision entirely and often leaves 60 to 80 basis points of payment margin on the table.
- Regulatory liability scales with control: the more of the payment flow you own, the more you earn and the more you owe regulators and processors.
- Most SaaS teams underestimate implementation effort for the middle two models (ISV and PayFac-as-a-service) and overestimate it for the outer two (referral and full PayFac).
- The rollout sequence is the same regardless of model: define flow, pick model, set up legal entity, integrate API, build onboarding, wire compliance, test end-to-end, go live.
Understanding how to embed payments in SaaS starts with a model decision, not a vendor selection. A product team chooses one of five models: referral partner, ISV (independent software vendor) program, PayFac-as-a-service, full PayFac, or Merchant of Record. Each model determines who holds the merchant account, who absorbs chargeback liability, how much margin flows to the platform, and how much compliance infrastructure the engineering team must build. The implementation sequence runs eight steps and takes four to twenty weeks depending on the model chosen.
Why “Just Use Stripe Connect” Is the Wrong Starting Point
Stripe Connect is a product, not a strategy. Choosing it before choosing a model is like choosing a database before you have drawn an entity-relationship diagram. The model decision sets your economics; the vendor decision sets your tooling.
Most SaaS teams skip straight to vendor selection because it feels concrete. The result is usually a referral-equivalent setup with PayFac-level engineering time, or a full PayFac posture with referral-level margin. Neither outcome is intentional. The five-model framework below fixes that by forcing the model choice first.
The Five Embedded Payments Models: What Each One Actually Means
Referral Partner
Your platform sends users to a payment provider and collects a small revenue share, typically a flat bounty or a thin basis-point cut on volume. You carry no merchant liability, do no underwriting, and write almost no payments code. Implementation time is measured in days. Margin is low, usually under 10 basis points on payment volume, and you have no control over the checkout or onboarding experience.
This model fits companies that want to test payment monetization without a compliance or engineering investment, or whose core product does not depend on payments being embedded in the UX.
ISV Program
An ISV (independent software vendor) program is a reseller arrangement with a payment processor. The processor underwrites merchants, holds the master merchant account, and handles chargebacks. Your platform earns a margin on the interchange and processing fees that flow through your referral volume. You get a co-branded or white-label checkout, some reporting access, and more revenue than a pure referral but less than a PayFac.
Processors like North (formerly Heartland), Fiserv, and Worldpay run mature ISV programs. You own the sub-merchant relationship commercially but not legally. That distinction matters: chargebacks hit the processor’s books, not yours, but the processor can revoke your program if your sub-merchant portfolio performs poorly.
PayFac-as-a-Service
PayFac-as-a-service is the model most SaaS teams actually want when they say “embed payments.” Your platform acts as a payment facilitator without holding a full PayFac registration. A licensed sponsor processor sits underneath and handles card network sponsorship, while you control the sub-merchant onboarding UX, the branded checkout, and a meaningful share of the payment margin. You also absorb sub-merchant chargeback liability up to a threshold defined in your agreement.
Providers like Stripe Connect (with custom accounts), Adyen for Platforms, Finix, and Payrix operate in this space. The FintechSpecs guide to PayFac-as-a-service providers covers nine vendors in detail if you are ready to evaluate specific options. Implementation takes six to sixteen weeks and requires KYC/KYB onboarding flows, webhook infrastructure, and dispute management tooling.
Full PayFac
A full PayFac registration means your company is directly registered with Visa and Mastercard as a payment facilitator. You hold the master merchant account, underwrite sub-merchants, own all chargeback liability, and keep the full margin between interchange and what you charge sub-merchants. You also need PCI DSS Level 1 compliance, a dedicated risk and compliance team, and direct card network agreements.
The registration process alone takes six to eighteen months and costs six figures in legal and certification fees before the first transaction clears. This model is for platforms processing well above $100 million in annual payment volume where the margin math justifies the overhead. Below that threshold, PayFac-as-a-service almost always pencils better.
Merchant of Record
A Merchant of Record (MoR) is structurally different from the four models above. Instead of helping your sub-merchants accept payments, an MoR accepts payments on your behalf and resells your software to end customers. The MoR holds all tax liability, handles VAT and sales tax compliance across jurisdictions, and manages refunds and chargebacks. You receive revenue net of fees.
Paddle and Lemon Squeezy are the dominant MoR options for SaaS. The FintechSpecs comparison of Stripe vs Paddle vs Lemon Squeezy vs Polar covers the trade-offs in depth. MoR is the right model if global tax compliance is your primary pain point and you sell software directly rather than building a platform where sub-merchants collect payments from their own customers.
Model Comparison: Margin, Liability, and Implementation Effort
| Model | Who Holds Merchant Account | Platform Margin on Volume | Chargeback Liability | Typical Implementation Time | Compliance Burden |
|---|---|---|---|---|---|
| Referral Partner | Payment provider | Very low (flat bounty or under 10 bps) | None | 1 to 5 days | Minimal |
| ISV Program | Processor (master merchant) | Low to moderate (10 to 40 bps typical) | Processor absorbs; portfolio risk to platform | 2 to 6 weeks | Low (processor handles underwriting) |
| PayFac-as-a-Service | Sponsor processor; platform controls sub-merchant UX | Moderate to high (40 to 80+ bps) | Platform absorbs up to contract threshold | 6 to 16 weeks | Moderate (KYC/KYB, dispute flows) |
| Full PayFac | Platform (direct card network registration) | High (full spread between interchange and platform rate) | Platform absorbs entirely | 12 to 24 months | High (PCI Level 1, network agreements, risk team) |
| Merchant of Record | MoR provider | None (net revenue model) | MoR absorbs | 1 to 3 weeks | Minimal (MoR handles tax and compliance) |
How to Pick the Right Model: The FintechSpecs Payments Fit Test
Four questions narrow the field quickly. Work through them in order; the first disqualifying answer stops the analysis.
1. Do your users need to accept payments from their own customers?
If yes, MoR is off the table. MoR applies when you sell software, not when your software users collect money. A field service management platform where plumbers invoice homeowners needs PayFac-as-a-service or full PayFac, not Paddle.
2. Is payment monetization core to your business model or incidental?
If payments are a feature your customers asked for but not a primary revenue driver, start with an ISV program. You will trade margin for speed and avoid a compliance buildout that does not yet justify its cost. If payments are expected to contribute meaningfully to platform revenue within two years, skip ISV and go straight to PayFac-as-a-service.
3. What is your annual payment volume, or your realistic projection within 18 months?
PayFac-as-a-service margin typically outweighs its implementation cost at volumes above roughly $1 million annually, though this depends heavily on your negotiated rate with the provider. Full PayFac registration costs are rarely recouped below $100 million in volume. If you are pre-revenue on payments, use a referral or ISV arrangement and revisit the model after you have real volume data.
4. What is your team’s compliance and engineering capacity?
PayFac-as-a-service requires building KYC and KYB onboarding flows, webhook handlers for dispute notifications, payout scheduling logic, and a sub-merchant dashboard. That is a real engineering project, typically four to eight weeks of focused work for a two-person team. If your team cannot absorb that in the next quarter, an ISV program buys you time without sacrificing the ability to migrate later.
What Is the ISV Model of Payments?
An ISV payments model is a reseller arrangement between a software company and a payment processor. The processor retains the master merchant account and bears primary regulatory and chargeback responsibility. The software company earns a revenue share on the payment volume its customers generate. The processor handles underwriting, compliance, and network relationships. The ISV handles the sales relationship and, in most programs, basic merchant onboarding through a co-branded portal.
The ISV model is common in vertical SaaS, particularly in industries like restaurants, healthcare, and field services, where the software company has deep customer relationships but limited appetite for payment compliance overhead. North’s ISV program and Fiserv’s Carat platform are frequently used examples in the US market. ISV programs are also easier to exit: if you outgrow the margin structure, migrating sub-merchants to a full PayFac-as-a-service setup is cleaner than unwinding a full PayFac registration.
The Eight-Step Implementation Sequence for Embedded Payments
This sequence applies regardless of model. Steps 4 and 5 vary significantly by model; the others are largely consistent.
- Define your payment flow. Map every money movement in your product: who pays whom, what triggers a payout, how refunds and disputes are handled. Document this before writing any code. Ambiguity in the flow diagram becomes a compliance gap in production.
- Select your model. Use the FintechSpecs Payments Fit Test above. Commit to a model before evaluating vendors. Vendors will try to skip this step for you; resist it.
- Set up your legal entity and banking relationships. For ISV and PayFac-as-a-service, you need a US business entity, a business bank account, and in most cases a dedicated operating account for payment funds. For full PayFac, add card network registration and a dedicated reserve account.
- Integrate the payments API. For PayFac-as-a-service providers, this means creating connected accounts (Stripe), marketplace accounts (Adyen), or equivalent constructs on your chosen platform. For ISV programs, this typically means a lighter integration: routing customers through the processor’s hosted flow.
- Build the sub-merchant onboarding flow. This is where most teams underestimate effort. A compliant onboarding flow collects business identity, beneficial ownership, bank account details, and processing history. It runs KYB and KYC checks, typically via an API like Middesk or Alloy. The FintechSpecs comparison of Alloy vs Middesk is useful here. Expect two to four weeks of frontend and backend work for a functional onboarding flow.
- Wire compliance and risk tooling. Add transaction monitoring, dispute webhooks, and payout controls. For PayFac-as-a-service, you need chargeback notification handling and a process for responding within the processor’s dispute window. The FintechSpecs list of chargeback management tools covers purpose-built options. For full PayFac, add a fraud decisioning layer and AML screening.
- Test end-to-end in sandbox. Test the full lifecycle: onboarding, payment capture, payout, refund, and dispute. Most PayFac-as-a-service providers offer sandbox environments with simulated dispute scenarios. Do not skip dispute simulation; it is the most common production failure point.
- Go live with a limited cohort. Launch to a small group of existing customers, not a public release. Watch payout timing, dispute rates, and onboarding completion rates for two to four weeks before opening to new signups.
Where Implementation Actually Breaks Down
The payment API integration is rarely the hard part. KYB onboarding completion rates are. Platforms that launch with a generic onboarding form see abandonment rates that make the payment feature commercially useless before it has a chance to perform. Three specific design decisions drive this.
First, progressive disclosure beats front-loading. Asking for beneficial ownership information on step one of a five-step onboarding flow causes drop-off. Collect the minimum needed to create the account, then prompt for the rest when the merchant hits their first payout threshold. Stripe’s Connect onboarding documentation calls this “eventually due” information collection, and it consistently improves completion rates compared to upfront collection.
Second, payout timing is a retention lever. Sub-merchants who receive their first payout within 24 hours of their first transaction retain at significantly higher rates than those waiting 5 to 7 days. If your payment provider supports next-day or same-day payout options, exposing those in the onboarding flow is worth the extra configuration. The broader problem of onboarding drop-off in fintech products is covered in the FintechSpecs teardown of why fintech onboarding flows kill conversion.
Third, dispute handling must be visible to sub-merchants. A sub-merchant who receives a chargeback notification by email, with no in-app context or one-click response path, will churn. Build a basic dispute dashboard before launch, even if it is a simple webhook-driven table with response deadlines.
How Embedded Payments Change Your Margin Profile
Consider a hypothetical vertical SaaS company processing $5 million annually across 200 sub-merchants. These are illustrative figures, not quotes from any specific provider. Under an ISV arrangement at a hypothetical 25 basis point revenue share, payment revenue adds $12,500 per year. Under PayFac-as-a-service at a hypothetical 60 basis points net of provider costs, the same volume generates $30,000. The difference is $17,500 annually, against an implementation cost that a focused team can complete in eight to twelve weeks.
At $20 million in volume, those same illustrative rates produce $50,000 versus $120,000. The PayFac-as-a-service implementation cost becomes a rounding error. This is why the model decision is an economic decision first and a technical decision second. The wider dynamics of payment monetization are covered in the FintechSpecs analysis of how fintech companies monetize payments without killing UX.
Full PayFac math works differently. If your platform negotiates directly with card networks, your cost of funds is closer to interchange plus a small network fee. The numbers below are approximations to illustrate how the spread works in practice, not a quote from any processor. On a Visa credit transaction, interchange for a card-not-present B2B transaction can be in the range of 2.20% plus $0.10 or higher. If you charge sub-merchants 2.9% plus $0.30 and your all-in processing cost lands near 2.20% plus $0.12, your margin per transaction is approximately 70 basis points plus $0.18. At $50 million in volume that spread is meaningful, but so is the compliance overhead required to operate at that level. For a broader look at how these cost structures compound, see the FintechSpecs breakdown of hidden costs killing fintech SaaS margins.
Frequently Asked Questions
What is the difference between a PayFac and an ISV for payments?
A PayFac (payment facilitator) holds a master merchant account and legally underwrites sub-merchants, taking on chargeback liability and regulatory responsibility for those accounts. An ISV (independent software vendor) is a reseller that earns a margin on payment volume but does not hold the master merchant account. The processor in an ISV program absorbs primary liability. ISV programs are faster to implement and carry less compliance burden; PayFac arrangements offer more margin and control over the sub-merchant experience.
How long does it take to add payments to a SaaS platform?
Referral and Merchant of Record arrangements take one to three weeks. ISV program integrations typically run two to six weeks. PayFac-as-a-service implementations take six to sixteen weeks depending on the complexity of the sub-merchant onboarding flow and the platform’s existing KYC and KYB infrastructure. Full PayFac registration takes twelve to twenty-four months from initial application to first live transaction. The implementation sequence is the same across models; the time difference is driven by compliance buildout, not API complexity.
Do I need PCI DSS compliance to embed payments in my SaaS product?
Yes, but the scope depends on your model. For referral, ISV, and PayFac-as-a-service arrangements where card data flows through a third-party provider’s hosted fields or SDK, most platforms qualify for SAQ A or SAQ A-EP, which are the lightest PCI DSS self-assessment tiers. You do not touch raw card data. Full PayFac operators who handle card data directly must achieve PCI DSS Level 1 compliance, which requires a Qualified Security Assessor audit and significantly more infrastructure investment.
Can a SaaS company embed credit products as well as payments?
Yes. Embedded credit (buy now, pay later terms, revenue-based advances, or working capital loans for sub-merchants) is a separate product layer built on top of or alongside embedded payments infrastructure. Providers like Parafin, Pipe, and Kanmon offer APIs that let platforms extend working capital to their sub-merchants using the payment volume data the platform already holds. This is covered in the FintechSpecs guide to embedded working capital APIs for B2B platforms. Licensing requirements for embedded credit vary by state and product structure; consult legal counsel before launching.
What is the best embedded payments provider for a seed-stage SaaS company?
For seed-stage companies, Stripe Connect (PayFac-as-a-service via custom or express accounts) or an ISV program with a regional processor are the most common starting points. Stripe offers the fastest path to a working integration, extensive documentation, and a sandbox that covers the full dispute lifecycle. ISV programs with processors like North or Fiserv trade some implementation speed for a higher revenue share on lower volumes. The right choice depends on whether payments are core to your product monetization or a supporting feature. The FintechSpecs comparison of embedded payments providers for B2B SaaS covers the field in detail.
What compliance infrastructure do I need before going live with embedded payments?
At minimum: KYC and KYB checks on sub-merchant onboarding, a dispute notification and response process, payout controls with hold logic for high-risk accounts, and basic transaction monitoring for fraud signals. For PayFac-as-a-service, your provider’s compliance framework covers card network rules, but your platform is still responsible for sub-merchant fraud that exceeds your contractual threshold. Before launch, review your provider’s acceptable use policy against your sub-merchant base. Vertical SaaS serving regulated industries (healthcare, cannabis, firearms) will face additional restrictions regardless of model.
The Decision You Are Actually Making
Embedding payments is an economics decision that happens to require engineering work. The model you choose determines your margin ceiling, your chargeback exposure, your onboarding UX, and how long it will take before the first payment dollar flows through your product. Getting the model wrong early is recoverable; migrating 500 sub-merchants from an ISV program to a PayFac-as-a-service setup is painful but doable. Starting as a full PayFac when your volume does not justify it is expensive in ways that compound for years.
The implementation sequence is knowable and finite. Eight steps, a clear order, and a specific set of integration, compliance, and UX deliverables at each stage. The part that trips most teams is not the API; it is underestimating the sub-merchant onboarding and dispute handling work, which sits mostly outside the payment provider’s SDK and mostly inside your product. Build those two surfaces with as much care as the core checkout flow, and the rest of the implementation follows a predictable path.
Once the model is chosen and implementation is underway, the next decision is which provider within that model class fits your volume, vertical, and engineering preferences. That comparison lives in the FintechSpecs list of top embedded payments providers for B2B SaaS platforms, which covers pricing structures, onboarding APIs, and dispute tooling across the major options.
