Explainer: marketplace and platform payments strategy

Milko Filipov, Managing Director at reMonetary, explains how marketplaces and ecommerce platforms should execute their payments strategy, sharing implementation, best practices, and solution scoping. 

When you build a marketplace or platform, you usually have a clear business model in mind: connecting supply and demand for certain products or services. From a business perspective, knowing which to prioritise is one of the biggest challenges. You need to attract both sides and give them a reason to stay. 

Payments are integral to this model and one of the most important elements in building trust between buyers, sellers, and the platform, so it’s worth defining the payment architecture early on. The decisions made at this stage can significantly impact you as the business grows. Getting the model right from the start can save you from costly future changes and give you more freedom to focus on customer relationships and scaling the platform. 

At first, this might sound as simple as integrating credit card payments into a webshop; however, marketplaces and platforms are more complex, as a transaction involves multiple parties and relationships: the platform, the buyer, the seller and the PSP. The added complexity affects the payment setup almost fully. Merchant onboarding, know your customer/know your business (KYC/KYB), payment splitting, payouts, fee handling, refunds, chargebacks, fraud prevention, and regulatory responsibilities should all be considered. 

Therefore, the starting point for designing the right platform model and selecting the payment infrastructure that supports it is understanding these relationships. The goal is to go beyond functional checkout payments and build a payment setup that works as the marketplace grows, adds sellers, and enters new markets. This is reMonetary’s expertise, and this explainer is a practical starting point for thinking through these decisions. 

Marketplace vs. platform: what is the difference?

A marketplace typically brings together independent sellers and buyers. Think of a marketplace where retailers, hotels, or service providers sell to customers through a common interface. The marketplace provides the customer interface, checkout, and payment infrastructure, but the underlying seller is the business offering the product or service. 

Meanwhile, a platform can have a different model. For example, a software platform might provide independent merchants with tools to run proprietary online stores and process payments, with the merchant remaining clearly visible to the customer as the seller. The platform acts as an infrastructure provider rather than as the marketplace where customers shop. 

It’s important to distinguish between the two, as this determines who the customer sees as the seller, and ultimately affects who is expected to handle delivery, refunds, complaints, and chargebacks. It also raises the question of who bears responsibility to the customer if the merchant fails to fulfil the order. 

Now that we know the difference, we can use ‘platform’ or ‘marketplace’ interchangeably throughout this article, regardless of the specific business model. 

This business type connects directly to the Merchant of Record (MoR) model. The MoR is generally the entity acting as the seller in the transaction, taking responsibility for the relevant commercial and payment obligations. A marketplace with the merchant as the seller and a model with the platform as the seller are fundamentally different, even when the checkout experience looks almost identical. Choosing either model directly impacts payment fund flows, merchant onboarding, refunds, customer support, and liability. Therefore, before designing the payment integration, the platform should be clear about who the seller is and what responsibilities that creates for each party. 

The business model determines the payment flow

The payment architecture should reflect the platform’s role in the transaction. 

In a simple model, the customer's payment goes directly to the seller's account, while the platform receives its commission separately. The platform facilitates transactions without control of the seller's funds. This works well when the seller is clearly responsible for the sale and the platform mainly provides the technology and customer interface. 

You need a more complex model when the customer's payment settles first in an account or balance controlled by the platform or its PSP, and it is later allocated between the seller and the platform. For example, a customer pays EUR 100, the platform takes a EUR 10 commission, and EUR 90 is subsequently paid to the seller. The platform may also hold the seller's funds before payout, apply reserves, deduct refunds or chargebacks, or split the payment between several sellers. At this point, the platform doesn’t act just as a payment facilitator, as it manages a multi-party fund flow. 

Understanding how the models differ is relevant for customer funds control. If the business model allows it, avoiding unnecessary control over sellers’ funds reduces operational and regulatory complexity. If the platform needs control over the fund flow, the payment infrastructure should explicitly support marketplace accounts, balances, split payments, and payouts, not just rely on a standard merchant account. 

