Paddle vs Lemon Squeezy 2026: Merchant of Record GDPR Risk and the Missing EU-Native Option

Post #932 in the sota.io EU Cyber Compliance Series | EU-PAYMENT-SERIE Post #5

The Merchant of Record model is attractive to SaaS developers for a straightforward reason: you offload the complexity of global VAT collection, sales tax compliance, payment disputes, and fraud management to a platform that becomes the legal seller of record. You ship the software, the MoR handles the billing infrastructure and the regulatory surface area. This simplification is real and valuable.

The GDPR and CLOUD Act complications, however, are also real. The two dominant MoR platforms in the SaaS developer ecosystem — Lemon Squeezy and Paddle — have very different legal structures, and neither one provides EU-native data sovereignty. The situation with Lemon Squeezy changed materially in January 2024, in a way that most developers using the platform have not fully registered.

What Merchant of Record Means for Data Flows

When you use a Merchant of Record, the MoR becomes the contractual party between your customer and the payment transaction. This affects data flows in specific ways:

Your customer's data flows through the MoR. Name, email address, billing address, card details or bank account, purchase history, IP address at time of purchase — all of this is processed by the MoR, not by you directly. The MoR establishes its own relationship with your customer's payment data.

You receive a subset of that data. The MoR provides you with a customer record sufficient for your application — typically an email address, a customer ID, and subscription status. The raw payment data stays with the MoR.

The MoR is a data controller for payment data, not just a processor. This is legally significant. A data processor acts on your instructions. A MoR makes independent decisions about how to process payment data: fraud scoring, dispute resolution, refund handling, tax calculation. These are controller-level decisions. The MoR is a joint controller or an independent controller for payment data, which means you cannot fully govern its processing via your own Privacy Policy.

Article 26 GDPR applies. When two or more organisations jointly determine the purposes and means of processing, they must enter into a joint controller arrangement under GDPR Article 26. The practical implication: your customers have the right to exercise their rights against the MoR directly, and the MoR's legal jurisdiction governs how those rights are handled.

Lemon Squeezy: Stripe Acquired It in January 2024

Lemon Squeezy launched in 2020 as an independent, developer-friendly MoR. The pitch was elegant: clean API, reasonable pricing, SaaS-first features, no enterprise minimums. It accumulated a significant following among indie developers and small SaaS teams.

In January 2024, Stripe acquired Lemon Squeezy. The acquisition was not initially widely covered outside of developer news sites. Lemon Squeezy continued to operate under its own brand with its own interface. The original founders remained involved. The developer experience did not change significantly. Many developers who adopted Lemon Squeezy in 2021 or 2022 have not re-evaluated the legal structure since the acquisition.

The legal structure changed completely.

Lemon Squeezy is now a Stripe subsidiary. Stripe Inc. is incorporated in South San Francisco, California. The CLOUD Act — codified at 18 U.S.C. § 2713 — requires US persons and US-incorporated entities to produce stored data on demand when served with a valid US government order, regardless of where the data is physically stored.

What this means in practice:

When your EU customer pays for your SaaS through Lemon Squeezy, their payment data — card details, IBAN if applicable, billing address, purchase history — flows through Stripe's infrastructure. The same CLOUD Act exposure that applies to Stripe Atlas, Stripe Billing, and Stripe Connect applies to Lemon Squeezy. The interface is different. The legal entity controlling the data is the same.

The Standard Contractual Clauses problem: Lemon Squeezy (as Stripe subsidiary) offers SCCs as the Article 46 GDPR transfer mechanism for EU data. As established by the Court of Justice of the EU in Schrems II (C-311/18, July 2020), SCCs cannot override a government's lawful access authority under its own jurisdiction. The SCCs do not prevent a US court order from compelling Stripe/Lemon Squeezy to produce EU customer payment data.

Payment data is in the highest GDPR risk tier. Transaction records reveal financial behaviour — what your customers purchase, when, how often, at what amount. Combining purchase history with IP addresses and billing addresses can enable profiling under GDPR Article 4(4). Article 22 restrictions on automated decision-making apply when payment data is used for creditworthiness assessment or fraud scoring.

If you adopted Lemon Squeezy because it was an independent alternative to Stripe, you should know that it is no longer independent. The data controller for your customers' payment data is Stripe Inc.

Paddle: UK Company, Not EU

Paddle was founded in London in 2012. It is incorporated as Paddle.com Market Ltd in England and Wales. The company listed on NASDAQ in 2023 under the ticker PDDLE, but the legal entity incorporating the business and governing its data processing obligations is registered in the United Kingdom, not in the United States.

This is a legally meaningful distinction. Paddle is not subject to the CLOUD Act in the same way that Stripe or Lemon Squeezy is. A US government CLOUD Act warrant issued against a non-US entity operating outside the US reaches a legal boundary. The UK has its own bilateral data access treaty with the US (the CLOUD Act bilateral agreement, signed 2022), but the procedural requirements under that agreement are different from domestic CLOUD Act enforcement.

