Marketplace & Platform Payments

This determines whether the customer is buying from the platform or directly from the seller. It shapes how the customer relationship and payment flow are structured.

For example, when buying an item on eBay, the customer generally thinks of themselves as buying from an individual seller, even though eBay provides the marketplace and payment experience. Amazon can work differently: customers often think they are buying from Amazon itself, while some products are sold by third-party sellers operating through Amazon. In another model, a customer may purchase a course directly from what appears to be a standalone e-learning business, without knowing that the business uses a platform such as Thinkific behind the scenes to provide the website, payments, and other infrastructure.

These examples illustrate why the visible customer experience does not necessarily tell us who owns the payment or who is responsible for the transaction behind the scenes. When designing the architecture, we should therefore be explicit about who the customer should perceive they are buying from.

This determines whether the platform holds and manages customer funds before paying sellers, or whether payments are routed directly to sellers. This choice mainly affects the platform's responsibilities and how the payment flow is structured.

From a legal and compliance perspective, controlling customer funds can make the platform subject to payment-services regulation. In the EU, PSD2 covers the receipt and forwarding of funds as a payment service unless a specific exclusion applies. The EBA has specifically stated that an e-commerce platform receiving payment on behalf of sellers is not automatically outside PSD2. In the US, the equivalent question is typically whether the platform is acting as a money transmitter under FinCEN rules and applicable state money-transmitter laws. The classification depends on the actual flow and contractual model, with exemptions available for certain payment-processing activities. Some PSPs specialize in structuring these flows so that the regulated payment activities, safeguarding, and compliance obligations are handled by the PSP, reducing the regulatory and operational burden on the platform.

The Merchant of Record (MoR) is the legal seller in the transaction. This determines who takes responsibility for the sale and the related obligations.

For example, when buying a product directly from a brand's website, the brand is typically the MoR. In a marketplace, the seller may be the MoR even though the customer interacts mainly with the marketplace. Alternatively, the platform itself may act as the MoR, selling the product or service to the customer and then paying the seller their share. Uber is a good example of why this distinction matters: its MoR and payment model can differ depending on the market and service. In some markets, Uber acts as the seller and collects the customer's payment before paying the service provider, while in others it acts more as an intermediary or payment collection agent for the provider. The MoR therefore defines who is legally standing behind the sale, not simply who processes the payment.

This determines who bears the financial responsibility when a customer requests a refund or raises a chargeback. The responsibility can sit with the platform, the seller, or be shared between them.

Refunds and chargebacks are often underestimated when designing the payment flow, but they are important for building a stable architecture and managing risk. The key question is who ultimately bears the financial impact when a payment is reversed. The architecture should ensure that there are sufficient funds to cover refunds and unexpected chargebacks, without creating negative balances for the platform or sellers. This may require coordinating chargebacks with payout timing, delaying payouts, maintaining reserves, or defining who covers a shortfall when the seller no longer has sufficient funds.

This determines how sellers are brought onto the payment setup and who handles the onboarding process.

PSPs require merchants to be verified because they need to know who is receiving or accepting payments through their infrastructure and assess whether the business and its owners can be supported from a regulatory and risk perspective. Depending on the merchant and the payment capabilities being enabled, this can include verifying the individual's identity, the legal business and registration details, beneficial owners and controllers, the business activity, and screening for sanctions and AML risks. Airwallex, for example, requires identity verification for connected accounts and adds a separate business verification step when a connected account acts as Merchant of Record and accepts payments through its gateway. The exact information and checks vary by country, business type, payment methods and risk profile, so verification may also continue after initial onboarding through requests for additional information.

The architectural decision is how much of this process to automate and embed into the platform versus relying on the PSP. For platforms onboarding a large number of merchants, building and operating this functionality themselves can require significant development and ongoing operational effort, which can often be reduced by using the PSP's hosted, embedded, or API-based onboarding and verification capabilities.

This determines who collects merchant information and manages the KYC/KYB process when sellers join the platform.

KYC/KYB can be a required part of this process, depending on the payment model. It can be handled by the PSP or by the platform itself using an integrated KYC/KYB provider such as Sumsub or IDnow. The architectural decision is therefore how much of the onboarding and verification process the platform wants to own versus delegate to the PSP or a specialised provider.

KYC/KYB does not end with merchant onboarding. This determines who monitors regulatory changes and collects updated merchant information when requirements change.

