Privacy and Data Handling

Benecaster is built for podcasters who care about doing right by their subscribers. That means being specific about what data the plugin touches, where it goes, and what controls you have over it.

This page documents every category of data Benecaster collects or processes — from subscriber feeds to optional telemetry — and the tools available to you for retention management and right-to-erasure.

---

Data Benecaster Collects

Free Follower Signups

When the [benecaster_follower_signup] shortcode is placed on a page, it presents a sign-up form to any website visitor — no account or payment required. Submitting the form:

• Creates a WordPress user account for the submitted email address (if one does not already exist)
• Generates and stores a feed token for them, recorded with a token type of follower
• Sends a welcome email to the submitted address containing their private RSS feed URL

Fields collected: Email address (required) and display name (optional — the form can be configured to omit the name field via show_name_field="false").

Personal data erasure: A follower’s data is erasable via the standard WordPress user erasure flow combined with TokenRepository::revoke_user_tokens(). The right-to-erasure tool in Settings → GDPR / Privacy covers follower token records alongside paying subscriber records.

Listener Support Donations

Donations are recorded whichever mode you run — see Listener Support Overview for the difference between link mode and Stripe mode.

What is stored: the show, the amount and currency, the platform, a transaction reference, the donor’s email address and message when they provide them, and the date. In link mode these values are supplied by the donor when they return to your site; in Stripe mode they come from the completed payment.

Card details are never stored. In Stripe mode the payment runs through Stripe’s Payment Element and card data goes directly to Stripe — it does not pass through your WordPress database. In link mode no payment touches your site at all.

Donors are usually not WordPress users. Anyone can donate without an account, so donation records often have no user attached to them. That is why donors have their own erasure route, described below — the subscriber erasure tool works by email against subscriber records and will not find them.

You have full access to your donor records. Because donations are stored in your own WordPress database, you can see each donor’s name, email, and message — there is no separate visibility control withholding it from you. Use it for sending a personal thank-you, the same way you would with any other record you hold.

Third-Party Scripts on Your Site

Two Benecaster features load a script from another company’s servers. Neither is loaded on a default install, and neither runs sitewide — but where they do run, the third party sees your visitor’s IP address, so both belong in your cookie and privacy disclosures.

Stripe.js — payments. Loaded when a page renders the subscribe form or the account and billing-portal pages. Stripe sets two cookies:

These are payment security cookies, not advertising cookies. Stripe uses them to recognise repeated card attempts from the same browser. They do not track your visitors across other websites and they are not used to profile or target anyone. A cookie audit that mislabels them tends to end in one of two bad outcomes: a privacy policy that describes tracking you do not do, or a podcaster ripping out payments over a misunderstanding.

Benecaster does not store either cookie and never reads them. They are set by Stripe, in your visitor’s browser, and Stripe is the data controller for them.

Where Stripe.js loads is narrower than people assume, which is useful when writing a cookie policy: the script is registered globally but only enqueued at render time, so it loads only on pages carrying [benecaster_subscribe] or the account and billing-portal pages. Never sitewide, never on episode or archive pages that do not carry one of those.

Cloudflare Turnstile — bot protection. Loaded only if you have enabled Bot Protection by saving both Cloudflare keys. On a default install, and on an install where only one key has been saved, nothing is requested from Cloudflare at all.

When it is enabled, Cloudflare receives the visitor’s IP address and their interaction with the challenge. Turnstile is designed to work without tracking cookies, which is much of why it was chosen, but the IP disclosure is real and you should account for it.

Where it loads depends on the donation style you use:

• With the inline form style, the script loads when a page carrying that form is opened.
• With the button or icon styles — including the auto-injected prompt, which defaults to a button — the script loads only when a visitor clicks to open the donation modal. A listener who never clicks never contacts Cloudflare.

Benecaster does not receive or store anything from the challenge beyond a pass or fail on the donation attempt itself.

No consent banner, and no lazy-load switch. Benecaster does not ship either, for Stripe.js or for Turnstile, and neither is planned. If your jurisdiction requires consent before these load, that is handled by your own consent tooling — the plugin will not do it for you, and you should not assume otherwise from the narrow load conditions above.

