Payment Failure and Recovery

When a Benecaster subscription payment fails, your license moves to Suspended state. Benecaster gives you a 30-day window to resolve the billing issue before any subscriber impact occurs. This page covers what to expect at each stage and how to recover.

---

The 30-Day Grace Window

The moment Benecaster’s daily license check receives a payment-failed rejection from the license server, a 30-day grace window opens. During this window:

• Subscribers are unaffected. Their private feed URLs continue to work and deliver their tier-specific content normally.
• New token generation is blocked. New subscribers who sign up through your membership plugin cannot receive a feed URL until the billing issue is resolved.
• A warning notice appears in the Benecaster admin notification panel explaining that payment failed and prompting you to update billing.

The grace window opens once, on the first payment-failed response. Subsequent daily checks that also return payment-failed do not restart the clock — you have 30 days from the initial failure, regardless of how many failed checks occur in between.

---

What Your Subscribers See

Nothing. That’s the point.

During the full 30-day grace window, your subscribers’ private feed URLs continue to deliver their tier-specific episodes exactly as normal. No notification is sent to subscribers. Their podcast apps keep working without interruption. You have 30 days to resolve the billing issue without any subscriber-visible consequence.

---

What the Operator Sees

Benecaster also emails you a series of reminders to prompt you to update billing:

Each reminder is sent once. The Day-0 email does not re-fire on subsequent retry attempts from Stripe — only the first confirmed failure triggers it.

The ladder stops at the cutoff. The Day-29 notice is sent on day 29 and only while you are still inside the 30-day window. Once the window closes you receive nothing further from this sequence — no repeated final notices, and never a “0 days remaining” warning after the fact.

These come from benecaster.com, not from your site, and go to your account’s billing address rather than your site’s admin address. That means they still reach you if your site’s own email is misconfigured — which matters most precisely when billing is failing — and if you run several sites on one license you get one message per event rather than one from every install.

Because they aren’t sent by your site, they don’t appear in your email queue, can’t be delayed by WP-Cron, and have no local template to override.

For local observability, the plugin fires benecaster_license_grace_started when the grace window opens — hook it to route an alert to external monitoring or raise your own notice. There is no plugin-side hook for the reminder emails themselves.

---

If the Grace Window Expires Unresolved

If 30 days pass without a successful payment, Benecaster enters hard cutoff state. From that point:

• Private feed URLs stop serving. They return an error rather than content, and they do not fall back to your public feed. The paid product stops.
• Your public feed keeps working normally. So do your episodes, your show pages, and listener support links. At hard cutoff the site runs as exactly the free WordPress.org version of Benecaster — nothing less, nothing more. You lose subscriber delivery, not your podcast.
• Nothing is downgraded or deleted, and it all comes back when you pay. Hard cutoff is a state your license is in, not a conversion of your install. Subscriber records, tier mappings, episodes and settings are untouched, and recovery works at any point — see Recovery below.
• Token access is suspended but tokens are not deleted. Tokens are marked as blocked for the duration. On recovery, the block is lifted — feed URLs start working again on the next app poll, and subscribers do not need to re-add their feeds.
• New token generation stays blocked.
• Some podcast apps eventually drop subscriptions after enough consecutive failed polls. This is the consequence worth knowing about — see the recovery section below.

The hard cutoff is applied by GraceExpiryTracker during the nightly cron pass, which records the cutoff timestamp. The benecaster_license_payment_grace_hard_cutoff action fires once, on the first cron tick that crosses day 30 — hook it to escalate an admin notice or alert external monitoring.

What subscribers see during hard cutoff. Their app reports an error or an empty feed rather than quietly showing different episodes. That is deliberate. Somebody whose paid access has ended should be told, not moved onto the free tier without noticing — a silent switch to public content damages your relationship with the people who were paying you, and it hides from them that anything happened at all. Episodes they already downloaded stay on their device.

⚠ Your subscribers are still being charged. Hard cutoff stops their feeds. It does not stop their payments — not through an external membership plugin, which has no idea your license lapsed, and not through built-in membership either. Until you intervene, every subscriber keeps paying full price for a feed that returns an error.

This matters more here than on a deliberate cancellation, because nobody chose this state. A card expired, and the site arrived at day 30 on its own. If you have decided not to continue, cancel or pause the subscriptions — in your membership plugin, or in Benecaster → Memberships for built-in membership — rather than leaving them running against a dead feed. If you are coming back, resolving the billing issue fixes both sides at once.

Why there is no gentler landing. We considered redirecting subscribers to the public feed, and decided against it. A subscriber whose app keeps updating has no idea anything is wrong, and neither, in practice, do you — which removes the one signal that prompts anyone to fix the billing problem. The clarity we owe goes to you: the reminder emails, the admin notices, and your benecaster.com account all say exactly what is happening and how to resolve it. Every one of those reaches the person who can actually act.

---

Recovery

To restore full private access:

1. Log in to benecaster.com/my-account/ and update your payment method or clear the failed invoice.
2. Wait for the next daily license validation (automatic, runs once per day), or trigger it manually from Settings → Account → Validate now.
3. When the license server responds with a valid status, Benecaster:
   • Clears the grace window record and the hard-cutoff marker
   • Un-revokes every token that was revoked by the cutoff, in a single pass
   • Restores private feed delivery on the next poll from each subscriber’s app
   • Unblocks new token generation

There is no deadline on recovery. Whether you resolve the billing issue on day 5, day 45, or a year later, the result is identical — full restoration. Nothing expires, nothing is purged, and there is no point after which the license can only be replaced rather than revived. Paying on day 5 simply means there were no revoked tokens to bring back.

Recovery requires nothing from your subscribers. Their feed URLs are unchanged and start working again on their own — you do not need to reissue tokens, resend welcome emails, or tell anyone to do anything.

Only tokens blocked by the hard cutoff come back. Restoration is scoped to tokens tagged grace_timeout. Anything revoked for another reason during the same window — an admin revoking access, a bridge cancellation, a manual grant reaching its expiry — stays revoked. Those were deliberate decisions and recovery does not undo them.

Timing. Restoration happens on the first daily validation cycle after the payment succeeds, so typically within 24 hours. Trigger it immediately from Settings → Account → Validate now if you would rather not wait.

The one case that needs subscriber action. If a subscriber’s podcast app dropped the show during the dark period — some apps do after enough consecutive failures — their feed URL works again, but the app has already deleted the subscription. They will need to re-add it. This is worth a proactive message to your subscribers after a long outage rather than waiting for support requests.

Two actions fire on recovery. benecaster_license_grace_recovered fires on every recovery, including one where payment succeeded before day 30 and no access was ever lost. benecaster_license_payment_grace_recovered( int $restored_count, int $started_at ) fires only when a hard cutoff was cleared and tokens were actually restored — hook that one for “N subscribers just got their access back” notices, resolve events on a monitoring incident, or tracking how many subscribers survive an outage.

---

Timeline Summary

---

See Also

• License Status → — full explanation of Suspended and other status values
• Billing and Renewals → — how billing works and where to manage payment methods
• How Feed Tokens Work → — how the public-feed fallback is dispatched after grace expires