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
• Subscriber history (joined, cancelled and tier-change events) for those subscribers, which is anonymised rather than deleted, so your growth and churn counts don’t change

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.

Episode purchases (the Episode Sales add-on) are excluded too, for a different reason: they’re access someone paid for outright, not aging subscriber activity. The nightly retention sweep never removes a purchase record — only a right-to-erasure request does, below. Don’t assume a quiet buyer’s purchases get tidied away with everything else.

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. The subscriber’s history (joined, cancelled and tier-change events) is anonymised rather than deleted: the events stay so your counts don’t change, and the link to the person is removed. The result lists it as Subscriber history rows anonymised: N. 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 — plus a Benecaster Purchased Episodes section (Episode Sales add-on): the show, what it gave access to, the date granted, and the expiry, including purchases that have since expired. Lifetime access shows Never rather than a date.

The Benecaster Emails Sent section lists one entry per email Benecaster logged for that address, with its show, type, subject, date and Status:

• queued — waiting its turn to be sent.
• sent — handed to your site’s mail system. A message that bounces later still reads sent, because Benecaster never hears about it.
• failed — could not be sent after three attempts.
• suppressed — never sent: the person had opted out of that kind of email, or something else on your site stopped it.

So the section can include emails the person was not sent because they opted out. Emails logged before Benecaster recorded these statuses all read sent, whatever happened to them.

If the person has been notified of a tier or buy-up price change, the export also includes a Benecaster Price Changes section — one entry per change they were notified of, including a change since withdrawn or superseded by a later one. Each entry shows: which tier or buy-up changed, the old and new price, when they were notified, the date they’d first be charged the new price, whether a reminder was sent (a date, or “No”), and the outcome in plain words — moved to the new price; not yet applied; left on the current price (with the reason: their membership had ended, moved tier, was paused, or had a payment problem); not applied because the subscriber switched to a different billing period before the change took effect; not applied because the subscriber cancelled their switch to this billing period; not moved because the update failed; or not applied because the show withdrew or replaced the change — plus the date they were moved and any error details. Dates are shown in the site’s own timezone. Only people matched to a WordPress account are included; a price change sent to someone without an account has nothing to match against.

If the person was imported from another podcast platform through the Migration Wizard, the export also includes a Benecaster Platform Migration section — one entry per show they were imported for: the show, the previous platform, their email and name as imported, the tier they held there, and the date they joined there. That join date is shown exactly as it was imported, never converted or shifted to your site’s timezone — it describes an event on the other platform, not on yours. The entry also shows their migration status and the invitation, completion, and grace-period-end dates, in your site’s own timezone. Someone matched only by email — imported before they ever created a WordPress account — is included the same as a matched account. The payment-setup link they were sent and any private notes you left on the import are never exported.

Before any of the erasure below runs, Benecaster checks whether the person still has a membership that can be billed. If they hold a built-in membership subscription that Stripe can still charge — active, in a free trial, past due, paused, or set to cancel at the end of the current billing period — the whole request is refused and nothing is erased. The same happens if a bridge plugin (MemberPress, WooCommerce Subscriptions, Paid Memberships Pro, or Restrict Content Pro) still counts them as an active member of a show, or if a show’s configured membership plugin is deactivated, since there’d then be no way to ask it. Each plugin’s own idea of “active” decides this: a WooCommerce subscription on hold after a failed payment, a MemberPress renewal being retried, and an RCP membership that’s expired but still being retried do not block erasure, while a fixed-term PMP level does.

When a request is refused this way, WordPress shows Personal data was found for this user but was not erased, with one line per show telling you what to do — cancel the Stripe subscription (settle a past-due balance first, or cancel immediately rather than waiting out a subscription already set to cancel at period end), or cancel or reactivate the relevant membership plugin. Once that’s done, run the same request again. Until then the request stays at Confirmed (or Pending, for a forced erasure), and WordPress’s “your request has been completed” email is never sent — telling the person why is on you, since WordPress doesn’t send a refusal email either. None of this blocks a hand-granted or comped membership with no Stripe subscription behind it, an ended membership, or someone with no WordPress account at all, and it doesn’t stop any other plugin’s own eraser from running.

The reason the whole request is refused, rather than just the parts that would otherwise stay: erasing feed tokens and detaching a subscription from the account while Stripe keeps billing would leave the person paying for something they can no longer access and can no longer cancel themselves from their account page.

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:

Episode purchases don’t appear on the podcaster-facing Settings → Your Data export in Benecaster itself — that sheet belongs to the Episode Sales add-on, which has the product names and prices this page doesn’t.

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.

Paid Subscriptions

If built-in membership is active on your site, the suggested text includes a Paid Subscriptions paragraph:

“We store your subscription status, tier, and billing history. If the price of your subscription changes, we also record that we told you about it, when, whether we sent a reminder, and what happened to your subscription as a result. If you ask us to erase your data, we keep that record but remove anything that identifies you, so our record of the price change stays complete. We can only erase your data once your subscription has ended. While it is active, paused, in a free trial or has a payment outstanding, we need that data to provide the subscription you are paying for, so please cancel it first and then ask again.”

The last two sentences describe the refusal behavior above in plain language for your subscribers, and the middle two describe how a price-change notice survives an erasure request without identifying anyone — see Price Change Considerations for more on that record.

This paragraph is suggested text you can edit like any other paragraph on the Policy Guide screen, and it only appears for a show billed through built-in membership. A show gated by a bridge plugin (MemberPress, WooCommerce Subscriptions, PMP, RCP) doesn’t get it — that plugin already discloses its own billing data and its own erasure limits, and Benecaster doesn’t duplicate them.

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.