synthrek

What disclosures Stripe, PostHog, Supabase, and OpenAI typically require in your privacy policy (with example wording)

A vendor-by-vendor walk-through of which data Stripe, PostHog, Supabase, and OpenAI handle, the processor entries each vendor's own docs ask you to include, and example wording you can adapt for your own privacy policy.

checklist confidence medium Published May 20, 2026
Educational content, not legal advice. Consult counsel for production policies. Sample wording is a starting point; review the official requirement before publishing.
Sources S-006S-011S-012S-013S-004

If you’re shipping an indie SaaS in 2026 there is a high chance your stack includes some subset of: Stripe for payments, Supabase for auth and database, PostHog for analytics, and OpenAI (or Anthropic) for an LLM feature. Each of those vendors expects you to disclose them in your privacy policy and on the platform-specific privacy surfaces. This post walks through the four most common, using each vendor’s own primary documentation as the source.

TLDR

For each vendor you typically need:

  1. A processor entry naming the vendor’s legal entity and country.
  2. A description of which data the vendor handles.
  3. A purpose statement (payments, authentication, analytics, AI inference, etc.).
  4. A link to the vendor’s published privacy policy.

The exact wording is up to you (and ideally counsel). The examples below are starting points drawn from each vendor’s own public documentation, not legal advice.

Stripe

Stripe’s privacy policy and DPA describe Stripe as a processor for the payment data your app collects. Stripe handles card data, billing addresses, and fraud signals; you handle the customer record that ties a Stripe customer ID back to your user.

Example processor entry (adapt to your policy):

Stripe Payments Europe, Ltd. (registered in Ireland) and Stripe, Inc. (registered in Delaware, USA) process payment information on our behalf, including cardholder data, billing address, transaction history, and fraud-prevention signals. Their privacy practices are documented at https://stripe.com/privacy. Stripe acts as a payment processor and, where applicable, a controller for its own anti-fraud and regulatory obligations.

Where this entry shows up:

  • Privacy policy “Third parties / processors” section.
  • Apple Privacy Details: Purchases (Purchase History), Financial Info (Payment Info), and Identifiers (User ID, where you link Stripe Customer to your user ID).
  • Google Data Safety: Financial info — Purchase history, Payment info — Collected and shared.
  • GDPR Art. 28 record of processing activities entry.

Supabase

Supabase publishes a privacy and security overview and a separate DPA. Supabase, Inc. is the data processor; you (the app developer) are the data controller. Supabase’s surface area covers anything you write into Postgres tables, anything you upload to Storage, and the auth identities created by Supabase Auth.

Example processor entry:

Supabase, Inc. processes the data we store in our database, file storage, and authentication service on our behalf. Their data practices are documented at https://supabase.com/privacy. The data we store with Supabase includes account email addresses, user identifiers, hashed passwords or OAuth tokens, and the application data described in this policy.

Where it shows up:

  • Privacy policy: processor list + the regional residency you chose at project creation.
  • Apple Privacy Details: Contact Info (Email), Identifiers (User ID), and whatever columns your app stores.
  • Google Data Safety: Personal info (Email, User IDs) and any columns that store user content.
  • Cookie banner: Supabase Auth sets a session token in local storage or a cookie. Functional session storage is typically exempt from consent requirements under most local guidance, but session-replay or analytics cookies need a banner.

PostHog

PostHog’s privacy policy and DPA describe PostHog Inc. (US) and PostHog B.V. (EU). The data each PostHog Cloud region handles is the same shape — the difference is where it physically sits.

PostHog’s surface area is wide: every event you track, the distinct_id you identify users by, any session-replay recording (if enabled), and feature-flag evaluations. The session-replay surface is the most sensitive — it captures real DOM activity in your app.

Example processor entry:

PostHog Inc. (US) — or PostHog B.V. (EU), depending on your cloud region — processes product-analytics data on our behalf, including event names, custom event properties, the distinct_id we assign to each authenticated user, and (where enabled) session-replay recordings of the in-app UI. Their data practices are documented at https://posthog.com/privacy.

Cookie & consent specifics:

  • PostHog’s web SDK sets ph_* cookies by default.
  • Session replay should mask sensitive elements; PostHog publishes DOM masking guidance (accessed 2026-05-25).
  • EU traffic typically requires a consent banner before PostHog fires; verify against current guidance from your DPA or counsel.

OpenAI

OpenAI’s API data usage policies and privacy policy describe how OpenAI handles user inputs. As of OpenAI’s 2023 policy change (still in effect on the API as of access date 2026-05-25), API inputs and outputs are not used to train OpenAI models by default, although they may be retained for limited periods for abuse monitoring.

Example processor entry:

OpenAI, L.L.C. processes user inputs sent to OpenAI’s API on our behalf for the purpose of generating responses inside our [feature name]. Their data practices are documented at https://openai.com/policies/api-data-usage-policies. Per OpenAI’s published API policies as of [access date], API inputs are not used to train OpenAI models. Inputs may be retained by OpenAI for a limited period for abuse and misuse monitoring.

Where it shows up:

  • Privacy policy: processor entry + a paragraph explaining what your AI feature does with user input.
  • Apple Privacy Details: User Content — Linked to user, used for App Functionality.
  • Google Data Safety: Messages or App info → Other actions, Collected and shared.
  • GDPR: OpenAI is a US entity; reference the Standard Contractual Clauses in OpenAI’s DPA.

Note. OpenAI’s policies, retention windows, and API surface change. The entry above is a starting point — the moment OpenAI publishes a new policy version, re-read the linked pages and update your processor entry.

A reusable structure

For each vendor, write four short pieces:

  1. Identity line — entity name, country, link to their privacy policy.
  2. Data line — exact categories your app sends to them.
  3. Purpose line — why your app uses them.
  4. Cross-reference line — which Apple Privacy Details / Google Data Safety rows the vendor populates, and whether they trigger a cookie banner.

That structure carries over to Resend, Sentry, Mixpanel, Cloudflare, and anything else. The Indie App Privacy Disclosure Matrix is the side-by-side view of 12 such vendors.

FAQ

Do I need to list every vendor? Under GDPR Art. 13 / 14 you must disclose the categories of recipients of personal data. Most policies list the specific processors by name — naming helps users exercise their data-subject rights. The GDPR text is the source.

What if I switch from OpenAI to Anthropic? Re-author the processor entry, swap the data-usage link (https://www.anthropic.com/legal/commercial-terms and the DPA), and update the same rows on the Apple and Google forms.

Can I just copy this wording into my policy? The wording above is a starting point drawn from each vendor’s public docs. The right wording depends on what your app actually does. Have counsel review the policy before publishing.

Sources cited

S-006, S-011, S-012, S-013, S-004. Each source row is listed in the full disclosure matrix .

Useful next step

Open the Indie App Privacy Disclosure Matrix for a side-by-side view of which platforms expect which disclosures for the services in your stack.