Subscription Plugin Overview

Benecaster manages your podcast feed and subscriber authentication. It needs to know who is subscribed, at which tier, and whether they’re still active — and it gets that answer from a bridge.

You have two ways to supply it. Connect an external membership plugin you already run, in which case that plugin owns payments and subscriptions and the bridge simply translates its answers for Benecaster. Or use Built-in Membership, where Benecaster manages Stripe-powered tiers itself and is the system of record for both. Either way the rest of Benecaster works the same, because everything downstream talks to the bridge rather than to a specific plugin.

The sections below describe the external-plugin case, which is the more common setup. Built-in Membership is covered at the end of this page.

Why a Bridge Is Needed

If you already run a membership plugin, there is no reason for Benecaster to duplicate it. Your existing plugin keeps doing what it does well — payments, trials, coupons, renewals, dunning — and Benecaster stays focused on podcast feed delivery. Nothing has to be migrated, and your subscribers never notice a second system.

The bridge is the contract between them. It’s a small, standardized layer that translates between your membership plugin’s data model and Benecaster’s understanding of a subscriber.

What a Bridge Does

When Benecaster needs to know about a subscriber, it asks the bridge. The bridge translates the question into whatever API calls or database queries your membership plugin requires and returns a standardized answer. Benecaster never talks to your membership plugin directly — it only talks to the bridge.

Specifically, the bridge handles:

Tier lookup — Given a WordPress user ID, return what subscription level they currently hold. The bridge translates your membership plugin’s native concept of “levels,” “plans,” or “memberships” into a tier slug Benecaster understands.

Active status check — Return whether the user’s subscription is currently active. A cancelled, expired, or paused subscription means no feed access.

Subscription events — Listen for events from your membership plugin (subscription activated, cancelled, changed, renewed, payment failed) and notify Benecaster so it can generate or revoke tokens in real time.

What Happens on a Subscription Event

When a subscriber signs up through your membership plugin:

1. The membership plugin fires a “subscription activated” event
2. The bridge catches that event and tells Benecaster: user ID, tier, show
3. Benecaster generates a token for that subscriber
4. The welcome email is sent with their private RSS feed URL

When a subscription is cancelled or expires:

1. The membership plugin fires a “cancelled” or “expired” event
2. The bridge notifies Benecaster
3. Benecaster marks the token as inactive
4. The subscriber’s feed returns empty on the next podcast app poll

This happens automatically. You don’t need to manually revoke access when a subscriber cancels — the bridge handles it in real time, as long as your membership plugin fires the relevant event promptly.

Included Bridges

Five subscription options are available — four external membership plugins and Benecaster’s own built-in membership system:

See Subscription Plugin Compatibility for a detailed comparison, including which features work with each bridge and recommendations for new setups.

One Bridge Active at a Time

Benecaster connects to one subscription plugin per site. If you have multiple supported plugins installed, Benecaster shows a picker during setup — choose the one that manages your podcast subscribers.

If you use different membership plugins for different purposes (for example, WooCommerce for physical products and MemberPress for podcast subscriptions), select the plugin that handles the podcast subscriptions. The other plugin is ignored by Benecaster.

Connecting Your Bridge

The Setup Wizard walks you through connecting a bridge during initial configuration. You can also change the active bridge at any time in Benecaster → Settings → Subscription.

The Bridge Picker

The Subscription tab always lists Built-in Membership first, then any membership plugin that is currently installed and active on your site — not the full list of supported plugins. If you have MemberPress and WooCommerce Subscriptions both installed, you’ll see both alongside Built-in Membership. If no plugin is installed, the tab says so and lists the supported plugins with installation guidance beneath Built-in Membership.

Selecting a bridge saves immediately — there’s no separate Save button for the bridge picker. Once you click a plugin name in the list, the bridge is connected and Benecaster begins listening for subscription events from that plugin.

To disconnect the active bridge, use the Clear bridge selection link below the picker. This removes the bridge connection for the current show. Existing tokens are not revoked — subscribers continue to have feed access — but Benecaster stops receiving new subscription events from the disconnected plugin until a new bridge is selected.

