On a Stripe destination charge, a chargeback is debited from the platform's balance, even when the seller shipped the goods and the platform never touched them. On a direct charge, the same chargeback lands on the seller. One parameter decides who eats the loss, and most marketplace teams choose it in their first week, from a docs page that recommends it for unrelated reasons.
The pages that rank for "Stripe Connect vs Adyen" compare pricing and review scores. None puts Stripe's charge types next to Adyen's splits and Mangopay's wallets at API level, and none asks the UK question underneath: if your platform collects money for sellers, is that a regulated payment service? Field names below were checked against the docs on 21 October 2026.
Stripe Connect vs Adyen for Platforms vs Mangopay: The Short Version
All three let a platform take a buyer's payment, keep a commission and pay the seller without the platform holding client money in its own bank account.
| Stripe Connect | Adyen for Platforms | Mangopay | |
|---|---|---|---|
| Seller's funds sit in | A connected account balance | A balance account per account holder | An e-money wallet per user |
| Platform takes its cut with | application_fee_amount or transfer_data[amount] | A split with type Commission | Fees on a wallet-to-wallet transfer |
| One payment, several sellers | Separate charges and transfers | Several BalanceAccount splits | One transfer per seller wallet |
| Losses by default | Depend on charge type and controller.losses.payments | The platform's liable balance account | Not stated; your fee is reversed on chargeback |
| Documented cap on holding seller funds (UK) | 90 days on manual payouts | 20 business days of settlementDelayDays | None; payouts gated by KYC level |
Stripe makes you choose a charge type, Adyen wants a split instruction, and Mangopay hands you wallets. Each moves liability somewhere specific.
Does a Marketplace Need FCA Authorisation in the UK?
The law shapes the architecture. The Payment Services Regulations 2017 exclude payments made through a commercial agent (Schedule 1, Part 2, paragraph 2(b)), but only an agent authorised by agreement to negotiate or conclude the sale "on behalf of either the payer or the payee but not both".
The FCA reads that narrowly. PERG 15.5 Q33A describes the platform that acts for both sides: it takes the buyer's money into an account it controls, that payment does not settle the buyer's debt to the seller, and the platform then pays the seller under its own agreement with the seller. The authority must be real, meaning the ability to bind the principal; supplying the technical means for placing orders does not count. Escrow-style platforms are flagged as likely to need authorisation.
That rules out the obvious home-made design, where buyers pay into the platform's bank account and the platform pays sellers every Friday. Unless you genuinely buy and resell as principal, that is a payment service.
The marketplace products exist to move this obligation onto a licensed firm. The seller is onboarded as the provider's own user: a Stripe connected account, an Adyen account holder with a legal entity, a Mangopay user with a wallet. Mangopay S.A. is a Luxembourg e-money institution supervised by the CSSF, and its UK entity got an FCA e-money licence in November 2023. Whether your own flows still leave you in scope is a question for a lawyer, not an API reference.
UK vs EU Commercial Agent Rules in 2026
PSD2's operative text always said one side only, though its recital 11 suggested a two-sided agent could stay excluded if it never held client funds. The FCA follows the operative text. The EU is now going further. The Payment Services Regulation final compromise (Council document 8221/26, 17 April 2026) keeps the exclusion in Article 2(2)(b) only if the agent acts for one side and its agreement gives it "real scope to negotiate" or conclude the sale. The new recital 11 applies that test regardless of whether the agent holds client funds, and Article 2(7) asks the EBA for guidelines within a year of entry into force. ECON approved the text on 5 May 2026, the indicative plenary date is 14 December 2026, and it is not yet in the Official Journal. I covered the wider text in the PSD3 and PSR guide.
The UK is not following for now. HM Treasury's Modernising Payment Services Regulation consultation (14 July to 6 October 2026) says the government intends to "broadly replicate" the Schedule 1 activities, and its 43 pages never mention commercial agents.
Stripe Connect Charge Types: Direct vs Destination vs Separate Charges and Transfers
| Direct | Destination | Separate charges and transfers | |
|---|---|---|---|
| Charge created on | Connected account | Platform | Platform |
| Statement descriptor | Connected account | Platform, or seller with on_behalf_of | Platform, or seller with on_behalf_of |
| Stripe fees paid by | Configurable | Platform | Platform |
| Refunds and disputes debited from | Connected account | Platform | Platform |
| Connected accounts per charge | 1 | 1 | Many |
The details that catch teams out:
- Destination charges take
transfer_data[destination]plus eitherapplication_fee_amountortransfer_data[amount], both capped at the charge amount. A refund does not claw money back from the seller by default. You passreverse_transfer=true, andrefund_application_fee=trueif you are returning your fee too; Stripe will not refund the fee without reversing the transfer. Disputes debit the platform with or withouton_behalf_of, and you recover from the seller with a transfer reversal. If an asynchronous payment method fails, Stripe reverses the transfer for you. on_behalf_ofchanges more than the descriptor. The charge settles in the connected account's country, at that country's fees, and payouts follow that account's delay. Leave it out and the platform is the business of record.- Separate charges and transfers use
transfer_grouppurely as a label.source_transactionis the parameter that matters: it lets a transfer succeed before the charge's funds are available and executes it once they are. It is fixed at creation, and several transfers can share one charge up to its amount. Refunding the charge does not touch the transfers, and a failed asynchronous payment does not reverse them. Stripe recommends this type only when the platform is liable for negative balances. Cross-border transfers work between the US, Canada, the UK, the EEA and Switzerland. - Direct charges need the
card_paymentscapability and always settle in the connected account's country. Stripe does not recommend them for legacy Express or Custom accounts.
Stripe Standard vs Express vs Custom Accounts After Controller Properties
The three account types are now shorthand for four controller properties:
| Legacy type | losses.payments | fees.payer | requirement_collection | stripe_dashboard.type |
|---|---|---|---|---|
| Standard | stripe | account | stripe | full |
| Express | application | application_express | stripe | express |
| Custom | application | application_custom | application | none |
The newer Accounts v2 API (POST /v2/core/accounts) replaces types with configurations (merchant, customer, recipient) and moves liability into defaults.responsibilities.losses_collector, set to application or stripe. It rejects a platform that carries losses while Stripe collects fees. On v1, requirement_collection=application cannot be paired with losses.payments=stripe: if you own onboarding, you own the losses.
On UK pricing, Connect is free when sellers pay Stripe directly. If you set the pricing yourself, it costs £2 per monthly active account (one that received a payout that month) and 0.25% + 10p per payout, with Instant Payouts at 1%.
How Do Adyen for Platforms Split Payments Work?
Adyen's Balance Platform models each seller as an account holder with a balance account, a verified bank account (transfer instrument) and a legal entity for KYC. Your platform has a liable account holder and a liable balance account, and that is where trouble goes by default.
You split at authorisation by sending a splits array on /payments:
{
"amount": { "currency": "GBP", "value": 10000 },
"reference": "order-8841",
"splits": [
{
"type": "BalanceAccount",
"account": "BA00000000000000000000001",
"amount": { "currency": "GBP", "value": 8800 },
"reference": "seller-8841"
},
{
"type": "Commission",
"amount": { "currency": "GBP", "value": 1200 },
"reference": "commission-8841"
}
]
}
The valid type values in Checkout API v71 are AcquiringFees, AdyenCommission, AdyenFees, AdyenMarkup, BalanceAccount, Commission, Default, Interchange, PaymentFee, Remainder, SchemeFee, Surcharge, Tip, TopUp and VAT, plus MarketPlace for Classic integrations. Names such as PaymentFeeAcquiring turn up in older examples and are not in the v71 enum. Commission and VAT book to the liable balance account, and BalanceAccount splits need both account and reference.
The constraint a press release would never mention: Adyen validates only the format of split instructions. If the balance account does not exist or its holder is closed, the whole amount, fees included, lands in your liable balance account. A typo in a seller ID is not an error response. It is money in the wrong place until reconciliation catches it.
Refunds and chargebacks follow their own rules. A full refund without splits is deducted by the authorisation's split ratio; for partial refunds Adyen strongly recommends sending splits. Chargebacks follow platformChargebackLogic.behavior, which takes deductFromLiableAccount, deductFromOneBalanceAccount (with a targetAccount) or deductAccordingToSplitRatio. Chargeback fees go to costAllocationAccount, which defaults to the liable account. You can set the logic on /payments, /sessions or /captures, and the capture value wins. One asymmetry matters for your ledger: when you win a dispute, the reversal is credited to the liable account, even if you debited the seller. Moving it back is your job.
How Does Mangopay Handle Marketplace Fees and KYC?
Mangopay is the most literal of the three: every user gets a wallet, and the platform's cut is a field on the transfer between wallets.
POST /v2.01/{ClientId}/transfers
{
"AuthorId": "buyer_142",
"DebitedFunds": { "Currency": "GBP", "Amount": 10000 },
"Fees": { "Currency": "GBP", "Amount": 1200 },
"DebitedWalletId": "wlt_buyer_142",
"CreditedWalletId": "wlt_seller_77"
}
Fees is mandatory, so send zero when there is none. The seller's wallet receives DebitedFunds minus Fees, here 8,800 pence, and the 1,200 goes to an automatically created Fees Wallet per currency. Only Mangopay pays that wallet out, during its billing cycle, which matters if you model commission as cash you can spend today. Fees are reversed on chargeback, and pay-ins to virtual IBANs cannot carry fees at all.
The KYC rules carry the real constraint. Users are a PAYER or an OWNER, at KYCLevel LIGHT or REGULAR. Through Mangopay S.A. in the EEA, a LIGHT user cannot pay out at all, and since 1 July 2026 new EEA integrations cannot transfer into a LIGHT owner's wallet, or take pay-ins unless FlowDescriptor.Beneficiaries lists only verified users. Through Mangopay U.K., a LIGHT owner can pay out up to €150 per rolling month (the limits page quotes it in euros) before verification is required. Mangopay's docs never call this escrow. A wallet balance is just a balance.
Who Pays for Refunds and Chargebacks on a Marketplace?
When a chargeback pushes a seller's balance negative, the provider needs a backstop. On Stripe, liability follows controller.losses.payments: stripe for Standard accounts, application (you) for Express and Custom. When you are liable:
- Stripe first offsets the negative against the account's future payments, and pays nothing out while the balance is negative.
- It holds a reserve on the platform's available balance (
reserve_transaction), kept for three business days after a bank debit posts. - After 180 days negative, it moves platform funds to bring the account to zero (
connect_collection_transfer). debit_negative_balanceslets Stripe debit the seller's bank account. It defaults tofalsefor Custom accounts andtrueotherwise. UK accounts qualify; debit cards do not.
platformChargebackLogic decides whether the seller is touched at all. On Mangopay, the fee reversal is automatic. Whether a dispute is winnable at all is a card-scheme question, covered in the chargeback reason codes guide.
How Long Can a Marketplace Hold Seller Funds in the UK?
Buyer protection depends on holding funds, and the providers set hard limits:
- Stripe: UK accounts get their first payout after 7 calendar days, then 3 business days by default. On manual payouts you can hold funds for up to 90 days in the UK (two years in the US). Stripe says it provides no escrow service.
- Adyen:
settlementDelayDaysinsideplatformPaymentConfigurationruns from 1 to 20 business days (1 needs approval) and cannot be combined with managed payouts. - Mangopay: no documented cap. Funds stay in the wallet until a payout is requested and KYC allows it.
Opinion: Choose the Loss Model Before the Provider
My view: most UK marketplace teams choose a provider on pricing, then discover their loss model in the first dispute wave. Do it the other way round.
First, if buyers think they are buying from your brand, they will dispute against you whatever the API says. Destination charges without on_behalf_of are the honest fit: you are the business of record, you absorb disputes, and you price commission to cover them. Direct charges suit software platforms where the seller is the brand, such as booking tools for salons or gyms.
Second, do not design around the commercial agent exclusion. The UK test is one-sided, and the FCA's own example of a two-sided platform describes the home-made setup I come across most often. The EU test adds "real scope to negotiate", which a platform with standard terms and seller-set prices will struggle to show. If the December plenary holds, the PSR applies 21 months after entry into force, so on my arithmetic not before late 2028. My prediction is that once the EBA guidelines land, provider-held funds will be the only defensible default for any platform selling into both the UK and the EU.
What This Means for Marketplace Engineers in the UK
1. Write the loss model down first. Who pays refunds, disputes, dispute fees and negative balances? Map each answer to losses.payments or losses_collector, to Adyen's platformChargebackLogic, or to Mangopay's fee reversal.
2. Store the charge type on every payment in your ledger. Destination charges refund with reverse_transfer=true, separate charges need explicit transfer reversals, and Adyen partial refunds need splits.
3. Reconcile Adyen's liable balance account daily. Misrouted splits and won dispute reversals both land there silently. The Stripe vs Adyen reconciliation guide covers the report fields.
4. Do not treat commission as cash on Mangopay. The Fees Wallet pays out on Mangopay's billing cycle, not yours.
5. Check the holding cap against your buyer-protection window before you sign.
6. If you sell into the EU, design for the PSR test now. Technical order-taking powers will not carry the exclusion there.
Marketplace payments look like a provider choice. They are a liability model with a provider attached. I'm Tom Wang, and I would rather settle who eats a chargeback in a design doc than in a board meeting.