How Benecaster Handles Subscriber Billing

This page explains how the built-in membership system handles common billing situations — what happens to a subscriber’s feed access in each case, and what (if anything) you need to do.

---

A Card That Needs Bank Verification at Signup

Some banks ask the cardholder to confirm a payment — a code by text message, or a prompt in their banking app. This is 3D Secure, and it is common for cards issued in Europe and the UK.

When a new subscriber’s card needs it, the signup form opens the bank’s check. The membership is confirmed only once the payment clears — that is when they get their feed URL and welcome email. If they close the page straight after verifying, the signup still completes a moment later on its own.

If the check fails, or the card is declined outright, nothing is created and nothing is charged. The subscriber sees a message saying so and can try again or use another card.

A free member who starts a paid signup and gives up — at the bank’s check or with a declined card — stays on their free plan with their existing feed.

You don’t need to do anything. A signup whose bank check was never completed can sit in your Stripe dashboard as Incomplete for up to about a day; Stripe then expires it on its own, uncharged. A declined signup is cancelled straight away.

---

Successful Payment

When a subscriber’s payment succeeds:

• Stripe sends an invoice.paid event.
• Benecaster updates the subscription’s billing period dates.
• A payment receipt email is sent (if enabled in Show settings).
• The subscriber’s feed URL is unchanged.

You don’t need to do anything. Renewals are fully automatic.

---

Payment Failure — During Stripe’s Retry Window

When a payment fails, Stripe enters a retry cycle. The default retry schedule spans roughly three weeks across four attempts, though this depends on your Stripe account settings.

What happens to feed access: The subscription is internally marked as overdue, but the subscriber’s feed token is not revoked. They can continue downloading episodes throughout the retry window. This is consistent with how external membership plugins handle failed payments — WooCommerce Subscriptions puts the subscription “on hold,” MemberPress and Restrict Content Pro use configurable grace periods — all of them maintain access while retrying.

What Benecaster does automatically:

• Sends the subscriber a payment failure email (once, not on every retry attempt)
• Shows a persistent “payment failed” notice on the subscriber’s account page with a link to update their payment method

What you need to do: Nothing, unless a retry succeeds or all retries are exhausted (see below).

---

Payment Recovery — Retry Succeeds

When a retry payment succeeds:

• Stripe sends invoice.paid followed by customer.subscription.updated.
• Benecaster transitions the subscription status from overdue back to active.
• The account page payment failure notice clears automatically.
• The subscriber’s feed access was never interrupted.

---

All Retries Exhausted — Subscription Cancelled

When all Stripe retries are exhausted without a successful payment:

• Stripe cancels the subscription and sends customer.subscription.deleted.
• Benecaster revokes the subscriber’s feed token immediately.
• The subscriber receives a Subscription Cancelled email (if enabled).
• The subscriber loses podcast access.

To regain access, the subscriber would need to resubscribe through the podcast’s subscribe page.

---

Subscriber Cancels

When a subscriber cancels through their account page:

• Benecaster sets cancel_at_period_end = true on the Stripe subscription.
• Feed access continues through the end of the current billing period — the subscriber paid for that period.
• At the end of the billing period, Stripe closes the subscription and Benecaster revokes the token.
• The subscriber receives a Subscription Cancelled email at that point (not at the moment they cancel).

This is the standard cancel-at-period-end pattern used across all subscription billing platforms.

---

Subscriber Switches Their Own Billing Period

When a subscriber schedules a self-service switch to another billing period of their tier from their account page (Monthly to Annual, or any other cadence you sell that tier at):

• Nothing is charged the day they ask. The switch is scheduled, not billed.
• The new price starts at their next renewal — in either direction, Monthly to Annual or Annual to Monthly.
• The feed URL and token are unchanged. This is a billing change only; it doesn’t touch feed access.
• The subscriber receives a Billing Change Scheduled email confirming the switch, the price, and the date it starts.
• The switch can be cancelled from the account page any time before it lands, putting the subscriber back on their current billing period with no change.

If the new billing period already has a podcaster-initiated price change scheduled to land after the switch, the subscriber is enrolled in that change too — the Billing Change Scheduled email doubles as their notice of it, stating the later price and when it first applies. See Price Change Considerations for how these two things can interact.

---

Parity with External Bridges

Built-in membership billing behavior is consistent with how external bridges handle the same scenarios:

---

What Requires Your Attention

