All entries
Chapter VIII
Journal · 21 Oct 2026 · 11 min read

Stripe Connect vs Adyen for Platforms: Who Pays?

Stripe Connect charge types vs Adyen splits vs Mangopay wallets: who carries refunds and chargebacks, and when a UK marketplace needs FCA authorisation.

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 ConnectAdyen for PlatformsMangopay
Seller's funds sit inA connected account balanceA balance account per account holderAn e-money wallet per user
Platform takes its cut withapplication_fee_amount or transfer_data[amount]A split with type CommissionFees on a wallet-to-wallet transfer
One payment, several sellersSeparate charges and transfersSeveral BalanceAccount splitsOne transfer per seller wallet
Losses by defaultDepend on charge type and controller.losses.paymentsThe platform's liable balance accountNot stated; your fee is reversed on chargeback
Documented cap on holding seller funds (UK)90 days on manual payouts20 business days of settlementDelayDaysNone; 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

DirectDestinationSeparate charges and transfers
Charge created onConnected accountPlatformPlatform
Statement descriptorConnected accountPlatform, or seller with on_behalf_ofPlatform, or seller with on_behalf_of
Stripe fees paid byConfigurablePlatformPlatform
Refunds and disputes debited fromConnected accountPlatformPlatform
Connected accounts per charge11Many

The details that catch teams out:

  • Destination charges take transfer_data[destination] plus either application_fee_amount or transfer_data[amount], both capped at the charge amount. A refund does not claw money back from the seller by default. You pass reverse_transfer=true, and refund_application_fee=true if you are returning your fee too; Stripe will not refund the fee without reversing the transfer. Disputes debit the platform with or without on_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_of changes 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_group purely as a label. source_transaction is 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_payments capability 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 typelosses.paymentsfees.payerrequirement_collectionstripe_dashboard.type
Standardstripeaccountstripefull
Expressapplicationapplication_expressstripeexpress
Customapplicationapplication_customapplicationnone

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_balances lets Stripe debit the seller's bank account. It defaults to false for Custom accounts and true otherwise. UK accounts qualify; debit cards do not.
On Adyen the liable balance account is the backstop for negative user balances, and your 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: settlementDelayDays inside platformPaymentConfiguration runs 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.
A 30-day "release after delivery" promise fits inside Stripe's 90 days. It does not fit inside 20 business days of Adyen settlement delay, roughly four calendar weeks. Check the FCA's line on escrow platforms before building either.

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.