When No Supported Plugin Is Active

If none of the supported membership plugins are installed and active, the Subscription tab still offers Built-in Membership, and below it lists the supported plugins with a brief description of each, linking to the relevant setup guide. Install and activate whichever plugin fits your setup, then return to this tab — it appears in the picker automatically once detected.

If you set up Benecaster first and plan to add a membership plugin later, you don’t need to reinstall or re-run the wizard. Install the plugin at any time, then open Benecaster → Settings → Subscription — it appears in the picker automatically.

After connecting, configure your tier mapping — the step that tells Benecaster which of your membership plugin’s levels corresponds to which episode access tier. See Mapping Your Membership Tiers.

Using a Membership Plugin Not on This List

The four above are the ones Benecaster builds and supports itself. They are not the limit of what can be connected. A developer can add a bridge for any other membership plugin, and once it is installed it appears in the bridge picker alongside the built-in four and behaves identically — tier mapping, feed access and everything downstream work the same way.

So if you are told your membership plugin “isn’t supported”, the accurate version is that Benecaster doesn’t ship a bridge for it. One can be written.

This is an advanced option intended for developers. A custom bridge is a PHP class, typically delivered as a small companion plugin alongside your main membership plugin. See Integrate a Custom Membership Plugin in the developer documentation for a complete, working example.

Content Drip and Access Scheduling

Most membership plugins include a feature that releases content gradually over the course of a membership — commonly called content drip, content scheduling, or access rules. A member who joins today gets access to some content immediately, then more after 7 days, more after 30 days, and so on.

This feature operates at the WordPress content layer. It filters which posts and pages a user can see based on how long they’ve been a member. It has no effect on Benecaster’s RSS feed delivery.

Benecaster builds feeds from its own availability system. When an episode should appear in a subscriber’s feed, you control that in Benecaster — not in your membership plugin. If you want to release podcast episodes on a staggered schedule (Premium subscribers hear an episode immediately, Basic subscribers hear it a week later, Free subscribers hear it a month later), use Benecaster’s availability dates. Membership plugin drip rules won’t do this.

The practical rule: Configure episode release timing in Benecaster. You can ignore your membership plugin’s drip or access scheduling feature for podcast content entirely.

Each supported plugin’s drip feature is noted in its setup guide:

• MemberPress — Drip feature (built-in)
• Restrict Content Pro — Content Drip module (built-in)
• Paid Memberships Pro — Drip add-on

---

Compatibility with Membership Plugin Add-ons

Most add-ons for your membership plugin will not affect Benecaster. The bridge is a read-only consumer — it listens for events and reads membership state, but never writes to your membership plugin’s data. That separation means a new add-on installed on the membership plugin side generally has no impact on feed delivery or subscriber access.

There are two areas where friction can occur:

Add-ons that restructure member relationships. Some membership plugin add-ons — such as group accounts, team plans, or family subscriptions — change how the plugin represents who holds a membership. If a group add-on means the membership is held by a “group owner” user rather than the individual listener, the bridge may not see the individual as an active member. If you install an add-on that changes your membership plugin’s member model, verify that your subscribers still appear with the correct tier in Benecaster → Subscribers before announcing the change.

Overlapping welcome emails. When a subscriber signs up, both Benecaster and your membership plugin may send a welcome email — resulting in two messages in the subscriber’s inbox. Benecaster’s welcome email contains the private RSS feed URL and is the one subscribers need; the membership plugin’s email is typically account-related.

If you’d prefer to send only one email, or to combine the two, you have options:

• Show Settings → Subscription → Welcome and Feed URL Emails: Each Benecaster email type has its own on/off toggle, per show. Turn off the Welcome email for the show where your membership plugin is already handling onboarding. No add-on required, and it actually stops the email now.
• Disable in your membership plugin: Most membership plugins let you turn off their own welcome email from their settings. This is the simpler option if you want Benecaster’s RSS delivery email to be the only one.
• Email Editor add-on: Email Editor is a template-customization tool — it does not replace or duplicate the on/off toggles above, which stay in core (with or without Email Editor installed). Install it if you also want full control over the emails’ content and design, not to switch one off.

