Embedded Payments

What Are Embedded Payments?

Embedded payments are payment processing capabilities built directly into a non-financial software platform, so customers can complete transactions without leaving the app or being redirected to an external checkout page. The payment experience feels native to the platform rather than bolted on from a third-party provider.

Consider a freelancing platform where a client approves a deliverable and payment is captured, split, and disbursed to the freelancer: all within the same interface. Or a restaurant management system where diners pay their bill through the POS without interacting with a separate card terminal. In both cases, payment is embedded into the core workflow rather than treated as a separate step.

Embedded payments are a specific category within embedded finance, which is the broader practice of integrating financial services (lending, insurance, banking, payments) into non-financial platforms. While embedded finance encompasses everything from Banking-as-a-Service to embedded lending, embedded payments focus specifically on the movement of money at the point of transaction.

How It Works

Traditional payment acceptance requires a merchant to establish relationships with multiple parties: an acquirer (acquiring bank), a payment gateway, and often a payment service provider. The merchant signs up for a merchant account, integrates checkout forms, and manages compliance independently. Customers often see a redirect to a hosted payment page with different branding.

Embedded payments collapse this complexity. The software platform handles payment acceptance on behalf of its users (the sub-merchants), either by becoming a registered payment facilitator or by partnering with a provider that offers payment facilitation as a service.

The Payment Facilitator Model

A platform that wants full control over the payment experience can register as a payment facilitator (PayFac) with card networks and acquiring banks. As a PayFac, the platform:

1. Maintains a master merchant account with an acquiring bank
2. Onboards its own users as sub-merchants under that master account
3. Handles KYC/AML screening, underwriting, and risk monitoring for each sub-merchant
4. Processes payments through its own infrastructure and settles funds to sub-merchants
5. Retains a portion of the processing fee as revenue

Becoming a full PayFac requires significant investment: regulatory registration, PCI DSS compliance, acquiring bank sponsorship, and dedicated risk and compliance teams. Registration alone can take several months and require ongoing operational overhead.

PayFac-as-a-Service

Most software platforms do not become full PayFacs. Instead, they use a PayFac-as-a-Service provider (such as Stripe Connect, Adyen for Platforms, or similar) that handles the infrastructure, compliance, and acquiring relationships. The platform integrates the provider's APIs and presents a white-labeled payment experience to its users.

Under this model, the platform still earns a share of processing revenue, but the provider manages the regulatory burden. Onboarding time drops from months to weeks, and the platform avoids building its own risk monitoring, settlement, and dispute resolution systems.

Integration Architecture

At a technical level, embedded payment integrations typically follow this pattern:

// Simplified embedded payment flow
// 1. Platform creates a connected account for its sub-merchant
const account = await paymentProvider.createAccount({
  type: "express",
  country: "US",
  capabilities: { card_payments: { requested: true } },
});

// 2. Customer initiates checkout within the platform UI
const paymentIntent = await paymentProvider.createPayment({
  amount: 5000,        // $50.00
  currency: "usd",
  onBehalfOf: account.id,
  applicationFee: 250, // Platform takes $2.50
});

// 3. Payment settles to sub-merchant minus platform fee

The customer never leaves the platform. The platform collects its fee automatically on each transaction, and the sub-merchant receives the remainder after interchange and processing costs.

Revenue Model

The primary business motivation for embedded payments is revenue. Rather than treating payments as a cost center, platforms convert them into a profit center by capturing a share of processing fees.

Revenue mechanics vary by operating model, but they generally work as follows:

• The card network and issuing bank collect interchange (typically 1.5% to 3% in the US for consumer credit cards)
• The payment provider charges a buy rate (its base processing fee) to the platform
• The platform marks up the buy rate and charges its sub-merchants a higher effective rate
• The difference between the marked-up rate and the buy rate is the platform's net revenue, often called the "take rate"

Industry benchmarks for net take rates range from approximately 20 basis points for referral-only arrangements to over 100 basis points for full PayFac models at scale. For a platform processing $1 billion in annual payment volume at a 100 bps take rate, embedded payments would generate roughly $10 million in annual revenue.

Use Cases

Vertical SaaS Platforms