However, Paddle is not EU-incorporated. The United Kingdom left the European Union in January 2021. Since Brexit:

• UK companies are not subject to EU GDPR directly. They are subject to UK GDPR — the UK's retained version of EU GDPR, maintained under the UK GDPR and the Data Protection Act 2018.
• Data transfers from the EU to the UK are governed by the EU's adequacy decision for the UK, granted in June 2021 under Article 45 GDPR.
• The UK adequacy decision is not permanent. It was granted with a sunset clause subject to review. Ongoing divergence between UK and EU data protection law could lead to the adequacy decision being revisited. The UK government has signalled interest in diverging from EU data protection standards in some areas.

The Investigatory Powers Act 2016 (IPA). The UK has its own broad surveillance legislation. The IPA grants UK intelligence agencies and law enforcement authorities expansive powers to obtain communications data and content from UK-incorporated entities. The IPA was one of the factors the EU examined when assessing UK adequacy. The European Data Protection Board noted concerns about the IPA's scope in its opinion on UK adequacy.

Five Eyes intelligence sharing. The UK is a member of the Five Eyes intelligence sharing arrangement alongside the US, Canada, Australia, and New Zealand. Intelligence obtained by UK agencies — including data obtained from UK-incorporated entities — may be shared with US partners. This is not a CLOUD Act mechanism, but it is a risk factor for organisations with elevated threat models.

Paddle's DPA and SCCs. Paddle offers a Data Processing Agreement and standard contractual clauses for EU data transfers under Article 46. The analysis is parallel to Stripe: the DPA governs Paddle's contractual obligations, but it cannot override the UK government's access authority under the IPA.

Paddle vs Lemon Squeezy: Jurisdiction Comparison

Neither option is EU-native. The distinction matters for risk tolerance, not for compliance certainty.

What Merchant of Record Means Specifically for GDPR

The MoR model creates several GDPR-specific obligations that developers frequently underestimate.

Transparency obligations (Articles 13 and 14). Your Privacy Policy must disclose the data controller relationship with your MoR. If Paddle or Lemon Squeezy is a joint controller, your customers must be informed. If customers exercise data subject rights related to payment processing — access, erasure, portability — you must coordinate with your MoR, and your MoR's capability to respond within the GDPR's 30-day window governs your compliance.

Erasure and the MoR's retention obligations. MoRs are required to retain financial records for regulatory purposes — tax law, anti-money-laundering regulations, PSD2 audit requirements. When a customer submits an erasure request under Article 17, your MoR can and likely will invoke Article 17(3)(b) — the legal obligation exception — to retain payment records beyond the erasure request. You must disclose this in your Privacy Policy.

Profiling and fraud scoring. MoRs conduct fraud scoring using payment behavioural data. Under GDPR Article 22, automated decision-making that produces legal or similarly significant effects requires either explicit consent, necessity for contract performance, or national law authorisation. The fraud scoring your MoR performs on your customers may require disclosure and, depending on outcome (transaction declined), may trigger Article 22 rights.

PSD2 Article 94 interaction. PSD2 Article 94 restricts how payment data collected for payment services can be used for other purposes — specifically, marketing analysis and price comparison services are excluded unless the user has given explicit consent. If your MoR uses payment behavioural data for purposes beyond payment processing — personalisation, analytics, product improvement — PSD2 Article 94 constrains that processing independently of GDPR.

The EU-Native MoR Gap

There is no EU-incorporated, EU-native Merchant of Record platform with comparable developer experience to Paddle or Lemon Squeezy. This is a genuine market gap, not an oversight.

The existing EU-registered payment infrastructure options — Mollie, Adyen, SumUp, Mangopay — are payment processors or payment service providers, not Merchants of Record. They process payments on your behalf, but you remain the merchant of record. You are responsible for your own VAT registration, tax collection, dispute handling, and compliance obligations across each jurisdiction you sell into.

FastSpring (Santa Barbara, California) is a US-incorporated MoR. Not EU-native.

Digital River (US subsidiary of South Korean Hana Financial Group, but US-incorporated and CLOUD Act exposed). Not EU-native.

2Checkout/Verifone Commerce (US-incorporated). Not EU-native.

Gumroad (US-incorporated). Not EU-native.

EU SaaS Developer Options in Practice

Practical Options for EU SaaS Developers Who Want Sovereignty

If EU-native data sovereignty for payment data is a requirement — either because of your customers' procurement policies, your sector's regulatory environment, or your own risk assessment — the Merchant of Record model currently has no EU-native solution.

