Buy-up Content Gating

Once you have defined one or more buy-ups, you can restrict individual episodes so that only subscribers who hold an active grant for that buy-up can access them. This is separate from tier-level access — an episode can require a specific buy-up regardless of which tier the subscriber is on.

A grant only unlocks content on the show that owns the buy-up. Buy-ups belong to one show, and so does the access they grant: a subscriber who bought your ad-free buy-up on one show does not get ad-free episodes on another, even though it is the same person on the same site. If you run several shows and want the same buy-up on each, create it separately on each one — and expect subscribers to buy it separately too.

The episode editor reflects this: the buy-up picker on an episode only offers buy-ups belonging to that episode’s own show.

---

Setting up Per-Episode Access

In the episode editor, open the Access tab. Below the tier availability controls is a Buy-up Access section listing the show’s active buy-ups as checkboxes. Tick the buy-ups that should grant access to this episode. Leave them all unticked to apply normal tier-based access rules with no buy-up requirement.

A show can set a default list of buy-ups (Shows → [show] → Subscription tab → Buy-up Defaults) that pre-ticks these checkboxes on every new episode you create for that show. It is a convenience for bulk-selecting the same buy-up across many new episodes — it is not a second gating mechanism, it never filters the feed on its own, and it only affects episodes at creation: changing the show default does not touch episodes that already exist. See Show Settings for how to configure it.

---

Access Logic

The access check uses OR logic across the selected buy-ups: if the subscriber holds an active grant for any one of the selected buy-ups, access is granted. There is no way to require multiple buy-ups simultaneously on a single episode.

Ticking a buy-up never takes an episode away from anyone. It adds a way in, on top of the tier schedule — it is not a filter that narrows it. A subscriber whose tier already entitles them to the episode keeps it whether or not they hold the buy-up.

So an exclusive sale is expressed by leaving every tier unscheduled, not by ticking the buy-up. With a tier scheduled and a buy-up ticked, both groups get in — which is usually what you want for an optional extra, and never what you want for something sold separately.

A retired buy-up keeps delivering to existing holders. Deactivating a buy-up takes it off sale; it does not revoke grants. Anyone who already bought it keeps their access until they cancel.

---

Feed Access

Buy-up gating reaches the RSS feed as well as your website. A buy-up grant is resolved at feed-request time alongside the subscriber’s tier, so an episode unlocked by a buy-up is delivered to their podcast app like any other episode they can access.

The same decision unlocks the episode on your website. [benecaster_player], [benecaster_episodes], [benecaster_latest_episode] and [benecaster_related_episodes] all ask whether the listener can hear the episode, buy-ups and grants included, so a holder who is logged in can play it on your site as well as in their podcast app. An episode list given an explicit tier="…" is the exception by design: it shows what that tier carries, whoever is looking.

No token regeneration is required and nothing needs clearing. A purchase or cancellation changes what that subscriber resolves to, not the contents of any feed, so access changes take effect the next time their app fetches.

A [benecaster_access_gate] in an episode’s page content is resolved in the feed too, against what each listener holds. A holder’s podcast app shows the gated half on every episode that carries the gate, including public episodes and ones their tier includes. Your public feed, and every listener who doesn’t hold the buy-up, gets the [benecaster_else] half, so the gated half never reaches anyone who hasn’t bought it.

---

Gating Content on a Page

Everything above gates whole episodes. To gate part of a page instead — a download link, a transcript, an image, a bonus video, a paragraph of extra writing — wrap it in [benecaster_access_gate]. Holders of the add-on see what is between the tags; everyone else sees what follows [benecaster_else].

[benecaster_access_gate buyup="transcripts"]
  Read the full transcript below.
  ...
[benecaster_else]
  Transcripts are an extra — add them from your account page.
[/benecaster_access_gate]

buyup is the buy-up’s Access token type. The gate works on any page or post, and in an episode’s page content, where you can also insert it from the editor’s / menu as a Buy-up Gate block with two halves to type into, and pick the buy-up from a list instead of typing its slug.

The gate hides the link. It does not protect the file. A file in your media library keeps its ordinary web address, so anyone who is given that address can still open it. The gate decides who is shown the link, not who can reach the file.

Use the episode’s Access tab, not the shortcode, to gate a whole episode — the shortcode only shows and hides parts of the page it sits on.

Do not gate extra content by comparing the subscriber’s tier. This is the mistake to know about in advance, because nothing about it looks wrong. A buy-up does not change anyone’s tier: a subscriber who buys your ad-free buy-up still resolves to whatever tier they were already on. So a check written against a tier slug — a [benecaster_tier_gate] or a tier comparison in code — opens the content to every subscriber on that tier, including everyone who bought nothing, and closes it to anyone who bought the buy-up from a different tier. No error appears; the page simply shows to the wrong people. Use [benecaster_access_gate] on a page, or ask benecaster_user_has_buyup() in code — both ask whether the subscriber holds the grant, which is the only question that answers it.

---

For Developers

Buy-up requirements are stored on the episode, but read them through the supported seam rather than the underlying meta. benecaster_episode_is_accessible fires for every episode and carries the resolved access decision — use it to inspect or override buy-up access in custom code.

See benecaster_user_has_buyup() for checking buy-up status from PHP. Anything beyond showing or hiding content — putting a holder on a mailing list, telling another system about them — is benecaster_user_has_buyup() and the buy-up lifecycle hooks, called wherever the decision needs making, in your theme or in an add-on.

A buy-up will not unlock a community space on its own. Community access is designed around tiers, so a buy-up purchase is not something a Discord or Circle integration would act on — no role, no invite. A buy-up meant to unlock a community space needs that step written against benecaster_user_has_buyup() and the platform’s own API. Worth arranging before you put the buy-up on sale rather than after.