What are embedded payments?

Embedded payments refer to the seamless integration of payment processing capabilities directly into a non-financial software platform, app, or marketplace. Instead of redirecting users to a third-party site to pay, the software company acts as the payment facilitator, allowing users to complete transactions entirely within the platform’s native ecosystem.

Think about the last time you took an Uber. You didn’t pull out your credit card at the end of the ride, nor were you redirected to a bank’s website to authorize the charge. You simply got out of the car. The payment happened invisibly in the background. That is the power of embedded payments.

In 2026, embedded payments are no longer just for tech giants like Uber or Amazon. Software-as-a-Service (SaaS) companies, B2B platforms, and vertical marketplaces are rapidly adopting embedded finance to create frictionless user experiences and unlock massive new revenue streams.

This guide explains how embedded payments work, the different models of integration, and why software companies are rushing to become payment facilitators.

Table of Contents

  1. What are embedded payments?
  2. The Evolution of Software Payments
  3. How Embedded Payments Work (The PayFac Model)
  4. The 3 Models of Embedded Payments
  5. Why Software Companies are Embedding Payments
  6. The High-Risk Embedded Challenge
  7. Frequently Asked Questions (FAQ)

The Evolution of Software Payments

To understand embedded payments, you must understand what came before it.

  1. The Redirect Era: Early ecommerce required users to leave the merchant’s website, go to a gateway like PayPal, enter their details, and then be redirected back. It was clunky and resulted in high cart abandonment.
  2. The Integrated Era (White-Labeling): Gateways introduced APIs and iFrames. The user stayed on the merchant’s website, but the merchant still had to set up their own separate merchant account with a traditional bank. The software platform just provided the “pipes”.
  3. The Embedded Era: The software platform itself becomes the payment provider. The platform handles the onboarding, underwriting, and processing for its users, creating a completely native experience.

How Embedded Payments Work (The PayFac Model)

The engine driving the embedded payments revolution is the Payment Facilitator (PayFac) model.

In a traditional setup, if a software platform (like a gym management software) wanted its gym owners to accept payments, every single gym owner had to apply for their own merchant account through a bank—a process taking days or weeks.

Under the PayFac model, the software platform (the gym management software) applies for a “master” merchant account. The platform then has the authority to instantly underwrite and onboard its users (the gym owners) as “sub-merchants” under its master account.

The User Experience

  1. A new gym owner signs up for the software.
  2. During onboarding, they provide basic business details.
  3. The software platform instantly underwrites them in the background.
  4. The gym owner can start accepting credit cards from their members immediately, entirely within the software’s interface.

The 3 Models of Embedded Payments

Software companies have three main paths to embedding payments, depending on how much risk and operational overhead they want to take on.

1. The Referral Model (The Old Way)

The software company partners with a traditional processor (like Numus Payments or Chase). When a user needs to accept payments, the software refers them to the processor.

  • Pros: Zero risk or liability for the software company.
  • Cons: Terrible user experience (users leave the platform to apply); the software company only gets a tiny referral bounty, leaving most of the revenue on the table.

2. PayFac-as-a-Service (PFaaS) / Managed PayFac

This is the most popular model in 2026. The software company partners with a provider like Stripe Connect, Finix, or specialized high-risk PFaaS providers. The provider handles the heavy lifting (compliance, risk, payouts), but the software company controls the user experience and the pricing.

  • Pros: Excellent, native user experience; instant onboarding; the software company earns a significant share of the payment revenue.
  • Cons: The software company still relies on the provider’s underwriting rules (e.g., Stripe Connect will not allow high-risk sub-merchants).

3. Becoming a Full Registered PayFac

The software company registers directly with the card networks (Visa/Mastercard) and an acquiring bank to become a full Payment Facilitator.

  • Pros: Maximum control over underwriting; maximum revenue share (you keep almost all the markup).
  • Cons: Extremely expensive and time-consuming to set up (often $500k+ and 6-12 months); the software company assumes 100% liability for all fraud and chargebacks committed by its sub-merchants.

Why Software Companies are Embedding Payments

The shift toward embedded payments is driven by two massive incentives for software platforms:

1. Frictionless User Experience

By keeping the user entirely within their ecosystem, platforms increase conversion rates, improve customer satisfaction, and increase “stickiness” (making it harder for users to switch to a competitor).

2. Monetization (The Real Reason)

This is the game-changer. When a software company embeds payments (via PFaaS or Full PayFac), they get to set the processing rate for their users.

If the platform’s wholesale cost is 2.0% + $0.10, and they charge their users 2.9% + $0.30, the platform keeps the 0.9% + $0.20 difference on every single transaction processed through their software.

For many SaaS companies, the revenue generated from embedded payments eventually eclipses the revenue generated from their core software subscriptions.

The High-Risk Embedded Challenge

While embedded payments are booming, platforms serving high-risk industries (like telemedicine, CBD marketplaces, or high-ticket coaching platforms) face a major hurdle.

Mainstream PFaaS providers (like Stripe Connect) strictly prohibit high-risk sub-merchants. If a platform uses Stripe Connect and allows a high-risk user to onboard, Stripe will eventually shut down that user, and potentially penalize the entire platform.

Platforms serving these verticals must partner with specialized high-risk payment facilitators or orchestration platforms that understand the regulatory landscape and can underwrite high-risk sub-merchants safely.

Frequently Asked Questions (FAQ)

What is the difference between embedded payments and embedded finance?

Embedded payments are a subset of embedded finance. Embedded finance is the broader trend of integrating any financial service (lending, insurance, banking, issuing cards) into non-financial platforms.

Do I need to be PCI compliant to offer embedded payments?

Yes, but the level of compliance depends on your model. If you use a PFaaS provider and utilize their tokenization tools (like Stripe Elements), your PCI scope is minimized. If you become a Full PayFac and handle raw card data, you must undergo rigorous Level 1 PCI audits.

How long does it take to integrate embedded payments?

Using a modern PFaaS API, a development team can integrate basic embedded payments in a few weeks. Becoming a Full Registered PayFac takes 6 to 12 months of legal, compliance, and engineering work.