Embedded payments are one of the most significant shifts in how software companies generate revenue — and most platforms still haven't fully captured the opportunity.
This guide explains what embedded payments are, how the architecture works, the different models available, and what to look for when evaluating a solution. Whether you're a platform considering adding payments for the first time or re-evaluating an existing integration, this is the foundation.
What Is Embedded Payments?
Embedded payments is the practice of integrating payment processing directly into a software platform, so that the platform's end users — merchants, businesses, or service providers — can accept payments without leaving the platform or setting up a separate relationship with a payment provider.
Instead of a merchant signing up for their own Stripe account and loosely connecting it to your software, the payment capability is native to your product. It lives inside your UI, uses your branding, and is managed through your platform. To the merchant, it just feels like a feature of the software they already use.
A few concrete examples:
A property management platform where landlords collect rent from tenants — without ever logging into a separate payments dashboard
An insurance platform where agents take premium payments mid-conversation, with full PCI compliance and no data leaving the secure call environment
A CCaaS platform where AI voice agents process card payments during customer calls, authenticated and authorised before the call ends
An ERP platform where accounts receivable teams send branded payment links to clients and reconcile receipts automatically
In each case, the payment isn't an afterthought. It's woven into the workflow. That's embedded payments.
How Embedded Payments Work
At a high level, embedded payments sit between your software and the underlying payment infrastructure. The architecture typically looks like this:
Customer → Platform UI → Payment Layer → PSP → Acquiring Bank → Card Network → Issuing Bank
Breaking that down:
Platform integration — The platform integrates a payment layer (via API or SDK) once. This single integration provides access to payment processing, merchant management, compliance handling, and reporting.
Merchant onboarding — Merchants join through the platform's own onboarding flow. They're known as your merchants, not the PSP's merchants. The white-label layer means your branding is front and centre throughout.
Payment processing — When a customer pays, the transaction flows through the payment layer to the underlying payment service provider (PSP) — Stripe, Worldpay, Adyen, or whichever PSP is configured for that merchant or platform.
Settlement and reporting — Funds settle to the merchant, and the platform has visibility into transaction data, reporting, and reconciliation — all through a single management layer.
Revenue share — The platform earns a share of transaction revenue, either as a flat per-transaction fee, a percentage of processing volume, or a negotiated margin built into the payment flow.
The key architectural principle: the platform doesn't need to know which PSP is doing the processing. The payment layer handles that abstraction. This is what makes embedded payments scalable — you add the capability once and configure it across any number of merchants and PSPs.
Embedded Payments vs Traditional Payment Integration
The distinction between embedded and traditional payment integration matters more than it might seem.
Traditional Integration | Embedded Payments | |
|---|---|---|
Merchant setup | Merchant creates their own PSP account (Stripe, Square, etc.) | Merchant onboards through the platform |
Branding | PSP-branded checkout and dashboards | White-labelled to the platform |
Platform control | Limited — platform is a bystander | Full — platform manages the flow |
Revenue to platform | None (or minimal referral) | Transaction revenue share |
PSP relationship | Merchant owns it | Platform owns or manages it |
Data visibility | Fragmented across PSPs | Consolidated in platform layer |
Merchant experience | Disjointed — switches between tools | Seamless — payments feel native |
Time to onboard | Days (separate sign-up, verification) | Minutes (platform-managed KYC) |
Traditional integration is common in early-stage SaaS products — the path of least resistance is to link to an existing PSP and let merchants handle their own accounts. This works until it doesn't. Enterprise customers start demanding specific PSPs. The experience becomes fragmented. Revenue leaks. Competitive platforms that have native payments win the deal.
Embedded payments is the architecture that fixes this.
Who Uses Embedded Payments
Embedded payments are relevant to any software platform where payments are a required or natural part of the workflow. In practice, the highest-fit verticals are:
SaaS platforms — Any vertical SaaS product where merchants need to collect payment from their own customers. Field service, property management, membership platforms, professional services software.
Marketplaces — Two-sided platforms where payments move between buyers and sellers. Embedded payments handle the split, the reconciliation, and the merchant onboarding at scale.
CCaaS and contact centres — Contact centre platforms and AI voice companies where agents (human or AI) need to take payments during a call without breaking the call flow or transferring PCI liability. This is one of the fastest-growing embedded payments use cases.
Insurance platforms — Regulated environments where premium collection, claims payments, and policy renewals need to happen inside the platform workflow, often with specific PSP requirements per carrier or region.
Travel platforms — Complex multi-currency, multi-PSP environments where different airlines, operators, or markets require different payment providers. Embedded payments handles the PSP routing behind a single merchant-facing experience.
ERP and invoicing platforms — Accounts receivable automation, invoice-to-cash workflows, payment plans. Embedded payments turns billing software into a collection engine.
AI agent platforms — Emerging and growing fast. AI voice agents and chat agents that can close a sale, take a deposit, or collect a payment inline, without handoff to a human or redirect to a checkout page.
Benefits for Platforms
Embedding payments inside your product is a business decision as much as a technical one. The returns compound over time.
New revenue stream. Platforms that process payments earn transaction revenue — typically a few basis points to a percentage of volume, depending on the model. At scale, this becomes a significant and predictable revenue line that doesn't require new customers.
Increased stickiness. When payments are embedded, merchants become deeply reliant on the platform for a critical business function. Switching costs increase substantially. Churn goes down.
Better merchant experience. A native payment experience reduces friction, eliminates tool-switching, and keeps merchants focused on their workflow. This shows up in onboarding rates and daily active usage.
Competitive differentiation. Enterprise deals increasingly require embedded payment capabilities. Platforms without them lose deals to platforms that have them. The gap between embedded and non-embedded products is widening.
Consolidated data. When payment data lives inside the platform layer, it becomes usable. Platforms can surface insights, automate reconciliation, build reporting features, and improve underwriting or risk models over time.
PSP leverage. A platform with embedded payments controls which PSP processes their merchants' volume. That's negotiating power — for better rates, better service, and better integrations.
Benefits for Merchants
The merchant experience is often underweighted in embedded payments conversations. It matters.
Simpler setup. No separate PSP relationship to negotiate, no separate compliance burden, no separate account management. The platform handles it. Merchants get payment capabilities as part of the product they already use.
Faster onboarding. Platform-managed KYC and merchant onboarding can get a merchant live in minutes, compared to days or weeks through a standalone PSP application.
Unified experience. Payments, reporting, and reconciliation are in the same place as everything else. No logging into separate dashboards or exporting data between systems.
Consistent branding. Merchants interact with their preferred platform's branding throughout the payment flow — not a third-party checkout page that erodes trust.
PSP flexibility. Merchants working with enterprise customers often need to support specific payment providers. With a properly architected embedded payment solution, merchants can bring their preferred PSP or switch providers without changing platforms.
The Build vs Buy Decision
Every platform that reaches the embedded payments conversation eventually asks the same question: should we build this ourselves?
The honest answer is that building payment infrastructure is consistently underestimated. The scope includes: PSP integrations (each one taking months to build and maintain), PCI DSS compliance (Level 1 certification runs $1–2M and requires ongoing effort), merchant onboarding and KYC tooling, a management portal, dispute handling, reconciliation, and ongoing maintenance as PSP APIs change.
The real-world numbers: a self-build typically takes 12–18 months of engineering time, costs $2M or more to achieve PCI DSS Level 1 compliance, and consumes ongoing dev resources to maintain. The $360k annual operating saving compared to in-house infrastructure is consistently cited by platforms that have made the switch.
Buying or partnering with a purpose-built embedded payments solution gets a platform live in weeks — with compliance included, PSP integrations pre-built, and merchant management tools ready to deploy. The build-vs-buy calculation almost always favours buy, unless payments is your core product rather than a capability within it.
What to Look for in an Embedded Payment Solution
Not all embedded payment solutions are the same. When evaluating options, these are the dimensions that matter most for enterprise platforms:
PSP flexibility. Can you connect your existing PSP relationships, or are you locked into the provider's preferred PSPs? A PSP-neutral solution means you can support any PSP your enterprise customers demand — not just the ones your vendor has a commercial deal with.
White-label depth. Does the solution fully disappear behind your brand? Merchants should never see the infrastructure vendor's name. Evaluate the merchant portal, onboarding flows, payment pages, and email communications.
Channel coverage. Payments are increasingly multi-channel. Can the solution handle embedded checkout, payment links, voice payments, and chat payments — or just one channel? Platforms that need to support contact centre and AI agent use cases need voice and link capabilities alongside standard checkout.
Compliance certifications. PCI DSS Level 1 is the baseline. ISO 27001 and SOC 2 matter for enterprise procurement and regulated verticals. These should come included in the solution — not be your responsibility to certify.
Merchant onboarding tools. White-label KYC, document collection, and merchant approval flows. The smoother the onboarding, the faster your merchants activate and the lower your support overhead.
Revenue share model. Understand how the economics work. Revenue share is typically built into the per-transaction margin. Negotiate this clearly and model it at your expected volume.
Time to market. How long does integration actually take? Evaluate this honestly — a single API integration that covers all channels and PSPs will move faster than point integrations for each capability.
Embedded Payments Models
There are several distinct architectural models for embedded payments. Understanding the differences matters when evaluating solutions.
PayFac (Payment Facilitator) — The platform registers as a Payment Facilitator with card networks (Visa, Mastercard) and becomes the merchant of record for all sub-merchants. Maximum control and maximum economics, but also maximum regulatory burden: sponsor bank relationships, risk management, underwriting, compliance, and ongoing operational overhead. Only appropriate for large platforms that want to own payments as a core business function.
PayFac-as-a-Service — Providers like Payrix and Finix handle the PayFac registration and compliance, while the platform maintains a white-label experience. Reduces the regulatory burden compared to becoming a PayFac directly, but platforms are still inheriting significant operational complexity and are typically locked into a single underlying PSP network.
Platform Programmes via PSP — Stripe Connect, Adyen for Platforms, and similar offerings let platforms embed payment acceptance using a single PSP's infrastructure. Lower complexity, faster to deploy — but the platform is locked into that PSP's network, pricing, and geographic coverage. Enterprise customers who want a different PSP create a problem.
PSP-Neutral Payment Layer — A purpose-built layer that sits between the platform and multiple PSPs, providing white-label merchant tooling, compliance, and a single integration point across 40+ payment providers. This is the model that solves the PSP flexibility problem: platforms can support any PSP their merchants or enterprise customers require, across multiple channels, without building or maintaining each integration individually. Shuttle operates on this model.
The right model depends on the platform's size, risk appetite, and how central payments are to the core business. For most software platforms, a PSP-neutral payment layer provides the best balance of speed, flexibility, and economics.
The Future of Embedded Payments
Embedded payments are expanding in two directions simultaneously: more channels and more autonomy.
Multi-channel as the default. The next generation of embedded payments isn't just checkout. Payments are moving into voice calls, chat conversations, SMS threads, and AI agent interactions. A platform that only embeds payments at checkout is leaving significant volume uncaptured — particularly as AI agents begin to handle transactional workflows that previously required a human or a separate payment step.
Multi-PSP as table stakes. Single-PSP embedded solutions are increasingly a liability. Enterprise customers mandate specific PSPs. Regulatory requirements vary by geography. PSP performance differs by vertical. Platforms that can route to multiple PSPs without rebuilding their integration will win deals that single-PSP platforms cannot support.
Agentic commerce. AI agents — voice, chat, and autonomous workflow agents — are becoming transaction-capable. An AI agent that can negotiate, recommend, and close a payment inline (with appropriate authentication and compliance) is a fundamentally new sales and collections channel. Platforms that have the payment infrastructure to enable this will have a significant competitive advantage over those that don't.
The platforms that will own the next decade are the ones that treat payments not as a bolt-on feature but as infrastructure running across every customer interaction.
Related Reading
Ready to Embed Payments in Your Platform?
Shuttle is a PSP-neutral payment layer for software platforms. One integration. 40+ PSPs. White-label merchant tools. Multi-channel coverage across embedded checkout, voice, payment links, and chat. PCI DSS Level 1, ISO 27001, and SOC 2 certified — compliance included.
Platforms go live in weeks, not months.
Book a Discovery Call | See How It Works for Platforms