Consequently, payment splitting and payouts should be designed together. The architecture must define where customers' money lands, how a platform's commission is separated, where sellers' funds are held, when they’re available, and how refunds, chargebacks, and reserves affect the balance. When these functions are central to the business, PSP-managed marketplace infrastructure is generally the most practical option. Although building these capabilities independently can increase control, it also adds to development, reconciliation, operational, and compliance requirements. 

So before selecting a PSP, define payment architecture. The right provider, besides the best card acceptance or transaction pricing, also offers account structure, fund flows, onboarding, splitting, payouts, and risk capabilities that fit the platform's business model and can support growth. 

In Europe, a platform providing regulated payment services must hold a Payment Institution (PI) licence under PSD2 or, depending on the model, an Electronic Money Institution (EMI), and must comply with requirements such as safeguarding, capital, governance, AML controls, and regulatory reporting. In the US, a platform that receives funds from buyers and transmits them to sellers may fall under money-transmitter rules, potentially requiring state licences, as well as FinCEN registration and Bank Secrecy Act/anti-money laundering (AML) compliance. 

To accelerate development and avoid building payment infrastructure from scratch, many platforms use PSPs with dedicated marketplace capabilities, which allows them to focus on their core product while relying on the PSP for much of the underlying payment tech. 

Seller onboarding: a part of the marketplace architecture

Even when a PSP provides marketplace capabilities, the compliance responsibilities mentioned above don’t disappear. The PSP may take responsibility for parts of the payment and verification process; however, the marketplace still needs to provide accurate information, follow the required processes, and support the PSP in meeting regulations. How responsibilities are divided depends on the PSP's model, the marketplace's role, and the specific integration structure. 

Once a platform enables independent sellers to receive payments, it should decide which sellers it supports and how to onboard them – which is more than a registration-flow aspect. The sellers’ legal entity type and country of registration affect what information the platform should collect, the verification process, the payment provider's capabilities, and the operating model at scale. 

A marketplace can support companies, sole proprietors, or individual sellers. As such, it should clearly define what information it collects, who collects it, and how the process happens. This could be done manually or automatically, by the marketplace itself or by the PSP, through a hosted onboarding flow. 

The next decision is who handles merchant onboarding and KYC/KYB. A PSP-led model allows the payment provider to collect and verify the information needed for payment processing. A platform-led model gives the marketplace more control over the seller experience but also requires it to manage more of the compliance process. 

Seller access to the PSP: who should own the payment experience?

The payment architecture doesn’t end once the transaction completes, and sellers need visibility over transactions, payouts, fees, refunds, and, potentially, disputes. A platform should therefore decide if merchants interact directly with the PSP or if the platform displays payment information. 

This can be approached in three common ways:

1. sellers can receive full access to the PSP dashboard, which reduces development work because reporting, disputes, and payout tools already exist. 
2. they can receive selected PSP functionality, a hybrid model providing a practical balance, combining the control of a platform-managed experience with the efficiency of PSP-hosted onboarding and verification.
3. or the platform can own the entire payment experience, which gives it much more control but requires it to build and maintain those capabilities. 

Fees, refunds, and chargebacks

The platform should define distribution of payment processing fees and other costs. It can bear payment processing fees, deduct them from merchant payouts, or pass certain expenses to buyers when legally and contractually permitted. The same principle applies to refund and chargeback costs. The platform can handle costs; they can also be withheld from the merchant's balance or allocated according to specific liability rules. These decisions affect the fund flow and are closely tied to the MoR model. 

When selecting a PSP, the platform should therefore consider whether these requirements are supported immediately and how much flexibility the PSP offers to adapt them to the business model. 

Additionally, refund and chargeback processes need an operational definition. Refunds could be initiated by the platform, by merchants for their own transactions, or by both. Similarly, chargebacks can be centrally handled by platforms, by merchants directly through the PSP, or by an external provider. Centralised handling gives the platform more control and consistency, while merchant-managed processes can work better when sellers own the customer relationship. 

Payouts

