Stripe Connect vs Mangopay 2026: EU Marketplace Payments, Art.28 GDPR, and Platform PSP Obligations

Post #933 in the sota.io EU Cyber Compliance Series | EU-PAYMENT-SERIE Post #6

Building a marketplace means you are not just a merchant — you are an intermediary between buyers and sellers. The payment infrastructure you choose for a marketplace carries materially different legal obligations than a simple one-sided checkout. You are routing other people's money, holding funds in escrow, disbursing payouts to counterparties whose identity you must verify under AML law, and processing financial data about parties who are not your direct customers.

The two dominant platforms for marketplace payments in the European developer ecosystem are Stripe Connect and Mangopay. They approach the problem from fundamentally different legal foundations: one is a US-incorporated product that operates in Europe through a Dublin-registered subsidiary; the other is an EU-licensed e-money institution incorporated in Luxembourg.

The distinction matters under GDPR Article 28, PSD2 Article 85, and the EU Anti-Money Laundering framework. This guide explains why.

Marketplace Payments vs Standard Merchant PSP

A standard payment service provider processes payments between your business and your customers. You are the merchant of record. Money flows from buyer to you.

A marketplace payment platform processes payments where your platform intermediates between multiple buyers and multiple sellers. The flow is fundamentally different:

Buyer pays → your platform holds funds → platform disburses to seller (minus your fee)

This three-party structure introduces distinct regulatory obligations:

E-money institution licensing. Holding funds on behalf of sellers — even briefly — typically requires an e-money institution licence under EU E-Money Directive 2009/110/EC (EMD2) or a payment institution licence under PSD2. Without this licence, holding third-party funds creates regulatory exposure for your platform.

KYC/AML on sellers, not just buyers. You must know who you are paying out to. EU AML Directive 6 (6AMLD) requires identification of both parties to a transaction above certain thresholds. For platform operators, this means performing KYC on your seller base — not just verifying buyer card details.

Escrow and holding wallet requirements. Funds held pending disbursement must be safeguarded. This is a specific regulatory requirement: client funds must be segregated from the platform's own funds, typically in dedicated safeguarding accounts at EU-regulated credit institutions.

Art.26 GDPR joint controller considerations. When your platform and your PSP both make determinations about how to process seller and buyer data — KYC decisions, fraud scoring, payout eligibility — both may be data controllers. Article 26 GDPR requires a joint controller arrangement if both parties jointly determine purposes and means.

Stripe Connect: The CLOUD Act Architecture

Stripe, Inc. is incorporated in South San Francisco, California. It is subject to the US CLOUD Act (18 U.S.C. § 2713), which requires US persons and US-incorporated entities to produce stored communications and records on demand when served with a valid US government order — regardless of where the data is physically stored.

Stripe operates in the EU through Stripe Payments Europe, Limited, incorporated in Dublin, Ireland. This is a wholly owned subsidiary. The EU entity is the contractual party for EU merchants, and it holds a payment institution licence under PSD2 issued by the Central Bank of Ireland.

The CLOUD Act problem does not dissolve at the subsidiary level. The CLOUD Act targets US persons and US entities. The ultimate parent — Stripe, Inc. — is a US person. Courts interpreting the CLOUD Act have affirmed that parent-company control over subsidiary data means a US government order can compel the parent to produce data held by a foreign subsidiary. The legal test is not where the entity is incorporated; it is whether the US parent has practical control over the records.

The ECJ confirmed this analysis in its Schrems II (C-311/18, July 2020) ruling: SCCs cannot override a national government's lawful access authority under its own law. Stripe offers SCCs as the Article 46 GDPR transfer mechanism for EU data. Those SCCs do not prevent a US government demand served on Stripe, Inc. from reaching data that flows through Stripe Payments Europe, Ltd.

What Flows Through Stripe Connect

When you integrate Stripe Connect for a marketplace, the following data categories flow through Stripe's infrastructure:

Buyer data. Card number (tokenised), billing address, IP address at time of purchase, email address, purchase amount, timestamp. This is standard payment data for any Stripe integration.