Download Log

Download logging is opt-in, not automatic — it only records requests for a show (or episode) where you have turned on download tracking (Details → Show Flags, with a per-episode override on the Media tab). See Download Tracking for how to enable it. For a show or episode where tracking is off, no download-log entry is written at all. Where it’s on, each entry contains:

• Episode reference
• Show reference
• Token reference
• User (subscriber) reference
• Membership tier at time of request
• Hashed IP address (never plaintext — see below)
• Byte range from the HTTP Range header, when present

IP hashing: Raw IP addresses are never stored. Before any log entry is written, the requesting IP is hashed using benecaster_ip_hash_salt. The plaintext IP exists in memory only for the duration of that single request.

If GeoIP enrichment is enabled (see below), the GeoIP lookup also runs before the hash, so the lookup and the hash happen in the same request and the plaintext IP is discarded immediately after both operations complete.

GeoIP Enrichment

When GeoIP is enabled in Settings → Tools → GeoIP Database, Benecaster enriches download log records and subscriber token records with geographic data derived from the requesting IP address.

What is captured and stored:

• ISO alpha-2 country code (e.g., US, GB, DE)
• ISO subdivision/region code (e.g., NY, ENG)

What is read from MaxMind and immediately discarded without storage:

• City name
• Postal code
• Latitude
• Longitude

The two codes are written to two places:

• The download log — a country and region code on each recorded download.
• The subscriber’s token record — a country and region code written once on their first valid feed poll (not updated on subsequent polls).

MaxMind database stays local: The GeoIP database file is downloaded to your server and all lookups run locally. No IP addresses are sent to MaxMind for individual lookups.

To configure GeoIP, see Settings Reference → Tools → GeoIP Database.

Telemetry to the License Server

When you opt in under Settings → Account → Telemetry, Benecaster periodically sends an anonymous usage payload to the Benecaster license server. Opting in is entirely voluntary — both flags default to off.

Sent on every check-in, whether or not you opt in. The daily license validation call carries a minimum payload regardless of your telemetry setting:

These counts are sent whether or not you opt in to telemetry, and the reason is worth knowing. Your plan limits how many active shows and subscribers you can run, and those limits are checked on the license server against the figures your site last reported. Gated behind telemetry opt-in, they would read zero for everyone who opted out — so the limits would not be relaxed for them, they simply would not be evaluated. Bare counts carry no personal data and nothing about who your subscribers are, so they are sent unconditionally rather than leaving your plan’s limits unenforceable.

✅ Your license key is not sent. It is not in the validation payload and not in the failure-alert payload. The request is authenticated by the per-show site token, which is the only credential the license server reads.
Base telemetry (benecaster_telemetry_opted_in), when on, adds:

Revenue telemetry (benecaster_revenue_telemetry_opted_in), when on, additionally includes:

This is an estimate — no payment processor data, no transaction history, no subscriber identity is involved. It’s calculated from numbers Benecaster already has: how many active subscribers you have at each tier, and what pricing is configured for those tiers.

The revenue telemetry checkbox is disabled until the base telemetry checkbox is on. Turning off base telemetry automatically clears the revenue flag server-side.

Transcription add-on, when installed and active, adds a further block — base telemetry must also be on:

Nothing in this block includes transcript content. It reports how much was transcribed and how much editing followed, never what any transcript says.

What is never included in telemetry: subscriber names, emails, IP addresses, episode titles, feed URLs, or any content from your episodes.

Web Player Play Beacon

When the [benecaster_player] shortcode renders on a page, it registers plays via a lightweight unauthenticated beacon: POST /benecaster/v1/analytics/player-play.

This endpoint:

• Increments a per-episode play counter
• Increments a site-wide aggregate play counter
• Does not capture subscriber identity
• Does not store IP addresses (not even hashed)
• Does not log episode titles — the episode is referenced by internal ID only

Plays counted this way are the “Web player play count” field included in base telemetry, if you’ve opted in.

