benecaster_license_payment_grace_hard_cutoff
Fires when the 30-day payment-failure grace window expires and access is cut off. Every active token is bulk-revoked with a grace_timeout reason, the hard-cutoff marker is set, and all cached feeds are flushed so the next request recomputes immediately.
Subscriber feeds stop serving — they do not fall back to the public feed. Token-bearing feed URLs stop delivering; the show’s public, non-token feed keeps working exactly as it does on the free version of the plugin. The podcaster loses subscriber delivery, not their podcast. The per-show “serve public feed on invalid token” setting still governs subscriber-level failures — an invalid token, a lapsed membership — but does not apply to the podcaster’s own license lapsing. The reasoning is on Payment failure and recovery.
This is the terminal event in the payment-failure sequence that begins with benecaster_license_grace_started. The day 10, 20, and 29 reminders between the two are sent by the license server, not by the plugin — there are no plugin-side actions for them. If billing is fixed before this fires, benecaster_license_grace_recovered fires instead and this never runs.
Parameters
| Name | Type | Default | Description |
|---|---|---|---|
$now |
int |
— | Unix timestamp at which the cutoff was applied. |
$revoked_rows |
int |
— | Number of token rows flagged as a result of the cutoff. |
Notes
Subscribers are not emailed by Benecaster when this fires. Their apps simply start failing to refresh.
Built-in-membership billing stops with the feeds. Benecaster hooks this action itself and pauses collection on the Stripe subscriptions the plugin created — see benecaster_cutoff_billing_pause_complete for what it could not reach.
Billing you do not run through built-in membership carries on regardless. An external membership plugin — Restrict Content Pro, Paid Memberships Pro, WooCommerce Subscriptions, Patreon — has no idea the license lapsed and keeps charging for a feed that returns an error until the podcaster intervenes. That gap is still a reason to hook this action. See Payment failure and recovery.
Need this built rather than just documented? See our services →