Payment Architecture for Multi-Sided Platforms: Split Payments, Payouts and Compliance

A platform launched in one market, processed payments through a single provider, and grew to fourteen countries in eighteen months. In month fourteen, they tried to pay out to sellers in Brazil and the Philippines. Their payment provider didn’t support either market. Re-architecting payments on a live platform — with real sellers, real buyers, and real funds in transit — cost them six months of engineering time and two key markets to a competitor who had solved this on day one.

The payment model is not a technical detail to revisit after launch. It determines your compliance burden, your unit economics, and your international roadmap before you write a line of product code. This article covers the four payment models available to multi-sided platforms, how split payments work mechanically, what payouts actually cost, and how to choose a stack that won’t trap you.

This is not legal or financial advice. Get qualified counsel before making payment architecture decisions.

---

The Four Payment Models for Multi-Sided Platforms

Pass-Through (Buyer Pays Seller Directly)

In a pass-through model, the buyer pays the seller directly. The platform facilitates the introduction but is not in the money flow. The platform charges separately — typically via subscription or invoiced commission — rather than taking a cut of the transaction at the point of payment.

This is the simplest model to build and the most limited. The platform has no hold on funds, no ability to enforce a commission at the point of payment, and no recourse when a transaction fails. It works for high-trust B2B categories where sellers invoice buyers and the platform’s value is in the match, not the transaction. It does not work for consumer marketplaces where trust and protection are part of the product.

Liability sits with the seller. The platform has no financial exposure to individual transaction failures.

Aggregator / Payment Facilitator

A payment facilitator (PayFac) is an entity that processes payments on behalf of sub-merchants — in a marketplace context, on behalf of sellers. The PayFac holds the master merchant account with a card network or acquirer and onboards sellers as sub-merchants underneath it.

The platform collects the full buyer payment, deducts its commission and fees, and pays out the remainder to the seller. This is the model Stripe Connect, Adyen for Platforms, and Mangopay operate on — they provide the PayFac infrastructure and the platform uses it.

Becoming your own PayFac requires direct registration with card networks, an underwriting process, and significant ongoing compliance obligations. Most platforms should use a provider that already is a PayFac and let it absorb the regulatory burden.

Liability: platform is liable for chargebacks and refunds on transactions it processes.

Merchant of Record

A merchant of record (MoR) is the entity legally responsible for the sale — the name on the receipt, the entity collecting VAT (Value Added Tax) or GST (Goods and Services Tax), the party liable for chargebacks and refunds. When a platform becomes the MoR, it takes full legal ownership of every transaction on its platform.

Platforms that become MoR typically do so to simplify tax compliance for their sellers (the platform handles all VAT/GST centrally) or to offer a fully branded checkout experience without third-party interruption.

Liability: platform absorbs full liability for all transactions, refunds, chargebacks, and tax obligations.

Marketplace with a Regulated Partner

The most common model for early and growth-stage platforms: partner with a regulated payment provider that acts as the licensed entity, holds funds, and manages compliance, while the platform controls the product experience on top.

Stripe Connect, Adyen for Platforms, Mangopay, and Rapyd all operate this way. The compliance obligations sit primarily with the provider — though the platform still inherits KYC (Know Your Customer) and AML (Anti-Money Laundering) obligations for its seller onboarding.

Liability: shared between platform and provider. The provider handles regulatory compliance. The platform handles product experience and seller verification.

How Each Model Changes Who Is Liable

Pass-through puts liability on the seller. The PayFac model puts chargeback and refund liability on the platform. MoR puts full liability on the platform including tax. The regulated partner model shares liability — the provider handles funds and compliance, the platform handles the product layer.

The model you choose is a liability decision before it’s a technical decision.

Split Payments Explained

Splitting at Capture vs Splitting at Payout

A split payment is one buyer payment divided between multiple recipients — the seller, the platform’s commission, and in some cases, additional parties such as logistics providers or referral partners.

The split can happen at two points: at capture (the payment is split into separate transfers the moment the buyer pays) or at payout (the full amount is captured into a platform account and distributed in separate transfers at a later point).

Splitting at capture is simpler from a ledger perspective but less flexible for platforms that need to hold funds before releasing them. Splitting at payout gives the platform more control over timing and allows it to implement dispute holds before releasing seller funds.

Handling Commission, Taxes and Processing Fees in One Transaction

A single transaction on a marketplace typically involves: the buyer’s total payment, the payment processing fee charged by the provider (typically 1.5-3.5%), the platform’s commission, any applicable taxes, and the seller’s net payout.

