How to offboard paid community members without ghost access

A cancellation, the end of a paid period, and the removal of community privileges are three separate events. Collapse them into one and you get either ghost access that never ends, or a paying member locked out of a period they already bought.

Three events, not one

If you need to remove Patreon Discord access, do not start by manually deleting a role. A cancellation, the end of a paid period, and the removal of community privileges are separate events. Treating them as one produces two predictable failures: a former member keeps ghost access, or a paying member loses access before the period they bought has ended.

A reliable offboarding workflow gives each system one job, records an explicit access deadline, removes only paid privileges, and keeps a clean route back. The result is less support work for the creator and a more respectful exit for the member.

Why paid access drifts after cancellation

Most paid communities span at least three records. The billing platform knows whether a subscription is active, scheduled to cancel, unpaid, or ended. An identity link connects that customer to an account on the community platform. Discord or another community tool holds the roles that unlock private channels.

Those records change on different schedules. Stripe distinguishes immediate cancellation from cancellation at the end of the billing period, and that distinction matters even when Patreon or Memberful is the visible membership product. A cancellation request often means "do not renew me next month", not "remove what I already paid for, now".

Integrations add another delay. Discord’s Patreon integration connects membership tiers to Discord roles, but a role is a projection of membership state, not the authoritative subscription record. If an event is delayed, an account is unlinked, or a moderator added a role by hand, the projection is simply wrong.

Ask four questions, not one boolean

Is the subscription renewing Payment intent going forward. On its own it says nothing about today’s access.
Until what timestamp is the person entitled The paid period they actually bought. This is the field most workflows never store.
Which community account is linked to that entitlement The identity mapping, which can be missing or point at the wrong account.
Which roles should that entitlement currently grant The expected state, computed from the first three rather than read off the server.

The practical mistake is asking one boolean: "is this person a member?" These four separate payment intent from current access, and they give support enough information to fix a case without guessing.

Define the states before you automate them

ACTIVE Renewal on, access runs to the current period end.
CANCEL_SCHEDULED Renewal off, but access still runs to the current period end. Still entitled. This is the state a manual workflow mishandles most often.
PAST_DUE Renewal uncertain, access runs to a grace deadline. Needs an explicit policy, because payment retries and regional payment methods take time.
EXPIRED Renewal off and the deadline has passed. This is the only state that should remove paid roles.
OVERRIDE Access to an approved deadline, with a reason and an approver both required. This is what stops a creator fixing a support case with an invisible permanent role.

Use a small state machine rather than a pile of webhook handlers. Field names can vary; what matters is that the decision is visible in one record.

Store the source membership identifier, the linked community account identifier, the state, the access deadline, the last successful reconciliation time, and any override reason. Do not parse status out of a role name or a chat message. Those are outputs and evidence, not sources of truth.

Give each system exactly one job

Billing or membership system Owns entitlement and its deadline. In a Patreon community that is normally Patreon; in a direct subscription product it may be the billing system.
Identity linking Owns the mapping from entitlement to a community account.
Community platform Owns current role assignment, and nothing else. Discord should not own entitlement, because a role cannot explain why it exists.
Your reconciliation record Owns the explanation of any difference between the three.

Write the authority into the runbook. This boundary is what stops a common repair from becoming a new defect: if a moderator grants a permanent Discord role after a sync delay, that role outlives the membership. Create a temporary override with an owner, a reason, and an expiry instead.

Memberful’s post-setup guidance describes automated Discord role management. Use that automation, then verify its output against your own entitlement record. Automation reduces routine work; reconciliation is what catches missed events and manual exceptions.

The offboarding sequence

1. Record the cancellation without removing access Set renewal to false and copy the authoritative period end into the access deadline. Send a private confirmation naming the exact date access ends. Do not announce a cancellation in a public channel.
2. Recheck entitlement near the deadline Run reconciliation before expiry and again after it: read current membership state, resolve the linked community account, compare expected roles against actual roles.
3. Remove privileges, not the person At expiry, remove the roles granting paid channels, files, events, or moderation powers. Nothing else.
4. Confirm the change privately One concise private notice after the role change: paid access ended, these free spaces remain, here is the way back. If delivery fails because the account cannot receive messages, record the failure rather than posting publicly.
5. Preserve a clean rejoin path Keep the stable internal member identifier and the link history needed to reconnect the right account. On reactivation, recompute expected roles from current entitlement rather than restoring a remembered role list.

