In 2025, the global embedded payment market was estimated to be just over $39 billion. But embedded payments aren’t the only way businesses can incorporate payment functionality into their software platforms; integrated payments are another option.
The difference between embedded payments and integrated payments comes down to management, and the right choice for your business depends on what role you want to play. With integrated payments, you’re a software company that connects to payments. With embedded payments, you’re a software company that offers payments. That’s a different business, with its own economics, risk, and user expectations.
Below, we’ll discuss how each model works, where they differ in practice, and what the architectural and commercial implications are for software companies that are deciding between them.
Highlights
Integrated payments connect software to payment providers via application programming interfaces (APIs), while embedded payments make payments a native part of the product.
Software companies that embed payments can earn transaction revenue on top of subscription fees, but they take on greater compliance responsibility.
The right choice depends on how central payments are to your product and how much transaction volume your users generate.
What’s the difference between embedded payments and integrated payments?
Embedded payments are payment capabilities built directly into a software product. The payment experience is part of the product itself rather than a redirect, separate checkout window, or third-party page. The end user never leaves the platform to complete a transaction.
Integrated payments connect an existing, stand-alone payment product to software through an application programming interface (API) or plug-in. The payments infrastructure belongs to the payment provider and the software company wires it in. The integration can be tight or loose: a tight integration might pass transaction data directly into a general ledger in real time, while a loose one might export a comma-separated values (CSV) file every night.
How do embedded payments and integrated payments work?
Embedded payments and integrated payments differ at the infrastructure level. Here’s how each one works.
Embedded payments
With embedded payments, the software company becomes a participant in the payment environment. There are a few different models:
Payment facilitator (payfac or PF): The software company onboards its users as submerchants, takes on some compliance responsibilities, and earns a share of transaction revenue.
Payfac-as-a-service (PFaaS): In this model, the software company gets the commercial benefits of facilitating payments with less regulatory burden than if it registered directly as a payfac.
White-labeled payfac: The payment experience uses the same branding as the software product, with the underlying provider invisible to the end user.
Integrated payments
Integrated payments work through standard API connections. Your software sends a request to a payment provider’s API and the provider handles everything downstream, including authorization, settlement, and compliance. You get a response back and display the result to your user. The payment provider owns the merchant account, manages the banking relationships, and handles the regulatory obligations. Your software is the frontend; its infrastructure is everything else.
Some tools combine the benefits of different models. For example, Stripe Connect can handle the complexity of multiparty money movement so software companies can embed payments without building financial infrastructure from scratch, and it can provide white labeling capabilities, too.
When should you pick embedded payments vs. integrated payments?
The clearest way to see the difference between embedded payments and integrated payments is to put them side by side. Understanding how they compare can help you decide which option is right for you.
|
|
Embedded payments
|
Integrated payments
|
|---|---|---|
| Where payments live | Inside the software platform | Connected to the software via API |
| Who owns the user experience | The platform developer | The payment provider |
| Revenue model | Transaction fees or shares on top of other revenue | Primarily sales, subscriptions, licenses, and ads |
| Merchant of record | Often the platform or its submerchants | The platform user (i.e., seller) |
| Compliance obligations | Shared or held by the platform | Held by the payment provider |
| Best for | Vertical software-as-a-service (SaaS), marketplaces, and platforms with high transaction volumes | Businesses that connect existing tools |
What does embedded payments vs. integrated payments mean for your product architecture?
Choosing between embedded payments and integrated payments has consequences that extend beyond the initial product build. The payment system you choose shapes your compliance obligations, support model, and revenue structure.
With integrated payments, you’re making API calls to a payment provider and handling the responses. Your team needs to understand the provider’s API, manage webhooks, and build the right error handling, but you’re not responsible for what happens inside the payment layer. Upgrades, compliance changes, and infrastructure issues are someone else’s problem. The cost of switching providers is real but limited: you’re just replacing one API integration with another.
With embedded payments, your architecture becomes the payment layer. Here’s what that can mean:
Onboarding flows get more complicated: Your users become payment-enabled entities. You need to collect business information, verify customer identities, and meet Know Your Customer (KYC) requirements before they can process a transaction.
Compliance becomes a product requirement: You might be responsible for monitoring transactions for fraud, filing suspicious activity reports, or meeting card network rules on a per-account basis. You’ll also need to track connected accounts, their payout schedules, their transaction histories, and any reserves or holds on funds. This is a substantial expansion of the data model.
Pricing becomes part of your product strategy: When you’re earning on transactions, the spread between what you pay your payment provider and what you charge your users is where you make money. You need a pricing model that accounts for the risk you’re taking on and matches the types of transactions and customers your product attracts.
How Stripe Connect can help
Stripe Connect orchestrates money movement across multiple parties for software platforms and marketplaces. It offers quick onboarding, embedded components, global payouts, and more.
Connect can help you:
Launch in weeks: Use Stripe-hosted or embedded functionality to go live faster, and avoid the up-front costs and development time usually required for payment facilitation.
Manage payments at scale: Use tooling and services from Stripe so you don’t have to dedicate extra resources to margin reporting, tax forms, risk, global payment methods, or onboarding compliance.
Grow globally: Help your users reach more customers worldwide with local payment methods and the ability to easily calculate sales tax, value-added tax (VAT), and goods and services tax (GST).
Build new lines of revenue: Optimize payment revenue by collecting fees on each transaction. Monetize Stripe’s capabilities by enabling in-person payments, instant payouts, sales tax collection, financing, expense cards, and more on your platform.
Learn more about Stripe Connect, or get started today.
De inhoud van dit artikel is uitsluitend bedoeld voor algemene informatieve en educatieve doeleinden en mag niet worden opgevat als juridisch of fiscaal advies. Stripe verklaart of garandeert niet dat de informatie in dit artikel nauwkeurig, volledig, adequaat of actueel is. Voor aanbevelingen voor jouw specifieke situatie moet je het advies inwinnen van een bekwame, in je rechtsgebied bevoegde advocaat of accountant.