Note: The Welcome email is the primary way subscribers receive their private RSS feed URL — if you turn it off, your membership plugin’s own onboarding must deliver it instead. Followers are the one exception: they always get Benecaster’s welcome email regardless of this switch, since it’s their only route to a feed URL at all.

---

For Developers

The benecaster_bridge_connected action fires each time a bridge is saved — whether from the setup wizard or from Settings → Subscription. It does not fire when a bridge is cleared. Args: (string $bridge_slug, int $show_id).

Use this hook to react to bridge connection events from an add-on — for example, to configure a default integration or pre-populate data from the newly connected plugin. See the benecaster_bridge_connected action reference in the developer documentation.

For building a fully custom bridge (integrating a membership plugin not in the built-in set), see Integrate a Custom Membership Plugin.

Your Source Data Is Keyed by Email; Benecaster Is Keyed by User ID

This is the mismatch every custom bridge hits first. A membership plugin export, a webhook payload or a CSV of members gives you email addresses, and Benecaster’s lookup functions take a WordPress user ID. Two functions bridge the gap:

• benecaster_get_user_id_by_subscriber_email() — the cheap resolve, one address to one user ID. This is the one to call inside a loop over an import.
• benecaster_get_subscriber_data() — the whole record for one subscriber on one show, keyed by email: user ID, display names, tier, token status, revocation reason. Reach for this when you want more than the ID, rather than resolving an ID and then making three more calls.

Benecaster subscribers are WordPress users — there is no subscriber record independent of a WP user — so neither function can tell you about an address with no account, and both return an empty result rather than creating one.

See Subscriber Lookup for Developers for the full decision matrix.

Reporting a Lapse, Not Just a Cancellation

The on_subscription_cancelled() callback your bridge invokes takes an optional third argument: $callback( int $user_id, int $show_id, string $reason = 'cancelled' ). Pass 'expired' when your membership plugin can tell that a membership lapsed — a fixed term ran out, or renewals were attempted and gave up — rather than being deliberately cancelled by the subscriber. Two arguments still means 'cancelled', so existing bridges keep working unchanged.

Report the lapse at all, even if you can’t distinguish the reason. A bridge that never calls on_subscription_cancelled() for an expiry leaves that member’s token active indefinitely — still counted as a paying subscriber, and never sent the cancellation email.

Reporting 'expired' triggers benecaster_subscription_expired in addition to the standard cancellation handling, so an add-on can send lapse-specific win-back messaging instead of a “sorry to see you go” cancellation message.

Enabling “Add Subscriber Manually” for a Custom Bridge

Bridge add-ons can expose Benecaster’s “Add subscriber manually” admin action for shows that use their bridge. By default the action is only available on shows using the built-in membership bridge. To unlock it for a custom bridge, implement a two-step contract:

1. Implement BridgeInterface::create_manual_membership() directly on the bridge class. Do not use ManualMembershipUnsupportedTrait — that trait provides a throwing stub for bridges that cannot support this feature. Your implementation should: create the member record in the target plugin’s data model, call TokenManager::generate() to mint a Benecaster token, stamp is_manual_grant = 1 (and manual_expiry_at when an expiry was requested) on the resulting token row via TokenRepository::set_manual_grant(), and return { subscription_id: int, token_prefix: string }.

2. Hook benecaster_bridge_supports_manual_membership to return true for your bridge slug:

add_filter( 'benecaster_bridge_supports_manual_membership', function( bool $default, string $bridge_slug ): bool {
    if ( 'acme_membership' === $bridge_slug ) {
        return true;
    }
    return $default;
}, 10, 2 );

Once both are in place, the “Add subscriber manually” button appears automatically on shows bound to your bridge and the POST /shows/{id}/subscribers/manual endpoint routes through your implementation. See the bridge-add-manual-membership recipe for a complete worked example.