Once a payment is collected, the platform needs to specify when sellers receive their funds. Payouts can happen shortly after settlement, on a fixed schedule, or delayed based on factors such as the seller's risk profile or the transaction type. 

The choice comes down to balancing seller experience and risk. Faster payouts improve liquidity for sellers, while delayed payouts give the platform more time to manage refunds, chargebacks, and other potential losses. When choosing a PSP, you should consider which payout model you need, including whether the provider supports the payout timing and controls the platform needs. 

Platform and marketplace fraud risk starts before the first transaction

Fraud prevention shouldn’t stop on the customer side of the payment flow. A marketplace may need to assess sellers during onboarding and continue monitoring after activation, particularly where fraudulent merchants can create significant refund, chargeback, or reputational risk. 

Distinguishing buyer fraud prevention and merchant risk management is a must. Buyer screening focuses on a transaction’s legitimacy. Merchant screening asks whether the business is legitimate and whether it should be allowed to access the marketplace and receive payouts. 

Depending on the business model, merchant risk controls can include KYC/KYB, sanctions screening, fraud checks, bank-account verification, and ongoing monitoring. KYC/KYB establishes who the merchant is, while fraud controls assess if it presents an unacceptable risk to the platform. 

Marketplace: a system of interdependent decisions

The most useful way to design a marketplace payment model is to define the business model first and then work through the decisions that follow, like which PSP you should use. 

The first point should be the seller model, as it determines much of the onboarding and KYC/KYB requirements. Aspects to consider include:

• who can sell, 
• where they are located, 
• what legal entities are permitted, 
• and their relationship with the platform. 

The next step is fund flow, namely:

• who receives the customer's money, 
• whether funds are held, how they are split, and when sellers are paid, 
• and whether reserves or delayed payouts are required. 

From there, the platform can define the commercial model:

• commissions, 
• additional platform fees, 
• payment processing fees, 
• refund costs,
• and chargeback costs. 

Afterwards, it can determine the operational model:

• who manages refunds and disputes, 
• who provides reporting, 
• and whether sellers use the PSP dashboard or the platform's own portal. 

Finally, the regulatory and liability analysis needs to align with the actual money flow and responsibilities. 

As these decisions are closely connected, changing one can force changes elsewhere. 

Platform and marketplace design: a practical framework

A platform can use the following questions to structure the initial assessment: 

Area	Key question
Business model	Who sells to the customer?
Seller model	Who can become a seller?
KYC/KYB	Who verifies and monitors sellers?
Fund flow	Who receives and controls the money?
Payouts	When and how are sellers paid?
Risk	Who bears financial risk for refunds and chargebacks?
Commercial model	Who pays fees?
Refunds	Who can initiate refunds?
Disputes	Who handles chargebacks?
Payment experience	Who manages payment operations?
Fraud	Are sellers screened as well as buyers?

The key is therefore defining the business and payment model before selecting the PSP. When the platform, sellers, buyers, and PSP relationships are clear and established, technical, functional, and regulatory requirements become much easier to map. The PSP can then be selected against these requirements, not forcing the business model to fit the provider's capabilities.  

For a new marketplace, this approach prevents costly redesign later, while for an established platform, it can highlight where the current setup creates unnecessary cost, operational complexity, or regulatory exposure. This is what we specialise in at reMonetary: helping platforms and marketplaces structure their payment requirements, evaluate the relevant options and select a payment architecture and PSP that fit both their current needs and long-term roadmap. 

This article is part of The Paypers’ Explainers section. To access other educational materials from this section, click here. If you have suggestions about other topics that could be included in this section, we invite you to write to us at editor@thepaypers.com. 

About the author

Milko Filipov is Managing Director at reMonetary and specialises in payment architecture, PSP selection, and navigating complex payment setups. His expertise covers marketplaces, platforms, billing and subscription models, regional compliance, and global payment expansion. reMonetary helps enterprises of all sizes structure their payment requirements, evaluate the right solutions, and design payment architectures that support their current needs and long-term growth.