Design your commission logic to operate on the net amount after processing fees, not the gross — otherwise your effective margin shrinks at high transaction volumes.

Multi-Seller Carts and Partial Fulfilment

When a buyer purchases from multiple sellers in one checkout, the payment architecture needs to handle splits to multiple recipients from a single capture. Partial fulfilment — one seller ships, another doesn’t — requires partial release logic and a clear buyer-facing view of which part of their order is in what state.

Payouts: The Part Founders Underestimate

Payout Schedules and Their Effect on Seller Retention

How fast sellers get paid is a supply-side retention lever. Sellers on platforms with faster payouts churn less. The trade-off: faster payouts increase exposure to fraud and dispute losses.

Typical payout schedules by category: physical goods, 3-7 days after delivery confirmation; services, 5-14 days after completion; digital goods, 24-48 hours; high-value transactions such as vehicles or B2B contracts, 14-30 days or on explicit buyer acceptance.

Cross-Border Payouts, FX and Local Rails

Paying out to sellers in multiple countries requires currency conversion (FX — Foreign Exchange), access to local payment rails (SEPA in Europe, ACH in the US, UPI in India, PIX in Brazil), and in some markets, local bank account registration.

FX costs are real and often underestimated. A platform paying out $1M per month to sellers in five currencies at a 1.5% FX spread loses $15,000 per month to currency conversion. Evaluate provider FX rates explicitly — they vary significantly between Stripe, Adyen, Rapyd, and dedicated providers like Wise for Business.

Local rails matter for seller activation. A seller in Indonesia who can only receive a SWIFT wire transfer waits 3-5 business days. A seller who receives via local bank transfer gets funds the same day. Payout friction directly affects retention in markets where local rails aren’t supported.

Failed Payouts, Negative Balances and Clawbacks

Payouts fail. Bank account details change. Every platform needs a failed payout handling flow: retry logic, seller notification, a queue for unresolved payouts, and a policy for what happens to funds that can’t be delivered.

Negative balances occur when a seller has been paid out and then a refund or chargeback is processed against a transaction they’ve already received. Your payout logic needs to support balance adjustments and a policy for sellers whose balance goes negative.

KYB / KYC Onboarding Without Killing Seller Conversion

KYB (Know Your Business) and KYC are regulatory requirements for onboarding sellers who will receive payouts. The design challenge: collecting this information without destroying seller activation.

Best practice is progressive verification — collect the minimum required to list, require full verification before the first payout. A seller can list and sell before they’ve fully verified. They cannot receive funds until they have.

Compliance Obligations You Inherit

KYC, AML and Sanctions Screening

Even when using a regulated payment partner, platforms inherit obligations for seller onboarding. You are responsible for ensuring sellers are not on sanctions lists — OFAC (Office of Foreign Assets Control) in the US, OFSI (Office of Financial Sanctions Implementation) in the UK, EU sanctions lists — and for maintaining records that demonstrate due diligence.

PCI DSS: What You Actually Have to Cover

PCI DSS (Payment Card Industry Data Security Standard) governs handling of cardholder data. If your checkout uses a provider’s hosted fields — Stripe Elements, Adyen Drop-in — you operate under the lowest PCI scope and your obligations are minimal. If you build a custom checkout that accepts card numbers directly, your PCI scope increases significantly. Use hosted checkout components.

Tax Reporting Obligations by Region

DAC7 is the EU directive requiring digital platforms to report seller earnings to tax authorities annually. The US equivalent is Form 1099-K. Canada, Australia, and the UK have equivalent frameworks. Build tax reporting infrastructure before you hit the reporting threshold, not after.

SCA and 3-D Secure in the Checkout Flow

SCA (Strong Customer Authentication) is required under PSD2 (Payment Services Directive 2) for card transactions in the European Economic Area. 3-D Secure (3DS) is the implementation mechanism. SCA exemptions exist for low-value transactions (under €30) and transactions flagged as low-risk. Understanding exemptions matters — 3DS adds friction and increases checkout abandonment.

Choosing Your Stack

Stripe Connect, Adyen for Platforms, Mangopay, Rapyd — Where Each Fits

Stripe Connect is the fastest to integrate and the right choice for most platforms at launch. Strong documentation, broad payout coverage, hosted seller onboarding. Limitations: FX rates not best-in-class, limited payout flexibility, thin emerging market coverage.

Adyen for Platforms is more complex to integrate but more flexible at scale. Better FX rates, more local payment methods, stronger high-volume payout support. Minimum volume requirements make it impractical early-stage.