To suppress a specific email type programmatically — for example, to suppress the welcome email only when a specific membership plugin add-on is active, or to route it through your own transactional email provider — use the benecaster_email_should_send_welcome filter. The filter fires after the per-show toggle check; if the email type is disabled in settings, the filter is never reached. See the benecaster_email_should_send filter reference.

Built-in Membership

Benecaster’s built-in membership system lets you manage Stripe-powered subscription tiers directly in WordPress — no external membership plugin required. It is always the first option in the bridge picker, ahead of the four external bridges, on every plan.

Choosing It Before Stripe Is Set Up

You can choose Built-in Membership at any time, including in the Setup Wizard on a brand-new site, before Stripe or a tier exist. The choice is saved at once. It starts working by itself once two things are in place:

1. Stripe keys configured — at least one Stripe key set (test or live) is saved in Settings → Membership → Payments.
2. At least one active tier exists — create a tier in Benecaster → Memberships → Tiers.

The wizard offers both as skippable steps right after you choose it. Until both are done, nobody can subscribe. A Benecaster admin notice, “Built-in membership is selected but not ready”, names what is missing and links to Payments or Memberships. In Settings → Subscription, a line beneath the picker lists the same missing pieces with Add your Stripe keys and Create a membership tier links. Once both exist, the notice clears and Benecaster begins managing subscriptions directly. Built-in Membership doesn’t use tier mapping, so the “Map at least one subscription tier” notice doesn’t appear for it.

Choosing Between Built-in and an External Bridge

Both approaches are fully supported and neither is going away. The right choice depends on your setup:

Use Built-in Membership if:

• You’re starting fresh and don’t already have a membership plugin installed.
• You want a simple setup — just Benecaster and Stripe, no additional plugin to configure.
• Your subscription needs are straightforward (per-tier pricing, annual and monthly billing, token-based feed access).

Use an external membership plugin if:

• You already have MemberPress, WooCommerce Subscriptions, or another supported plugin managing your subscribers — migration to built-in is unnecessary disruption.
• You need features beyond what built-in membership currently supports: advanced couponing, group accounts, content dripping, complex access rules, or multi-currency pricing.
• You prefer to separate payment processing from your podcasting plugin.

Switching from Built-in to an External Bridge

If you start with Built-in Membership and later decide you need a dedicated membership plugin, you can promote your subscriber records to that plugin. See the “Moving from Built-in Membership to an External Plugin” section below for details.

Moving from Built-in Membership to an External Plugin

If you start with Benecaster’s built-in membership and later decide you need a feature that a dedicated membership plugin offers — advanced couponing, team accounts, content dripping, or a specific payment flow — you can promote your subscriber records to an external plugin without leaving Benecaster.

The bridge handles the write path: because each bridge already knows how to talk to its plugin, it can also create member records in that plugin on your behalf. Your subscribers keep their existing feed URLs throughout — Benecaster simply switches which plugin it consults for tier information going forward.

What transfers automatically:

• Subscriber records (email, WordPress user account, current tier)
• Feed access — existing feed URLs are preserved; no subscriber action required

What cannot transfer — payment details:

Due to payment provider security requirements, active payment relationships cannot be moved from one system to another. This is a constraint of how payment processors work, not a Benecaster limitation. Your subscribers will need to re-enter their payment information in the new membership plugin.

To give subscribers time to do this, Benecaster applies a configurable grace period (default 30 days) after the switch. Feed access continues uninterrupted during the grace period. Before starting the promotion, let your subscribers know they’ll need to re-subscribe through your new membership system — most podcasters send a brief announcement email first.

Which plugins support this:

Not every membership plugin supports programmatic member creation. The promote wizard shows only the plugins that are installed, active, and confirmed to support it. The Subscription Plugin Compatibility page lists which bridges include write support.

How to do it:

The promotion wizard is in Benecaster → Settings → Subscription. It walks through: selecting the target plugin, mapping your tiers, previewing the subscriber count, running the transfer, and switching the bridge. The whole process takes a few minutes; your show stays live throughout.