In normal operation, nothing. The billing cycle runs automatically. The scenarios that may benefit from your attention:

• Subscriber with recurring payment failures — you can view their subscription status in Benecaster → Subscribers → [Subscriber]. The account page notice prompts them to update their payment method.
• Subscriber who wants a refund — Benecaster does not issue refunds. Use the Stripe Dashboard to refund the charge directly.
• Subscriber who wants an immediate cancellation (not end-of-period) — not available through the subscriber account page. Use the Stripe Dashboard to cancel the subscription immediately, or cancel via the Benecaster subscriber detail panel if that option is exposed.

---

If Your Own Benecaster License Lapses

Everything above assumes your Benecaster license is in good standing. If it isn’t, what happens to your subscribers’ billing depends on why — and the two cases are opposites.

A failed payment that runs to hard cutoff: Benecaster stops the billing for you. Your subscribers stop being charged when their feeds stop, and bringing your license current resumes exactly the subscriptions it paused. Two cases are skipped and keep billing — a show in test mode, and one whose Stripe credentials Benecaster cannot use — and you are told which. See Payment Failure and Recovery for the detail and the limits.

The skipped-show notice can now tell you when those subscribers are definitely still paying you. Where Benecaster knows a skipped subscription was set up with live Stripe keys, the notice adds a count: “N of those skipped subscriptions were created with live Stripe keys, so those subscribers are still being charged right now.” That turns “we could not reach Stripe for this show” into a number you can act on.

When that sentence does not appear, read it as unknown — never as zero. Benecaster only started recording which key mode created a subscription in a recent version. Subscriptions set up before that carry no record, and nothing can work it out after the fact: a Stripe ID does not say which mode made it, and the show’s current mode is exactly the signal that cannot be trusted here — a show that has since been switched to test is the case the count exists for. Rather than tell you “0 are still being charged” when it does not know, Benecaster says nothing. On an established show, silence is the normal case and still means: go and look.

You cancelling deliberately, or a plain expiry: nothing is paused. These never open a grace window and never reach hard cutoff, so the automatic pause never runs. Your subscribers keep renewing on their normal schedule after your feeds have stopped. Stop the billing yourself in Benecaster → Memberships, before you cancel, so there is no window where people are paying for a dark feed.

Paused is not cancelled, in either case. A paused subscription sits in your Stripe account indefinitely until you close it — deliberately, because pausing is reversible and cancelling effectively is not. If you are not coming back, cancel them yourself.

On a Staging Copy, Billing Is Refused Entirely

If you are looking at a staging or development copy of your site and billing does not work, that is the design, not an outage. Benecaster records the address it first ran at. Once it finds itself running somewhere else, it refuses every billing operation — new subscriptions, cancellations, resumes, buy-ups added or removed, one-off support payments, and the automatic pause and resume sweeps described above.

Why it refuses even with test keys in place. A staging site is normally a copy of the production database, so it carries your subscribers’ real Stripe subscription IDs. Those IDs stay real no matter which keys are loaded. A cron run or a replayed webhook on the copy could cancel, re-tier or resume a genuine paying subscriber — no money moves, and the subscriber still loses what they paid for. Key mode cannot catch that; only knowing the site is a copy can.

This arms itself. Because the copy inherits the recorded address along with the rest of the database, you do not have to remember to configure the staging site. That is deliberate — the protection cannot depend on anyone remembering.

What your subscribers see. On a copy, a subscriber-facing billing action fails with “Billing changes are temporarily unavailable on this site.” — and nothing more. The message is deliberately vague: it is the same message every time, it appears on pages a logged-out visitor can reach, and there is nothing a subscriber could do with the real reason. Your explanation is in the debug log, which names both addresses — the one the site recorded and the one it is running at — once per operation per hour.

If a site refusing billing is genuinely your production site — after a domain change, for instance — the fix is define( 'BENECASTER_IS_PRODUCTION', true ); in wp-config.php. Only ever add that to the real production site. Putting it on a staging copy disarms the protection on the one install it exists to watch. See Using a Staging Site.

Running an external membership plugin instead? None of the above applies. Benecaster cannot pause or cancel billing inside Restrict Content Pro, Paid Memberships Pro, WooCommerce Subscriptions or Patreon — those systems have no idea your license lapsed and will keep charging on schedule, indefinitely, on every path including a payment-failure cutoff. You must stop it there yourself. See License Status and Notifications.