How to implement embedded payments for your marketplace

Implementing embedded payments means building a licensed payment system directly into your marketplace, so buyers pay and sellers get paid without leaving your product. For European marketplaces, this is a sequence of decisions: mapping money flows, choosing a payment facilitator model, building sub-accounts, automating seller verification, and configuring how splits and payouts execute. Getting the sequence right the first time avoids a costly rebuild later.

Map your money flows before choosing a provider

Every marketplace moves money differently, and that shape determines what infrastructure you need. A booking marketplace holds funds until a service is delivered, an on-demand marketplace splits a single payment three or four ways in real time, and a subscription marketplace needs recurring billing layered on top of payouts.

Write down every party who touches a transaction: buyer, seller, platform, and any co-seller or referral partner. Note when each party gets paid and under what condition. This map becomes the specification you hand to a potential provider, and it exposes whether you need escrow, instant payouts, or multicurrency support before you start evaluating vendors.

Decide between becoming a payment facilitator and partnering with one

A marketplace has two paths into embedded payments. Becoming a registered payment facilitator gives full control over the payment experience, but it means taking on licensing, underwriting, and ongoing regulatory obligations directly. Most marketplaces do not have the resources or the timeline for this route.

The alternative is PayFac as a Service, where a licensed provider holds the regulatory authorisation and handles compliance, while the marketplace keeps its own branding and product experience. Ryft holds FCA authorisation and operates across Europe, so marketplaces embed payment functionality without becoming a regulated entity themselves.

Build the sub-account structure for sellers

Every seller on the marketplace needs a sub-account: a ledger maintained within the provider's authorised systems that holds funds on the seller's behalf and tracks their transactions separately from the platform's own balance. This is what keeps third-party funds off your balance sheet and satisfies the safeguarding requirement under European payment services rules.

The sub-account structure also determines how you can scale embedded payments later. A marketplace that needs to route a percentage to a co-host, a referral partner, or a multi-seller basket needs sub-account architecture that supports more than one split per transaction from day one, rather than retrofitting it once volume is already flowing.

How to automate embedded payments in seller onboarding

Before any seller can receive a payout, they must be verified under PSD2 and equivalent payment services rules. This covers identity document checks, address verification, and enhanced due diligence for higher-risk categories. Manual review does not scale past a handful of sellers a week.

Automated KYC built into the registration flow compresses this, which matters directly for activation. A seller who cannot receive a payout on day one is a seller evaluating whether to list elsewhere, so onboarding speed is a retention metric, not just a compliance step.

Configure split payments and settlement timing

Once a seller is verified, define how splits execute. A standard flow authenticates the card under Strong Customer Authentication, captures the payment, deducts the platform's commission at the point of split, and routes the remainder to the seller's sub-account. This should happen within the transaction rather than as a manual step afterwards, since manual disbursement creates reconciliation overhead and can constitute unlicensed holding of third-party funds under European payment services regulation.

Settlement timing is a product decision as much as a technical one. Instant, daily, or deferred payouts are all configurable, and faster payouts are increasingly a retention lever in their own right. Ryft supports split payments to unlimited sellers on a single transaction, which matters for marketplaces with layered commission structures or multiple co-sellers per order.

How to secure embedded payments against fraud and disputes

Your provider should support configurable fraud rules based on your marketplace's specific risk patterns, rather than a single fixed ruleset applied to every transaction type.

Dispute handling needs the same marketplace-specific thinking. When a buyer disputes a charge that has already been split three ways, someone has to decide how the chargeback is absorbed across the platform and the seller. This should be defined in your provider agreement before your first dispute arrives, not worked out in the middle of one.

Understand the pricing model before you commit

Marketplace payment economics differ from standard checkout economics, since fees apply to gross transaction volume before most of it is distributed to sellers. A flat-rate model that looks competitive on a single transaction can become expensive at volume once every split is priced individually.

Volume-based pricing scales more predictably as transaction counts grow, which is why Ryft prices this way rather than on a flat per-transaction basis. Tuft, a growing marketplace, reduced its payment processing costs by 62% after switching from Stripe, a flat-rate provider to Ryft's volume-based model.

Plan for regulatory compliance from day one

Payment institutions across Europe face tightening scrutiny over how customer funds are safeguarded. In the UK, the FCA's strengthened safeguarding regime came into force on 7 May 2026, requiring authorised payment institutions to run daily reconciliations, maintain resolution packs, and submit monthly safeguarding returns. Similar tightening is underway across the wider EU as PSD3 approaches, expected between late 2027 and early 2028. Read more on the changes of PSD3 here.

A marketplace operating through a licensed sub-account structure sits behind that provider's compliance programme rather than carrying the obligation directly. A marketplace that builds payments outside this structure, or bolts split functionality onto a single-merchant setup, inherits the exposure these rules exist to catch. This is the clearest reason implementation planning should start with the regulatory model, not just the technical integration.

Choosing an embedded payments provider for seller productivity

Once your money flows, split logic, and compliance requirements are mapped, evaluate providers against that specification rather than a generic feature list. Confirm regulatory authorisation status, ask how many sellers a single transaction can split to, and check whether support is a dedicated team or an outsourced queue.

Ryft is built for European marketplaces, with regulatory authorisation, volume-based pricing, and a support team available around the clock. Marketplaces that map their requirements before evaluating providers typically integrate faster and avoid the mid-build changes that add cost.

If you're planning an embedded payments implementation, Ryft's split payment functionality and rapid seller onboarding are built specifically for marketplace money flows. You can also read our complete guide to embedded payments for the underlying concepts, or see how delayed payments and escrow fit into a build via our marketplace use case page.

‍