Marketplace Payouts and Seller Wallets: Build, Buy or Embed?

Marketplace Payouts and Seller Wallets: Build, Buy or Embed?

A marketplace's payout flow is easy to ignore until it fails. A seller is paid late, a fee is split wrongly, a currency is not supported, or someone asks who is actually holding the money. Product teams then meet a decision they have usually postponed: build payouts themselves, buy a payouts service, or embed a wallet that sellers can hold and use. This guide is for directors of eCommerce, CDOs, heads of payments, CTOs and CPOs at UK marketplaces and platforms. It compares the three models, explains why the question of who holds seller balances usually decides the answer, and shows how to keep the choice reversible. Regulatory points are at outline level only and are not legal advice.

A payout is a lifecycle, not an API call

The most common mistake is to treat a seller payout as a single step at the end of an order. It is a chain of obligations, and each link can fail on its own:

• Seller onboarding and verification: you need to know who you are paying before you pay them
• Collection: taking the buyer's payment and matching it to the right order
• Splitting: dividing one buyer payment between the seller, your platform fee and sometimes other parties, which is what "split payments" means in marketplace terms
• Holding: keeping funds until a condition is met, such as delivery or the end of a return window
• Release: paying the seller, on a schedule or on request, to the account or balance they choose
• Reconciliation and reporting: proving that every pound in matches a pound out, to sellers, finance and auditors

How you assign these responsibilities across your own team, a payments provider and a regulated partner is the build, buy or embed decision. The rest of this guide is about making that assignment on purpose rather than by accident.

Three models, defined

The terms below are working definitions for decision-making. They are our framing, not industry-standard categories, and real programmes often blend them.

Build

You design and run the payout logic yourself: seller onboarding, your own ledger, split rules, release schedules, reconciliation and reporting. Money still has to move through a regulated route, so building the product layer does not remove the need for a regulated partner or permissions underneath it.

The case for it: full control of the seller experience and of the data, and the ability to design flows that off-the-shelf services do not support.

The cost: a long engineering run, an ongoing maintenance burden, and ownership of every edge case from failed payouts to reconciliation breaks. The last of these is easy to underestimate.

Buy

You integrate a marketplace payments or payouts service. The provider runs collection, splitting and payout flows, typically within its own regulated structure, and you connect by API. Depending on the structure, seller funds are usually held by the provider and not by you. Which funds sit where, and under whose permissions, should be confirmed in writing and checked with your advisers.

The case for it: speed to launch, less to build and, often, broader coverage than you could assemble alone.

The cost: less control over the seller experience, dependency on the provider's roadmap and pricing, and a seller relationship that may feel like it belongs to someone else.

Coverage deserves testing, not trust. One payments provider announced on LinkedIn, on 20 October 2026, that it had added local payouts in five more currencies (AUD, HKD, SGD, MXN and TRY) across APAC, LATAM and EMEA, so that platforms can pay sellers through local networks rather than correspondent banking. That is a company's own announcement, not independently verified, and none of those currencies is sterling. We cite it only as a sign that payout coverage is expanding quickly. Our interpretation is that any coverage claim should be checked against the specific corridors and currencies your sellers use, and put in the contract.

Embed

You offer sellers a branded wallet or account inside your own product, where they can see, hold and use balances, delivered with a regulated partner. If you are weighing this route, our embedded wallet and finance work is a useful reference point for what the product and integration layers involve.

The case for it: a stronger seller relationship, a richer product and more control over how and when sellers use their money.

The cost: the widest product surface, the heaviest compliance and operational load, and the regulatory questions that come with balances sellers can hold. That brings us to the point that usually decides the choice.

Who holds seller balances decides the answer

Moving money on behalf of others and holding it for others are different questions. As a general matter, the longer funds sit and the more freely sellers can use them, the more the arrangement looks like holding customer money. That is where the regulatory position gets complicated.

At outline level, there are broadly three ways a marketplace can approach it:

• Operate under your own permissions, which means seeking authorisation and carrying the obligations that come with it
• Operate through a regulated partner whose permissions cover the activity, with the contract setting out who does what
• Structure the flows so that the marketplace does not hold funds, relying on a rule, exclusion or exemption where one is available

Which of these is open to you is a legal question that depends on your exact flows, and we are not offering a view on it. The FCA publishes its own material on payment services, electronic money and the safeguarding of customer funds, and fca.org.uk is the authoritative place to read the position. Take advice for your own circumstances before you commit to a design.

A regulated partner changes the answer. It can make the embed model feasible without the marketplace becoming authorised itself, but it also brings conditions: the partner's own approval of your product and flows, its onboarding and monitoring requirements, and a contract that allocates responsibility. Those conditions shape what you can build, and they are worth understanding before you fall in love with a wallet design.

One practical distinction helps with scoping. A payout released to a seller's bank account on a schedule is a different proposition from a balance a seller can hold, spend and withdraw at will. The second looks more like stored value, and that is where the question of e-money tends to arise. If your roadmap includes the second, raise it with your adviser early.

Questions to bring to that conversation:

