Compliance

GDPR and Subscriber Data in RevenueCat: What a Compliance Review Actually Covers

6 min read | RevenueCat · Compliance

This is not legal advice, and if that caveat feels repetitive across our compliance-adjacent posts, that’s deliberate — we build the technical layer and flag where a lawyer needs to sign off, we don’t replace one. Unlike our piece on HIPAA-adjacent HealthTech apps, GDPR isn’t vertical-specific: any subscription app with users in the EU or UK is processing personal data through its billing layer, regardless of what the product does.

1. What’s Actually Personal Data Here

Subscriber identifiers and purchase history

Even a pseudonymous app user ID tied to purchase and entitlement history is personal data under GDPR once it can identify a specific person — which, combined with an email address for receipts, it usually can.

Data flowing to every connected integration

If RevenueCat events feed an analytics tool, an email platform, or a data warehouse, each of those is a separate place the same personal data now lives — each needs its own accounting.

Data retention after cancellation

A cancelled subscriber’s data doesn’t need to disappear immediately — legitimate interests like fraud prevention and accounting can justify retention — but “we kept it because we always do” isn’t a policy, it’s the absence of one.

2. What a Review Actually Checks

Usually already in order

Store-level purchase securityHandled by Apple/Google

Payment card dataNever touches your systems

Worth an explicit check

Data processing agreements w/ integrationsPer-vendor

Deletion request handlingCross-system

3. Deletion Requests Are the Practical Sticking Point

A GDPR deletion request is straightforward to honor in one system and genuinely awkward across several. If RevenueCat data has been piped into an analytics tool, a CRM, and a data warehouse, “delete this user’s data” means deleting it in four places, not one — and proving you did, if ever asked. This is worth designing for explicitly: know which systems hold subscriber-linked data before a request arrives, not while you’re scrambling to answer one within the regulatory deadline.

Where this differs from the HealthTech piece

GDPR applies by user location, not by product vertical — a fitness app, a productivity tool, and a health app with EU subscribers all have the same baseline obligation. Our HealthTech compliance piece covers additional, vertical-specific obligations layered on top for health data specifically — treat this post as the baseline every subscription app needs, and that one as what health products need in addition.

Taking a subscription app into European markets?

Tell us your current data flows — RevenueCat plus whatever else touches subscriber data — and we’ll map what a review should cover.

Start the Conversation →

Engineering Insights

Latest from Syntaxa Studio.

Loading latest posts

View All Articles