Merchant information may need to be reviewed or updated when the business changes, when ownership or control changes, or when regulatory and risk requirements require additional checks. This can include updated company details, beneficial owners, identification documents, and sanctions or AML screening. At scale, managing these checks internally can become a significant operational and financial cost.

The architectural decision is therefore who is responsible for monitoring these changes, requesting updated information, and triggering re-verification when required.

This determines which types of sellers can join the platform, such as companies, sole proprietors or individuals. This choice affects how seller onboarding and payments need to be structured, particularly across different countries.

PSPs often have different requirements for companies, sole proprietors, and private individuals because each has a different legal and ownership structure. This affects the information and documents required for verification, the level of KYC/KYB checks, and sometimes whether the PSP can support that seller type at all. These requirements can also vary by country.

This determines how a payment is divided between the platform and other recipients, such as sellers or service providers. It mainly depends on whether the splitting is handled by the payment provider or by the platform itself.

The standard approach for platforms and marketplaces is to use the PSP's built-in splitting and fund-routing capabilities. This reduces the complexity of handling payment allocation internally. In rare cases, a platform may have a specific reason to implement the splitting and payout logic and execution itself, but this should be a deliberate architectural choice with a clear rationale. In such cases, the PSP selection may include a broader range of providers that are not specifically focused on marketplace or platform payments.

This determines whether sellers manage their payment activities through the PSP's dashboard or through the platform's own portal. It affects how much of the payment experience the platform owns.

If the merchant does not control the funds, whether they can access the PSP directly depends largely on the PSP's account model and permissions. In some models, the merchant does not have direct access to the PSP at all, and payment management is handled through the platform. In other setups, merchants may have their own account with the PSP, allowing them to log in directly to the PSP's website or dashboard using their own credentials.

For marketplaces, using the PSP's merchant-facing capabilities can reduce the functionality the platform needs to build, but may introduce a media break where merchants have to leave the platform to manage their payments. Keeping payment management within the platform provides a more seamless experience, but requires more functionality to be built and maintained by the platform. A compromise approach is to use embedded components provided by the PSP.

This defines the countries and regions in which the platform will be active and where it will allow sellers and customers to participate.

For platforms and marketplaces, geographic coverage is more complex than simply checking whether a PSP supports a particular country. PSPs may have one set of supported countries for the platform itself and a different set for the countries in which its sellers can be onboarded. In addition, the available payout countries and supported payout currencies can impose further limitations on the countries and currencies that can be used. These differences are typically driven by local regulatory requirements in each market.

This defines the currencies in which prices can be presented, payments can be accepted and sellers can be paid out.

The platform needs to define which presentment currencies it will support based on its target markets, and assess the countries in which its merchants operate and the payout currencies they require. The available options will depend on the platform's regional setup and the capabilities of the selected PSP, so some compromises may be necessary. Where the payment and payout currencies differ, currency conversion may be required. The architecture should therefore clearly define where the conversion takes place, who is responsible for it, and how the associated conversion fees are handled.

This determines how payment-related costs are allocated between the platform, sellers and customers.

The platform or the merchants ultimately need to bear the costs of payment processing, and this decision is usually closely connected to the chosen fund flow and who controls the funds. It is an important business-model decision because payment costs can directly affect the platform's margins and the pricing offered to merchants. There are several approaches, including passing through the actual transaction costs, adding a markup to each transaction, charging fixed or tiered fees, bundling payment costs into a subscription, or generating revenue through a revenue-sharing model with the PSP.

Because payment pricing can involve many different fees and can be difficult to make fully transparent, many platforms choose to absorb the underlying payment costs and offer merchants a simple, fixed or predictable fee structure. This makes the merchant proposition easier to understand, while allowing the platform to manage the complexity of the underlying PSP costs and potentially build payment revenue into its business model.

This defines how and when funds are released to sellers, including payout timing, delays and any reserves applied for risk management.

Payout timing should be designed together with the fund flow and risk model. Platforms may pay sellers immediately, on a fixed schedule, after a defined delay, or once a defined reserve threshold has been met. Delaying payouts can provide time to handle refunds, chargebacks, cancellations, or other risks before funds leave the platform or PSP-controlled balance. The architecture should therefore define not only when sellers are paid, but also whether the platform or PSP controls the payout timing, whether reserves or minimum balances are required, and who bears the risk if a seller's available balance is insufficient.