Transcription Service Add-On Telemetry

When the Transcription Service add-on is active and base telemetry is enabled, six additional fields are included in the telemetry payload:

What is never included: transcript text, episode titles, episode IDs, or any content from your audio or transcripts.

---

Subscriber Data Retention

Configurable Retention Window

You control how long Benecaster retains subscriber personal data via Settings → GDPR / Privacy → Subscriber Data Retention. The default is 90 days after a subscription ends.

Covered by the retention window:

• Token records for deactivated subscribers
• Download log rows linked to those subscribers
• Email log rows
• Migration patron records from Patreon/Supercast imports

A nightly cron (benecaster_gdpr_prune, 02:00) automatically purges records older than the window.

What Is Never Pruned

The unsubscribe log is explicitly excluded from retention purges. It records that an unsubscribe event occurred, and is retained indefinitely for regulatory compliance — you need to be able to demonstrate that you honored an unsubscribe request, even after the subscriber’s other records are gone.

Analytics Data Retention

Analytics records — subscriber events, daily aggregates, and the download log — have a separate retention window configured in Settings → Tools → Analytics Data. The default is Forever. This is distinct from subscriber data retention — analytics data may not contain subscriber identity at all (daily aggregates, for example, contain no subscriber references). See Settings Reference → Analytics Data for details on the pruning flow.

Donor Data Retention

Donation records have their own window, set under Settings → Listener Support → Donor data retention. The default is to keep donations forever, and that default is deliberate: donations are financial records, and most podcasters need them for their accounts long after the subscriber data around them has aged out.

Set a window in days and a nightly sweep purges donation rows older than it. Consider your bookkeeping and tax obligations before turning this on — the deletion is permanent, and this is the one retention setting where the shortest window is unlikely to be the right one.

Billing Addresses

Benecaster does not store your subscribers’ billing addresses.

When you enable tax on the built-in membership system, subscribers enter a billing address during checkout — tax has to be calculated from somewhere. That address goes to Stripe and stays there. It appears on the Stripe invoice your subscriber receives, which carries your business details because you are the merchant. Your WordPress site never receives or stores it.

This is deliberate. A home address is more precise than anything else Benecaster keeps — elsewhere the plugin reads a subscriber’s city, postal code and coordinates during a GeoIP lookup and discards all three, retaining only country and region. Keeping addresses would also mean keeping them for years, since tax rules require invoices to be retained long after a subscription ends.

What this means for your privacy policy: you still need to account for the address, because it is collected in the course of your transaction — but you are describing data held by your payment processor, not by your website. Your existing disclosure about Stripe as a payment processor may already cover it. Worth a look rather than an assumption.

See Tax and VAT on Podcast Subscriptions.

---

Right to Erasure

To delete all data Benecaster holds about a specific subscriber:

1. Go to Settings → GDPR / Privacy → Delete a subscriber’s data.
2. Enter the subscriber’s email address.
3. Click Find subscriber — Benecaster shows you a cascade summary listing every category of data and record count that will be deleted.
4. Review the summary and click Confirm deletion.

The cascade covers: tokens, download log, email log, and migration patron records. Unlike the automatic prune, a manual right-to-erasure request also deletes the subscriber’s entry in the unsubscribe log — the indefinite-retention exception applies only to automated pruning.

Deletion is immediate and irreversible. There is no recovery path.

WordPress’s Built-In Export and Erase Tools

Benecaster also registers with WordPress’s own privacy tools, so Tools → Export Personal Data and Tools → Erase Personal Data work for subscribers without you using the dedicated screen above.

Export Personal Data returns everything Benecaster holds tied to the requested email: tokens, subscriber history, membership and subscription records, badges, donations, sent emails, unsubscribe records, and download history.

Erase Personal Data does not treat every category the same way, because some of it is also the podcaster’s own financial or feed-delivery record:

Anonymised means the identifying link (the WordPress user, and any denormalized name or email) is stripped from the row, while the row itself, its timestamps, and its non-identifying counters or state stay in place — this is how a donation or a download count survives an erasure request rather than being removed outright.

