Skip to main content

Is My Customer Data Secure? (GDPR and Privacy)

A
Written by Andreas H

Data security is about how Churn.io stores, protects, and limits access to the information that flows through your cancel flows — both your own account details and the subscriber data Churn.io sees when someone tries to cancel. This article explains what data Churn.io handles, how it's protected, and what that means for your GDPR and privacy obligations.

What customer data Churn.io handles

When a subscriber goes through one of your cancel flows, Churn.io records a session so you can see what happened and measure your save rate. A session can include:

  • The subscriber's email address, current plan, and billing interval.

  • Their monthly recurring revenue (MRR) so you can see the value of saves and cancellations.

  • The cancellation reason they selected and any written feedback they left.

  • Which retention offer (if any) they accepted.

  • A reference to the matching subscription in your connected payment processor, used to apply offers or process the cancellation.

All of this data is scoped to your business. Sessions, feedback, and analytics are only ever visible to members of the business they belong to — never shared across other Churn.io accounts.

Your payment processor credentials are encrypted

When you connect Stripe, the access Churn.io uses to read subscriptions and apply offers is stored encrypted at rest. These credentials are write-only: once saved, they're never displayed back in the app or returned in any response. Only Churn.io's servers can decrypt them, and only to carry out the actions your flows require.

💡 You stay in control of access

Because the connection is made through Stripe's own authorization flow, you can revoke Churn.io's access from your Stripe dashboard at any time, and only an Owner or Admin can connect or disconnect a payment processor.

Protection in transit and in logs

Data moving between your browser, the cancel flow, and Churn.io's servers is protected in transit. On top of that, sensitive values are deliberately kept out of Churn.io's internal logs:

  • Passwords, authentication tokens, confirmation codes, and payment card details are automatically masked before anything is written to a log.

  • Your payment processor credentials are masked the same way.

  • Responses from sensitive areas — sign-in, password reset, billing, and payment-processor connection — are never written to logs in full.

Anonymous identifiers for experiments

When you run an A/B test between flows, Churn.io needs to consistently show the same subscriber the same variant. To do this without storing extra identifying data, it converts the subscriber's identity into a one-way fingerprint that cannot be reversed back into an email or customer ID. In your session logs, only the last few characters of that fingerprint are ever shown.

Cancel-page links and outbound notifications

If you use the hosted cancel page, each personalized link is single-use and expires. Once a session is completed or the link's window has passed, that link stops working — so a forwarded or stale URL can't be reused to view someone's details.

If your flow sends a cancellation notification to your own systems, Churn.io validates the destination first and refuses to send to internal, private, or local network addresses. This prevents your notification settings from being used to reach anything other than a legitimate public endpoint you control.

⚠️ You remain the data controller

For GDPR purposes, the subscriber data that passes through your cancel flows is data you control. Churn.io processes it on your behalf to run your flows and analytics. Make sure your own privacy policy and customer notices cover the use of a cancellation tool, and only collect the feedback and fields you actually need.

Keep what you collect to a minimum

A simple way to reduce your privacy footprint is to only ask for what you'll use. When you build a flow, consider:

  • Keeping survey reasons short and avoiding open feedback fields if you don't plan to read them.

  • Not requesting free-text feedback that could prompt subscribers to share sensitive personal information.

  • Reviewing your session logs periodically so you know what's being captured.

In short

Your customer data is handled carefully: payment processor credentials are encrypted and never shown again, sensitive fields are masked in logs, A/B test identities are one-way and unreadable, hosted cancel-page links expire, and outbound notifications are restricted to safe destinations. The data your flows collect is scoped to your business and yours to control — so pair these protections with a clear privacy policy and sensible data minimization to stay aligned with GDPR.

Did this answer your question?