• What exactly are we doing with seller funds, and for how long?
• Who can instruct a payment, and on whose behalf?
• What do sellers see in their terms about their balance?
• Which party is responsible for safeguarding, onboarding and ongoing monitoring?

A decision framework

Use these six questions in order. Each one tends to push the decision in a direction, and the pattern of answers tells you more than any single one.

1. Do sellers need to hold a balance, or simply be paid? If paying on a schedule is enough, buying a payouts service is usually sufficient. If sellers need to hold, spend or move funds inside your product, embedding comes into play.
2. Is the payout experience part of your proposition? If sellers choose you partly because of how quickly and clearly they are paid, you will want more control than a standard service gives you.
3. Where are your sellers? A UK-only seller base has a narrower set of requirements than one that spans currencies and countries. Cross-border coverage is a common reason to buy.
4. Who carries the regulated risk, and do you have a regulated partner available? Without a route to one, build and embed both stall.
5. What engineering capacity do you have, and for how long? Be candid about maintenance, not just the first release.
6. How reversible does the choice need to be? If you expect to change provider or model, design for it from the start.

Our view, which is analysis and not a cited finding, is that most marketplaces should rent the regulated core and build the layers that differentiate. In practice that often means starting with a bought payouts service, building your own seller-facing experience, ledger of record and reconciliation on top, and moving to an embedded wallet when balances become part of the product, not merely a stop on the way to a bank account. Building the whole stack from the bottom is rarely the best use of a product team's time, and embedding too early takes on regulatory and operational weight before the seller need is proven.

Provider-change risk: keep the choice reversible

Whatever you choose, assume the provider underneath may change. In its summary of company announcements dated 11 October 2026, This Week in Fintech reported that a digital-asset custodian had acquired a payouts platform, and that the acquisition of a BaaS provider had been completed. That is third-party reporting, and this article names neither firm and draws no conclusions about them. Our reading is that it fits a wider pattern of consolidation across payments, BaaS and digital-asset infrastructure, which is a reason to plan for provider change, not a prediction about any provider.

A short list covers most of what protects a marketplace:

• Keep your own record of seller balances and payouts, reconciled to the provider's, so you can reconstruct state if you need to move
• Put the provider behind an interface you control, so seller-facing code does not depend on one provider's identifiers or behaviour
• Secure data export rights and test them, including payout history and seller verification records
• Read the change-of-control, termination and notice clauses in your agreement before you need them, with your lawyers
• Write down what would make you migrate, and who decides

The aim is the option to move, not a commitment to run two providers at once.

Where Innovify fits

Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance. We help mid to large businesses, including brands and platforms that are not financial companies, build AI-native products, modernise their technology stack and launch fintech products. We design compliance in from day one, and we are an implementation partner across multiple fintech platforms.

Innovify is not FCA-authorised. We build for regulated clients and for platforms working with regulated partners, and we do not give legal or regulatory advice. Whether your marketplace can hold seller funds, and under whose permissions, is a question for your own legal and compliance advisers.

What we can help with is turning the decision into a working product: mapping your payout lifecycle, designing the ledger and reconciliation layer, building the seller-facing experience, and structuring the integration so that a change of provider is manageable. If you are deciding between buying payouts and embedding a seller wallet, explore Innovify's Embedded Finance & Digital Wallets work and let's build your next AI or financial product.

FAQ

How does a marketplace pay out sellers and hold balances?

A marketplace collects the buyer's payment, splits it between the seller and its own fee, holds it until any conditions are met, and then releases the seller's share. Funds are held under a regulated structure, which may be the marketplace's own permissions, a regulated partner's or an arrangement that avoids holding funds. Which applies is a legal question, so take advice for your own flows.

What is the difference between marketplace payouts and a seller wallet?

A payout moves a seller's earnings to their bank account, usually on a schedule or on request. A seller wallet is a balance inside your product that the seller can hold, see and often spend or send. The wallet gives you a richer product, but holding balances raises heavier regulatory and operational questions than paying out does.

Does a UK marketplace need to be regulated to hold seller funds?

It depends on how the flows are structured and who holds the funds, and that is a question for your legal adviser, not a general rule. A marketplace may work through a regulated partner or structure its flows so that it does not hold funds itself, but each route has conditions. The FCA publishes its own material on payment services and e-money, and fca.org.uk is the place to start.

Should a marketplace build, buy or embed its payouts?

In our view, most marketplaces are better served by buying the regulated core and building the seller-facing experience, ledger and reconciliation on top. Embedding a wallet makes sense once sellers need to hold and use balances in your product and you have a regulated partner to deliver it. Building everything from the bottom is rarely the best use of engineering time.

How do I reduce provider risk in marketplace payments?

Keep your own reconciled record of balances and payouts, put the provider behind an interface you control, secure and test data export rights, and read the change-of-control and termination terms in your agreement. The aim is the ability to switch provider if you need to, not necessarily to run two at once.

Conclusion

Build, buy or embed is less a technology choice than a question about who holds seller money and who carries the regulated risk. Answer that first, with advice, and the rest of the decision follows: buy the regulated core, build what differentiates, embed when balances become part of the product, and keep every choice reversible. Treat the provider as a component you may one day replace, because the market underneath it is moving.