Seller/connected account data. This is the more extensive category for Stripe Connect:

• Legal name, date of birth (for natural persons)
• Business name, registration number, VAT number (for legal entities)
• Bank account details (IBAN/sort code/account number) for payouts
• Identity documents: passport, national ID, driving licence (Stripe's KYC requirements)
• Tax identification numbers
• Business category and described activities
• Payout history and transaction records

This seller data is substantially more sensitive than buyer data. It includes government-issued identity documents and banking credentials. All of it flows through Stripe, Inc.'s infrastructure subject to the CLOUD Act.

GDPR Article 28 and Stripe Connect

GDPR Article 28 governs controller-processor relationships. When you use Stripe Connect, the data protection analysis is not straightforward:

For buyer payment processing: Stripe acts as a data processor on your instructions. You determine what to collect; Stripe processes it. Article 28 DPA applies.

For seller KYC and onboarding: Stripe acts as an independent data controller. Stripe determines whether a seller passes KYC, sets identity verification thresholds, makes fraud decisions, and can independently decline to onboard or terminate a seller account. These are controller-level determinations. Stripe is not following your instructions — it is applying its own risk policies.

The Article 26 question. When Stripe and your platform both make independent determinations about seller data (Stripe: KYC pass/fail, fraud scoring; your platform: seller eligibility, product category restrictions), both may be joint controllers under Article 26. The practical implication: your sellers have rights they can exercise against Stripe directly, under Stripe's privacy policy and Stripe's jurisdiction — which includes the US CLOUD Act exposure.

Article 28(3)(a) limitation. Under GDPR, a processor may only process data "on the documented instructions from the controller." For Stripe Connect's seller KYC functions, Stripe does not act on your instructions — it acts on its own regulatory judgement. This is a structural tension in the Article 28 DPA that EU data protection authorities have scrutinised in similar contexts.

PSD2 Article 85 and the Platform Exemption

PSD2 Article 85 provides a limited exemption for platforms that operate payment systems but do not hold funds themselves. The platform exemption applies when:

1. The platform acts solely as a commercial agent for one of the parties (buyer or seller, not both simultaneously)
2. The platform does not at any time hold funds belonging to payers or payees
3. The platform's role is purely referral or distribution, not active funds management

Most actual marketplaces do not qualify for the Article 85 exemption. If your platform temporarily holds buyer funds pending confirmation of goods delivery, or if you hold seller payouts pending a release trigger, you are holding funds. This typically requires an e-money institution licence or reliance on a licensed PSP that holds the funds on your behalf under their own licence — which is exactly what Stripe Connect and Mangopay both provide, through different legal structures.

Mangopay: EU-Licensed E-Money Institution

Mangopay S.A. is incorporated in Luxembourg (Avenue du Rock'n'Roll 3, Belval, Luxembourg) and holds a full e-money institution licence issued by the Commission de Surveillance du Secteur Financier (CSSF), Luxembourg's financial regulator. Its EU Passporting rights extend the licence across all EU/EEA member states.

Luxembourg is an EU member state. Mangopay processes and stores data within the European Economic Area. There is no third-country transfer mechanism required — no SCCs, no adequacy decision dependency. The data stays in the EU.

The CLOUD Act does not apply to Mangopay. Mangopay S.A. is incorporated under Luxembourg law. It has no US parent company. The CLOUD Act targets US persons and US-incorporated entities. Mangopay is neither. A US government demand has no legal hook into Mangopay's infrastructure.

Mangopay's Architecture for Marketplaces

Mangopay was built specifically for marketplace and platform use cases, not retrofitted from a one-sided payments product. Its core architecture:

E-wallets. Mangopay creates a wallet for every user — both buyers and sellers — within your marketplace. Funds are held in these wallets, which are legally safeguarded client funds under Mangopay's e-money licence. Your platform does not need its own e-money licence because Mangopay's licence covers the fund-holding activity.

Pay-in / Transfer / Pay-out flow. The canonical Mangopay flow:

1. Buyer pays-in (card, bank transfer) → funds credited to buyer's Mangopay wallet
2. Platform executes an internal transfer → funds move from buyer wallet to seller wallet (minus your platform fee, which can be split off automatically)
3. Seller requests pay-out → funds transferred from seller Mangopay wallet to seller's bank account

All three operations are native Mangopay API calls. The escrow period (funds held in buyer wallet pending delivery confirmation) is natively supported without your platform needing separate safeguarding arrangements.

KYC under Mangopay's CSSF licence. Mangopay performs seller KYC as part of its licensed obligations under Luxembourg AML law (implementing 6AMLD). Sellers submit identity documents to Mangopay; Mangopay makes the KYC determination. This is a controller-level function — Mangopay is an independent data controller for KYC data.

The difference from Stripe Connect: Mangopay's KYC data controller activity operates under EU law (Luxembourg, CSSF-regulated). Your sellers' KYC documents are processed by an EU-licensed institution under EU regulatory supervision, not under California law subject to CLOUD Act.

GDPR Article 28 and Mangopay

For payment processing: Mangopay acts as a data processor for transaction execution on your instructions. Article 28 DPA applies.

For KYC: Mangopay acts as an independent controller (under its own CSSF licensing obligations). Article 26 joint controller arrangement applies for overlapping processing purposes.

The EU-law difference. Both Stripe Connect and Mangopay are independent controllers for KYC. The jurisdictional difference is decisive: Mangopay's controller activities are governed by Luxembourg law, CSSF regulation, and GDPR directly. Stripe Connect's controller activities are governed by California law with US CLOUD Act exposure sitting over the top.

Compliance Comparison

The Art.28 Downstream Processor Obligation in Practice

If you run a marketplace and your sellers are data subjects whose data flows through your platform to your PSP, you have a chain of data processing obligations:

1. You as controller → enter Art.28 DPA with your PSP
2. PSP as processor → enters sub-processing agreements with its own sub-processors
3. PSP as independent controller (for KYC) → Art.26 joint controller arrangement with you

For Stripe Connect: your Art.28 DPA is with Stripe Payments Europe, Ltd. (Dublin). That entity is wholly owned by Stripe, Inc. (California). The KYC controller activity sits with Stripe, Inc. directly — not the EU subsidiary. Your Art.26 arrangement with Stripe for KYC data is effectively with a US-incorporated entity subject to the CLOUD Act.

For Mangopay: your Art.28 DPA is with Mangopay S.A. (Luxembourg). The KYC controller activity also sits with Mangopay S.A. Your Art.26 arrangement is with an EU-incorporated, CSSF-regulated entity. There is no US parent with CLOUD Act exposure in the chain.

The practical documentation requirement. Under GDPR Article 28(3)(e), your DPA must specify that the processor (PSP) assists you in ensuring compliance with Articles 32–36. For marketplace payments, this includes:

• Data breach notification timelines (Art.33: 72 hours to supervisory authority)
• DPIA assistance when processing high-risk financial data (Art.35)
• Deletion and return of data at contract termination (Art.28(3)(g))

Both Stripe Connect and Mangopay provide DPA templates. The Stripe DPA is governed by Irish law (Stripe Payments Europe Ltd jurisdiction); the Mangopay DPA is governed by Luxembourg law. Both are GDPR-compliant on their face. The difference is the controller-level KYC exposure above the DPA layer.

When Stripe Connect Is Still Defensible

Not every EU marketplace project has an absolute requirement for EU-native PSP jurisdiction. Stripe Connect remains defensible when:

You process no sensitive personal data beyond standard payment fields. If your marketplace involves low-value digital goods with no financial risk profiling, the practical CLOUD Act exposure is lower.

Your sellers are incorporated legal entities, not natural persons. Corporate KYC (business registration documents, VAT numbers) carries less individual privacy risk than natural-person KYC (passport, national ID). The CLOUD Act exposure exists in either case, but the individual rights risk is reduced.

You have a documented Transfer Impact Assessment (TIA). GDPR Chapter V requires you to assess whether the third-country legal framework undermines SCC protections. For Stripe Connect, a properly documented TIA should acknowledge the CLOUD Act risk and your mitigation (SCCs + supplementary measures). The TIA does not eliminate the risk but demonstrates due diligence.

Your DPA is with a controller in a country with an EU adequacy decision. Stripe Payments Europe Ltd is incorporated in Ireland, an EU member state. The operational data controller for EU transactions is the Irish subsidiary, not the US parent. The weakness is that Stripe, Inc. maintains practical control over the subsidiary's infrastructure and records — which is the CLOUD Act exposure pathway.

Migration Considerations

If you are currently on Stripe Connect and evaluating Mangopay, the migration involves more than an API swap:

Wallet architecture. Stripe Connect manages funds through connected account balances, not dedicated wallets. Mangopay uses per-user e-wallets with explicit pay-in/transfer/pay-out operations. Your payment flow logic requires a meaningful rewrite, not just endpoint substitution.

KYC process. Stripe and Mangopay have different KYC requirements, acceptance thresholds, and document formats. Your seller onboarding flow needs to be rebuilt around Mangopay's KYC API.

Payout scheduling. Stripe Connect offers instant payouts, scheduled payouts, and manual disbursements. Mangopay has similar options but with different timing guarantees and bank transfer rails. Test EU SEPA payout latency in your target market before migrating.

Existing connected accounts. Sellers already onboarded and verified on Stripe Connect will need to complete fresh KYC with Mangopay. This is a non-trivial friction point for your seller base. Plan for re-verification churn.

Pricing model difference. Stripe Connect pricing is transaction-percentage plus per-payout. Mangopay pricing is also transaction-based but with different per-transaction floors and monthly minimum structures for lower-volume platforms. Compare total cost of ownership at your expected transaction volume.

The sota.io Angle

If you run your marketplace infrastructure on sota.io, the platform's EU-native architecture means your application layer processes no data outside EU jurisdiction by default. Combined with Mangopay for the payment layer, you achieve a fully EU-native stack:

• Application hosting: EU infrastructure, no CLOUD Act exposure
• Payment processing: Luxembourg e-money institution, no CLOUD Act exposure
• KYC data controller: CSSF-regulated Luxembourg entity, no CLOUD Act exposure

For B2B SaaS marketplaces selling to EU enterprise buyers or regulated industries (fintech, healthtech, legaltech), this stack allows you to represent EU data sovereignty end-to-end — including the payment layer — which is increasingly a procurement requirement from EU enterprise procurement teams.

Summary

Stripe Connect and Mangopay both solve the marketplace payment problem technically. The regulatory difference is structural, not operational:

Stripe Connect routes your marketplace through a Delaware-incorporated US parent with CLOUD Act exposure over all seller KYC data, even when processed by its Irish EU subsidiary. Your Art.26 KYC joint controller relationship is effectively with a US entity. SCCs are your transfer mechanism; they do not override CLOUD Act obligations.

Mangopay is an EU-incorporated, CSSF-licensed e-money institution. Seller KYC data stays in the EU under Luxembourg regulatory supervision. There is no US parent and no CLOUD Act hook. Your Art.26 KYC arrangement is with an EU entity under EU law.

The choice is not primarily about features. Both platforms support split payments, escrow, automated payouts, and KYC. The choice is about which legal framework governs your sellers' identity documents and financial records — and whether your marketplace can represent EU data sovereignty to your customers.

For EU marketplaces with regulatory-sensitive seller bases (financial services, healthcare, professional services) or with EU enterprise buyers who perform vendor due diligence, the jurisdictional difference is material. For EU marketplaces with lower regulatory sensitivity, Stripe Connect remains operationally viable with a properly documented TIA and Art.26 arrangement.

This post is the sixth in the sota.io EU-PAYMENT-SERIE. Previous posts cover Stripe EU Alternative, PayPal EU Alternative, Mollie vs Adyen, PSD2 + GDPR Combined Compliance Guide, and Paddle vs Lemon Squeezy.