Embedded payments are card and bank payments that a software platform or marketplace offers inside its own product. Its users accept money without signing up with a separate processor. The platform owns the checkout and the experience. A payment provider, an acquiring bank and the card networks sit underneath. How much of that stack the platform takes on depends on the model: its own PayFac registration, a PayFac-as-a-service partner, or a Connect-style product.
How embedded payments work
Four parties sit behind every embedded card payment.
- The platform. A SaaS product or marketplace whose users sell goods or services.
- The sub-merchant. The platform’s user, who is paid for the sale. Visa calls this a “sponsored merchant” when a payment facilitator signs it up.
- The payment provider. It processes transactions, onboards sub-merchants and moves funds. Examples on remwm: Stripe Connect, Adyen for Platforms and Finix.
- The acquirer. A bank licensed by the card networks to contract with merchants for card acceptance.
The acquirer is the anchor. Visa’s rules say a payment facilitator (PayFac, or PF) is a third-party agent that signs merchant contracts on behalf of an acquirer and receives settlement from the acquirer on behalf of its sponsored merchants. Visa treats an entity that does either of these two things as a PF. The acquirer stays responsible for the acts of both the PF and its sponsored merchants, and must register the PF with Visa after a risk and financial review.
Providers disclose who their acquiring banks are. Finix, for example, states that it is a registered payment facilitator of Fifth Third Bank and a registered processor of Pathward.
Three ways to embed payments
The labels below are industry shorthand, not card-network categories. Visa’s rules know acquirers, payment facilitators, sponsored merchants and marketplaces. The shorthand describes who does the PayFac work.
| Model | Who is registered as the PF | Who onboards and underwrites sub-merchants | Who receives settlement and pays out | Example from provider docs |
|---|---|---|---|---|
| Registered PayFac | The platform, sponsored and registered by an acquirer | The platform, under the acquirer’s oversight | The platform | Finix is itself a registered payment facilitator of Fifth Third Bank |
| PayFac-as-a-service | Set by contract: the provider, or the platform using the provider’s tooling | The provider’s tooling, with the platform’s input | The provider’s systems, often on the platform’s instructions | Finix sells its platform to PayFacs, SaaS platforms and marketplaces |
| Connect-style platform product | The provider | The provider, through hosted or embedded onboarding | The provider, on the platform’s instructions | Stripe Connect; Adyen for Platforms |
Registered PayFac. The platform gets the most control over onboarding, pricing and funds flow. It also takes on the acquirer’s due diligence, ongoing monitoring and the network obligations that come with the role. Visa bars a PF from sponsoring another PF, a staged digital wallet or money-transfer activity.
PayFac-as-a-service. A provider supplies onboarding, underwriting, risk and payout tooling. Who holds the PF registration depends on the contract. Ask for that in writing.
Connect-style product. The platform builds on the provider’s API and components. Stripe says Connect lets platforms onboard users through a Stripe-hosted flow, embedded components or an API. Adyen says it verifies users before paying them out and cites its EU, UK and US financial licences.
Embedded payments vs integrated payments
The two terms are often used as synonyms, but providers draw a line between them. Worldpay for Platforms puts it this way: “With integrated payments, you’re a software company that connects to payments. With embedded payments, you’re a software company that offers payments.” Stripe’s guide to the two models draws the same line.
| Integrated payments | Embedded payments | |
|---|---|---|
| Merchant account | The software’s user signs its own contract with a processor | The user is onboarded inside the platform, as a sub-merchant or connected account |
| Who the user deals with on payments | The processor, often under its own brand | The platform |
| Platform revenue from payments | Usually a referral or revenue share, if any | Can set or mark up pricing, depending on the model |
| Platform responsibility | Lower: the processor holds the merchant relationship | Higher: onboarding, risk and support move toward the platform |
An integrated setup can move toward an embedded one later. The questions below help a platform check how far a provider lets it go.
How the money moves
Funds flow is a design decision, not a detail. It decides whose balance takes a refund or a chargeback.
Stripe’s Connect documentation describes three charge types:
- Direct charges. The payment lands in the connected account’s balance. Refunds and chargebacks reduce that balance. Stripe suggests this for SaaS platforms.
- Destination charges. The payment lands in the platform’s balance, and part of it moves to the connected account. Refunds and chargebacks reduce the platform’s balance. Stripe suggests this for marketplaces.
- Separate charges and transfers. One charge can pay several connected accounts. Stripe suggests this for a single cart with goods from many sellers.
Adyen for Platforms splits integrations into a marketplace model, where shoppers deal with the platform, and a platform model, where shoppers deal with the platform’s users. Adyen lists payment facilitators under the platform model.
What pricing providers publish
Published pricing varies. Stripe publishes two Connect options. In the first, Stripe sets and collects processing fees from the platform’s users, and the platform pays no extra account or payout fees. In the second, the platform sets its own pricing and pays $2 per monthly active account plus 0.25% + 25¢ per payout. Stripe counts an account as active in any month it receives a payout.
Where a provider does not publish a rate card, treat price as a negotiated field. remwm provider profiles record pricing only when the provider publishes it.
Security and card-data scope
The Payment Card Industry Data Security Standard (PCI DSS) applies to every entity that stores, processes or transmits card data. That includes merchants, processors and service providers. The PCI Security Standards Council published PCI DSS v4.0.1 in June 2024. Its 51 future-dated requirements became mandatory on March 31, 2025.
Embedded models often keep card data off the platform’s servers through hosted fields or pages. Two of the newer requirements, 6.4.3 and 11.6.1, cover scripts on payment pages. The Council has said they target e-skimming. Its Self-Assessment Questionnaire A (SAQ A) covers card-not-present merchants that fully outsource card-data functions. Which questionnaire applies to a platform is a question for its acquirer and assessor. This article is not legal or compliance advice.
Questions to ask a provider
- Who is the registered payment facilitator for my sub-merchants: you or us?
- Which acquiring banks sit behind card acceptance, and where is that disclosed?
- Who performs identity checks and underwriting on sub-merchants, and who can override a decision?
- Which charge or funds-flow models do you support, and whose balance absorbs refunds and chargebacks in each?
- Is pricing published? If not, which fees are fixed and which are negotiated?
- Which PCI DSS validation do you hold, and which questionnaire do you expect us to complete?
- If we later want our own PayFac registration, can sub-merchants move without re-onboarding?
Some platforms also route between several processors. That is a separate layer, covered in payment orchestration. For how payments fit into lending, accounts and cards sold to businesses, see b2b embedded finance. More in our payments guides.