Mangopay is designed specifically for marketplaces. Strong escrow, e-wallet, and multi-currency payout support. Well-suited for European platforms with complex payout logic.

Rapyd specializes in emerging market coverage — Southeast Asia, Latin America, Africa. The right choice when your payout geography includes markets Stripe and Adyen don’t support well.

Ledger Design: Why You Need Your Own, Even With a PSP

A PSP (Payment Service Provider) ledger records what happened at the provider level. Your own ledger records what happened at the business level — which seller earned what, which commission was collected, which dispute was resolved.

Build your own ledger from day one. Every transaction should produce a ledger entry: buyer payment, commission, processing fee, seller payout, adjustments. This is the foundation of your financial reporting and regulatory audit trail. This is a core part of custom software architecture for any serious marketplace platform.

Reconciliation and the Reports Finance Will Ask For

Finance will ask for: daily transaction volumes by currency, commission earned by period, processing fees by provider, payout totals by country, failed payout volumes, and chargeback loss by category. Design reconciliation as a first-class product concern from day one.

Designing the Money UX

Making Fees and Holds Legible to Sellers

Sellers who don’t understand why funds are held become sellers who churn. Every hold, deduction, and fee should be explained at the point it appears — in the interface, not in a terms document.

“Your funds are held for 7 days after delivery confirmation to protect buyers. They’ll be released on [date].” One line. Eliminates a category of support tickets. Reduces churn.

The Seller Balance Screen as a Retention Surface

The seller balance screen is one of the highest-value screens in a marketplace product. Show: pending balance, available balance, payout history, upcoming payout date, and the full calculation — earnings minus commission minus fees — so the seller can verify the math independently.

Failure States: Declines, Holds, Reviews

Payment failures need designed states. A buyer whose card declines should see a specific explanation and clear next step. A seller whose payout is on hold should know why, for how long, and what they need to do. Undesigned failure states are where trust breaks. See how we’ve approached financial UX in fintech platform design.

Conclusion

The payment model you choose before launch determines your compliance burden, your seller retention levers, your international expansion timeline, and your unit economics. Changing it in month fourteen costs more than getting it right in month one.

Start with a regulated partner model using Stripe Connect or Mangopay. Build your own ledger from day one. Design your payout schedule around your category’s dispute window. Plan compliance obligations by the markets you intend to enter in year two, not just the market you’re launching in.

If you’re designing the payment architecture for a marketplace platform and want to pressure-test the model before you build, book a discovery call.

FAQ

• What are split payments in a marketplace?

  A split payment is one buyer payment divided between the seller, the platform’s commission, and any additional fees — all processed in a single transaction. The split can happen at capture (separate transfers the moment the buyer pays) or at payout (funds held in a platform account, then distributed). The choice affects hold logic, dispute handling, and ledger complexity.

• Do I need to be a payment facilitator to run a marketplace?

  No. Most platforms use a regulated payment provider — Stripe Connect, Adyen, Mangopay — that is already a licensed payment facilitator and holds funds on the platform’s behalf. Becoming your own PayFac requires direct card network registration, underwriting, and significant ongoing compliance. The flexibility gain rarely justifies the cost for platforms below significant transaction volume.

• What is a merchant of record and when should a platform become one?

  A merchant of record is the entity legally responsible for the sale — collecting payment, remitting tax, and liable for chargebacks. Platforms become MoR to simplify tax compliance for sellers (the platform handles all VAT/GST centrally) or to gain full control of the checkout experience. MoR status increases liability significantly and requires robust tax infrastructure.

• How much do marketplace payments cost?

  Payment costs have four components: processing fee (1.5-3.5% of transaction value), platform fee charged by your PSP (0.25-0.5% for Stripe Connect standard), payout fee ($0.25-2.00 per payout depending on destination), and FX spread (0.5-2.5% on cross-currency payouts). Total cost per transaction on an international platform commonly runs 2.5-5% before your own commission.

• How fast should sellers get paid?

  Payout speed is a trade-off between seller retention and fraud and dispute exposure. Physical goods: 3-7 days after delivery confirmation. Services: 5-14 days after completion. Digital goods: 24-48 hours. High-value transactions: 14-30 days or on buyer acceptance. The right schedule is the shortest one where your chargeback rate remains within acceptable bounds.

• Can we start with one payment provider and switch later?

  Yes, but only if you own your own ledger and abstract the provider behind your internal payment service. Platforms that build directly against a single provider’s API face a complete re-architecture when they switch. Platforms with their own ledger and a payment abstraction layer can swap providers in weeks. The cost of not doing this is usually discovered in month eighteen when a new market makes the original provider inadequate.