Option A: Paddle with documented risk acceptance. Paddle is the closest available option. UK jurisdiction, no CLOUD Act, UK adequacy decision for EU transfers. You must document the transfer basis in your ROPA (Records of Processing Activities under Article 30), note the UK adequacy decision as the Article 45 mechanism, and assess the residual IPA risk against your specific threat model. For most commercial SaaS — as opposed to high-sensitivity sectors like healthcare, legal, or finance — this is a workable trade-off.

Option B: EU payment processor + DIY tax compliance. Use Mollie or Adyen as your payment processor. Register for VAT in the jurisdictions where you have significant customers (or use EU One-Stop Shop VAT for B2C). Handle your own dispute management and refunds. This retains full EU sovereignty over payment data, but you absorb the operational complexity of the MoR model yourself. It is viable for teams with engineering capacity. It is operationally burdensome for solo developers.

Option C: Stripe/Lemon Squeezy with comprehensive Article 46 documentation. If you are already using Stripe or Lemon Squeezy, the practical path is to document the SCC basis fully, conduct and document a Transfer Impact Assessment, implement supplementary measures (encryption, pseudonymisation), and ensure your Privacy Policy accurately describes the data controller relationship. This is not EU sovereignty, but it is defensible compliance under current law.

Option D: Wait. The EU payment infrastructure market is developing. PSD3 consultation is ongoing. Fintech-native EU MoR operators may emerge. The current gap reflects the regulatory complexity of building a MoR business under EU financial services law — EMI licences, AML obligations, cross-border VAT infrastructure — rather than a permanent market failure.

What to Include in Your Privacy Policy and ROPA

If you use Paddle or Lemon Squeezy, your privacy documentation should accurately reflect the legal structure.

For Lemon Squeezy (post-2024):

• Disclose that payment processing is handled by Stripe Inc. (Lemon Squeezy, a Stripe company)
• Document the transfer basis: Article 46 SCCs (Stripe's DPA)
• Conduct a Transfer Impact Assessment documenting your assessment of CLOUD Act risk against your specific use case
• Note that financial records are retained by Stripe for regulatory purposes beyond your control

For Paddle:

• Disclose that payment processing is handled by Paddle.com Market Ltd (UK)
• Document the transfer basis: Article 45 adequacy decision (UK adequacy, Decision 2021/1772)
• Note the UK adequacy decision's review status and document your monitoring plan
• Note that financial records are retained by Paddle for regulatory purposes (UK HMRC, anti-money-laundering)

For your ROPA under Article 30:

• Document MoR as a joint controller or independent controller for payment processing activities
• Record the legal basis for processing (Article 6(1)(b) — contract performance)
• Document the retention period: your MoR's legally mandated retention (typically 7-10 years for financial records) will exceed your product data retention

The Infrastructure Hosting Layer

One consideration that the MoR debate often does not surface: your application hosting is a separate data sovereignty decision from your payment processing.

Paddle and Lemon Squeezy handle payment data. Your application handles customer personal data at the product layer — usage data, account information, product content, support communications. These two data flows have independent sovereignty profiles.

If you host on Vercel (Vercel Inc., San Francisco), Render (Render Inc., San Francisco), Railway (Railway Corp., Delaware/US), or Fly.io (Fly.io Inc., Delaware/US), your application-layer personal data is in US-incorporated infrastructure even if your payment layer is on Paddle (UK).

EU-native managed PaaS — platforms that host on EU infrastructure with no US parent company — provide sovereignty at the application layer independently of your MoR choice. You can have an EU-native application host while using Paddle as your UK-based MoR, giving you the best available combination short of a non-existent EU-native MoR.

This separation matters for your ROPA documentation: the payment data controller (Paddle or Stripe/Lemon Squeezy) and the application data controller (your application host) are separate entries with separate transfer bases and separate retention schedules.

Summary

Lemon Squeezy is no longer an independent platform. It is a Stripe subsidiary. Developers who chose it as a non-Stripe alternative are now using Stripe infrastructure with a different interface. The CLOUD Act exposure is the same.

Paddle is a UK company, not an EU company. It provides better data sovereignty than Stripe/Lemon Squeezy for EU customers — no CLOUD Act, UK GDPR jurisdiction with an EU adequacy decision — but it is not EU-native and it is subject to the UK Investigatory Powers Act.

There is no EU-incorporated Merchant of Record platform with developer-grade APIs and SaaS-first features. This gap is real and documented. The nearest EU-native alternative requires assembling a payment stack from EU-regulated PSPs (Mollie, Adyen) and handling the tax and compliance complexity that MoRs normally absorb.

For EU SaaS developers, the honest assessment is: Paddle is the least-bad available MoR option. Document your choice in your Privacy Policy and ROPA. Understand what the UK adequacy decision covers and its review timeline. Treat the absence of a true EU-native MoR as a risk to monitor rather than a solved problem.

This article is part of the sota.io EU-PAYMENT-SERIE: Stripe EU Alternative | PayPal EU Alternative | Mollie vs Adyen | PSD2 + GDPR Guide | Paddle vs Lemon Squeezy