Promote to Bridge — Moving Subscribers to an External Membership Plugin

Promote to Bridge is a one-time migration tool that lets you move subscribers from Benecaster’s built-in membership system into an external subscription plugin — such as MemberPress, WooCommerce Subscriptions, or Paid Memberships Pro — while keeping their feed access uninterrupted during the handoff.

You would use this when you have outgrown the built-in membership system and want to adopt a full-featured membership plugin, or when you are consolidating an existing membership plugin with a second audience that started on built-in membership.

Before You Start

Payment must be handled outside Benecaster. The Promote to Bridge wizard creates subscriber accounts in the target membership plugin. It cannot move payment details or Stripe subscriptions across, and this is a deliberate security boundary rather than a missing feature.

Benecaster never holds your subscribers’ card numbers. Card details are entered directly into Stripe’s own hosted fields and stored by Stripe — they do not pass through your WordPress site, and there is nothing on your server to hand to another plugin. A Stripe subscription is likewise tied to the integration that created it and cannot be reassigned to a different plugin’s Stripe connection.

The practical consequence: you are responsible for collecting payment in the destination plugin (or billing subscribers separately), and for cancelling their Stripe subscriptions in the built-in membership system once the migration is done. Subscribers will need to enter their payment details again in the new system — there is no way around that, on any platform.

The wizard is a one-way operation. There is no built-in rollback.

Running the Wizard

The wizard is at Settings → Subscription → Promote to Bridge (the promote button in the subscription settings tab). It runs in five steps:

Select destination bridge — choose the external membership plugin you are moving to. Only bridges that implement the writable interface are listed (bridges that can create members programmatically).
Map tiers — for each of your native tiers, choose the corresponding level in the destination plugin.
Set grace period — choose how many days subscribers have before their existing feed token expires. During the grace period, subscribers can still use their old token while they complete setup in the new system. This number is the default for the run; a developer can vary it per tier or per subscriber with the benecaster_promote_grace_length_days filter, in which case individual subscribers may end up with more or fewer days than you typed here.
Confirm — review the subscriber counts per tier and confirm the run.
Done — results summary showing how many were promoted, skipped, and errored.

What Happens During Promotion

For each active subscriber:

Benecaster calls the destination bridge to create a member account for that subscriber.
A grace-period expiry date is written to the subscriber’s record.
The subscriber’s existing feed token continues to work through the grace period.
When the grace period ends, the feed token is revoked. On default settings their feed URL keeps working and starts serving the public feed — it does not go dead. See below.

Subscribers who already exist in the destination plugin (matched by email) are skipped.

Grace Period

The grace period gives subscribers time to connect their new membership account to their podcast app. During this window:

Their existing Benecaster feed token works as normal
They receive a reminder email 6–8 days before the grace period ends
They receive an expiry email when the token is revoked

Revocation does not usually break the subscriber’s feed. A revoked token is a subscriber-level failure, and the per-show Serve the public feed on an invalid token setting governs those. It is on by default, so the subscriber’s existing feed URL keeps responding and starts delivering your public feed instead of their private one. Their podcast app keeps refreshing; they simply stop receiving subscriber-only episodes. Turn that setting off for the show and the same URL returns an error instead.

After revocation, subscribers who have been successfully onboarded in the destination plugin will have a new feed URL provided by the bridge. Subscribers who have not completed setup will need to contact you for assistance.

For more detail on how the grace period is managed and monitored, see Promote to Bridge — Grace Period.

Re-authorization

Benecaster now checks for you automatically, by default, with no setting to turn on. Every day, before a grace period would expire, Benecaster checks whether the subscriber is confirmed active in the destination plugin. If they are, their token is kept — no admin click required.

This is a daily re-check, not a one-time decision. It runs fresh on every tick: a subscriber kept today because they were active in the destination plugin reverts to the normal revoke on the very next check if they later cancel there.

⚠ “Kept” is not the same as “resolved.” The subscriber’s row is not marked re-authorized, and its grace-deadline badge in Promotion History still shows as past-due even while their token is being kept — automatic detection decides the token, nothing else. If you want the row itself to stop showing as past-due, go to Settings → Subscription → Promotion History, find their row, and click Clear grace. This resets the expiry marker and is the only thing that changes what the panel shows.

Automatic detection can’t answer every case — the destination plugin might be deactivated, or the promotion’s target might be unrecognised or missing. In those cases the token is revoked as before, and the manual Clear grace route above still works exactly as it always has.

There is also a developer-side override. The benecaster_promote_grace_expiry_should_revoke filter runs just before each daily check and can veto a revoke — this is how automatic detection itself is implemented, and the same filter is available to your own code if you need different logic than the built-in destination-plugin check. A veto means not today rather than never: the subscriber’s row stays past-due and is offered up again on the next daily run until you clear or extend it. See Promote to Bridge — Grace Period.

Promotion History

The Promotion History panel (below the wizard entry point) shows every subscriber who has been through a promotion, their grace period status, and their target bridge. You can extend or clear grace periods for individual subscribers from this panel.

For Developers

benecaster_bridge_promote_complete — fires when the promotion run finishes
benecaster_promote_grace_expired — fires when an individual subscriber’s grace period expires
benecaster_promote_grace_expiry_should_revoke — veto an individual expiry, for the re-authorization case described above
benecaster_promote_grace_length_days — vary the grace length per tier or per subscriber
benecaster_promote_grace_cleared and benecaster_promote_grace_extended — mirror the manual Promotion History operations
PromotionService — the class that drives the promotion run and grace period management
BridgeWritable — the interface a bridge must implement to appear in the wizard’s destination list
REST API endpoints: Promote to Bridge REST API