The sequence begins when renewal stops, not when access ends. That single ordering choice is what prevents most ghost access.

The cancellation message should answer three things: what remains available, when paid access ends, and how to reverse the cancellation. Avoid guilt language and retention tricks. A former member may still recommend the creator, join public discussion, or come back later.

A returning member should not need a new identity or a manual favour from the creator. Recomputing roles on return also protects the creator: it avoids restoring an obsolete premium or moderator role that someone held two years ago.

What a reconciliation item records

Member and entitlement state The internal stable identifier and the current state, such as EXPIRED.
Access deadline The authoritative timestamp the decision was made against.
Expected roles and actual roles Both sides of the comparison, so the mismatch is visible rather than inferred.
Action and reason What will change and why, in terms a support reply can quote.

The job must be safe to rerun. Removing an absent role should succeed as a no-change result, and adding a role that is already present should also be a no-change result. Idempotent actions are what make retries safe after a platform timeout.

Remove privileges, not the person’s history

At expiry, do not automatically delete ordinary messages, corrections, quotes, or other accepted contributions. A payment ending does not make a member’s past work invalid, and deleting it punishes the community as much as the person.

Keep public or free community roles unless the person separately asks to leave or breaks a rule. This distinction matters most in mixed communities, where paid support unlocks benefits but the conversation also includes fans who never paid.

If a private channel holds sensitive material, role removal closes future access and that is all it does. Content retention is a separate policy: document whether private posts stay in backups, whether a member can request deletion, and who approves that request. Do not improvise data deletion inside the access job.

Decide the failure cases in advance

Cancellation reversed before expiry Return the record to ACTIVE, retain access, confirm renewal privately. Do not remove and re-add the role when nothing actually changed.
Payment becomes past due Apply a documented grace period with a deadline, and explain it to the member. Never let PAST_DUE stay open forever, because that quietly becomes free permanent access.
Identity link is missing Keep the entitlement record, mark the community account unresolved, offer a bounded relink flow. Never grant a role to an account picked by matching display name.
Integration event arrives late Compare event time against current authoritative state before acting. An old cancellation event must not override a newer reactivation.
Manual complimentary access Use an OVERRIDE record with scope and expiry, so a creator can grant a month after a support failure without creating an untracked lifetime exception.
Chargeback or abuse Route to a separate risk policy. Immediate suspension may well be justified, but it carries a reason and an appeal path. Do not hide punitive action inside ordinary offboarding.
Platform outage Queue the reconciliation and retry with limits, recording intended action, last attempt, and next attempt. Never report success just because an event was received.

A production workflow needs a decision for every one of these before it meets them. Each is a case where the happy path silently does the wrong thing.

Test the behaviour, not the webhook

Cancel at period end The paid role must remain until the deadline.
Cancel immediately The role comes off only after the authoritative state changes, not on the click.
Reactivate before expiry No role churn at all.
Expire while the community API is down Reconciliation repairs it later, without losing the intent.
Add a manual role The audit reports the mismatch rather than absorbing it.
Create a temporary override It expires on its own, with no human remembering to end it.
Relink the community account The old account loses paid privileges.
Rejoin after expiry Only current tier roles come back.

Use test accounts or a staging community where you can. Then track four operational measures: expired entitlements still holding paid roles, entitled members missing paid roles, unresolved identity links, and overrides past their deadline. Give each an owner and an age, because a count without an age can hide one member stranded for weeks.

Review the results monthly even when automation looks healthy. Integration behaviour changes, moderators add roles by hand, and support exceptions accumulate. The goal is not zero cancellations. It is zero unexplained differences between what a member is owed and what the community grants.

Put the offboarding contract in writing

The member-facing policy should say when access ends, which benefits stop, what happens to ordinary contributions, how private data is handled, and how to rejoin. The internal runbook adds the system authority, the grace period, the reconciliation cadence, override approval, and the escalation owner.

Start with one concrete action: export the current paid member list and compare it against the accounts holding paid community roles. Classify every mismatch as entitled, expired, unresolved, or approved override. Fix the unexplained ones, then schedule the same comparison to run again. That is what turns offboarding from an awkward manual removal into a predictable membership lifecycle.