Donors Without an Account

The tool above works against subscriber records. A donor who gave without ever creating an account is not a subscriber, so they have a separate, self-service route that verifies their email address before deleting anything:

1. The donor submits their email address — through your “Delete my data” form, or directly to the donor data erasure endpoint.
2. Benecaster replies the same way whether or not that address matches any donation. This is deliberate: a different response for a match would let anyone test addresses to discover who has donated to you.
3. If it does match, Benecaster emails that address a one-time deletion link, valid for 24 hours.
4. The donor clicks the link, confirms on the page it opens, and every donation record for that address is anonymised — their name, email, and any message are cleared, while the amount, currency, and date are kept as your financial record. The link cannot be reused.

Because the confirmation link goes to the address being erased, nobody can anonymise someone else’s donation history by guessing at their email — and you do not have to arbitrate the request yourself.

Developers: the benecaster_donor_data_erased action fires after the cascade, carrying the email and the number of rows anonymised, so you can mirror the change into a CRM or mailing list. See Clean up external records when a donor requests data erasure.

---

Erasing Your Own Data From Benecaster.com

Everything above is about your subscribers’ data, on your WordPress site. Your own account data on benecaster.com — your licence, your invoices, your support history — is a separate request, made by contacting us.

An erasure of your benecaster.com account does not delete everything, and we would rather you know why before you ask.

The right to erasure does not override a legal obligation to keep records, so the financial rows stay — kept whole rather than anonymised, because an invoice that cannot say whose it is is not an invoice. We will tell you exactly what was retained when we action your request. Full detail is in the Privacy Policy.

---

Suggested Privacy Policy Text

Benecaster contributes suggested paragraphs to your site’s privacy policy, one per feature you actually have active — download logging, Listener Support donations (link or Stripe mode), built-in membership, free follower signup, and email logging. A fresh install with everything off contributes nothing.

Find it at Settings → Privacy → Policy Guide (WordPress core’s own privacy policy tool). This text is a starting point, not a finished policy — it is suggested text, and you still own your privacy policy and must review it. Benecaster does not write your privacy policy for you; it drafts the parts that describe what Benecaster itself does, so you don’t start from a blank page for those sections.

Developers: an add-on can append or remove its own {heading, content} entries before the combined text reaches WordPress via the benecaster_privacy_policy_sections filter.

Your Responsibilities

Benecaster provides tooling to help you comply with privacy regulations — configurable retention, manual erasure, GeoIP controls, and telemetry opt-ins. But the plugin cannot guarantee compliance on your behalf. You are responsible for:

• Your site’s privacy policy accurately describing how subscriber data is collected and used.
• Responding to subscriber data requests (access, correction, erasure) within the timeframes required by applicable law.
• Configuring retention windows that match your legal obligations in the jurisdictions where your subscribers live.
• Accounting for the billing address your subscribers give at checkout if you take payment through the built-in membership system. Benecaster does not store it — Stripe does — but it is still collected in the course of your transaction. See Billing Addresses above.
• Disclosing the third-party scripts your site loads and the cookies they set — Stripe’s __stripe_mid and __stripe_sid on your payment pages, and Cloudflare Turnstile on your donation form if you have enabled Bot Protection. Benecaster neither sets nor reads them, but they run on your domain and your visitors meet them there. See Third-Party Scripts on Your Site above.
• Obtaining consent for those scripts if your jurisdiction requires it. Benecaster ships no consent banner and no lazy-load option for either.
• Meeting anti-spam requirements (such as CAN-SPAM) for the emails your site sends — including a valid business or postal address where the law requires one. Set it once per show under Settings → [Show] → Emails → Business address (or on the Details step of the setup wizard when you create the show), and Benecaster adds it as its own line in the footer of every email that show sends. Leave it blank and no address line is shown — the plugin does not add one for you.
• If you are subject to CCPA: understanding your obligations as a “business” under the California Consumer Privacy Act and whether the data Benecaster processes falls within its scope.

If you’re uncertain about your obligations, consult a legal professional familiar with data protection law.