Vertical software companies serving specific industries (restaurant management, property management, healthcare billing, field services) are among the largest adopters of embedded payments. These platforms already manage the core business workflow, and adding native payment acceptance is a natural extension. Companies like Toast in restaurants and Mindbody in fitness have built significant revenue streams by embedding payments into their software.

Marketplaces and Gig Platforms

Two-sided marketplaces require payment flows between buyers and sellers, including escrow, split payments, and delayed disbursement. Embedded payments handle these complex flows natively. The platform captures funds from buyers, holds them until service delivery is confirmed, then disburses to sellers minus the platform's commission: all without exposing the underlying payment infrastructure.

B2B Platforms and Invoice Settlement

Business-to-business platforms embed payment acceptance for batch invoice settlement, purchase order payments, and net-terms financing. B2B transactions often involve higher values, multiple approval workflows, and payment methods beyond cards (ACH, wire transfers). Embedded payments in B2B contexts may also integrate with supply chain finance and invoice factoring services.

Stablecoin-Native Embedded Payments

A newer category of embedded payments uses stablecoins instead of traditional card rails. Rather than connecting to acquiring banks and card networks, platforms integrate stablecoin SDKs that handle wallet creation, payment acceptance, and settlement on-chain.

This approach eliminates several layers of traditional payment infrastructure: interchange fees, chargebacks, and multi-day settlement cycles. Platforms using the Spark SDK, for example, can embed Bitcoin and stablecoin payments into their applications with near-instant settlement finality and no acquiring bank relationship. For a deeper comparison of stablecoin payment APIs, see the embedded stablecoin checkout integration analysis.

// Stablecoin embedded payment: no acquirer needed
const invoice = await sparkSDK.createInvoice({
  amount: 50_00,       // $50.00 in USDB
  currency: "USDB",
  memo: "Order #12345",
});

// Settlement is final in seconds, not days
// No interchange, no chargeback risk

Embedded Payments vs. Traditional Payment Processing

Why It Matters

Embedded payments have shifted how software companies think about monetization. Instead of relying solely on subscription fees, platforms capture a percentage of every transaction flowing through their system. For high-volume verticals, payment revenue can exceed software subscription revenue.

The trend also reduces friction for end users. A contractor using a field-services platform does not need to set up a separate merchant account, negotiate processing rates, or integrate a standalone payment gateway. Payments simply work as part of the software they already use.

For the broader payments ecosystem, the emergence of stablecoin-based embedded payments represents a potential disruption to the traditional four-party model (cardholder, merchant, issuer, acquirer). Platforms that embed stablecoin acceptance bypass card networks entirely, settling peer-to-peer on payment rails that operate 24/7 with programmable settlement logic. For a broader view of how this fits into the evolving payment stack, see the research on composable payment infrastructure.

Risks and Considerations

Regulatory and Compliance Burden

Platforms that embed payments take on responsibility for sub-merchant compliance. This includes KYC/AML verification, transaction monitoring, sanctions screening, and reporting obligations. In some jurisdictions, operating as a payment facilitator requires a money transmitter license or equivalent authorization. Failure to comply can result in fines, loss of processing privileges, or legal liability.

Vendor Lock-In

Deeply integrating a specific payment provider's APIs into a platform creates switching costs. Migrating from one PayFac-as-a-Service provider to another, or moving from a PFaaS model to a full PayFac registration, can require significant re-engineering. Some platforms address this with a payment orchestration layer that abstracts the underlying provider.

Fraud and Risk Exposure

When a platform facilitates payments, it often bears liability for fraud and chargebacks on its sub-merchants' transactions. A platform with insufficient risk controls can face cascading losses from fraudulent sub-merchants. The chargeback ratio of the platform's master merchant account is monitored by card networks, and excessive chargebacks can result in penalties or account termination.

Settlement and Counterparty Risk

In traditional embedded payment models, funds flow through the platform or its provider before reaching the sub-merchant. This introduces settlement risk and potential counterparty risk. If the platform or provider becomes insolvent, sub-merchant funds in transit could be at risk. Stablecoin-based models can reduce this by settling directly to the recipient's wallet, but they introduce their own risks around stablecoin depeg and custodial risk.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.