If you run a paid Discord off a Substack and people are writing in saying the link says they're not subscribed, start here. Before the comps, before the Apple purchases, before anything clever: the overwhelming majority of failed Discord access is one boring thing.
The email on their Discord account isn't the email on their Substack subscription.
That's it. They are paying you, the record is right there in Stripe, and the lookup still comes back empty — because the lookup was handed a different address than the one the subscription is filed under.
Why the mismatch is normal, not an edge case
When a subscriber clicks your link and authorizes Discord, Discord hands the tool exactly one piece of identity: the email on their Discord account. That's the only thing available to match against your Stripe customers, so that's what gets matched.
Now think about where each of those two addresses came from.
The Discord account was very likely created years ago, for a game, on whatever personal address they were using at the time. Nobody chooses a Discord email deliberately; you make the account once and never think about it again.
The Substack subscription is on the address they read newsletters at. For a professional newsletter that's frequently a work address. For anyone who has changed jobs, or moved off an old provider, or uses a plus-alias for newsletters, or subscribed on their phone with the address autofill offered — it's a coin flip.
There is no mechanism anywhere that would make these two agree. When they do agree, that's luck. Across communities we've watched get set up, the mismatch rate sits high enough that a creator with a few hundred paid subscribers should expect a steady trickle of these from day one, and a burst on the day they announce the Discord.
The related failure: Discord won't share an email at all
A smaller cousin of the same problem. If a subscriber's Discord email is unverified, Discord doesn't give us an address at all, and the flow stops with nothing to match. The fix is on their side: verify the email on the Discord account, then click the link again. It's worth recognizing because it reads like the same failure and isn't.
Two fixes that look obvious and aren't
“Just change your Discord email to match”
You're asking someone to alter the login credentials of an account they use for a dozen other communities, possibly with 2FA attached, because your newsletter's Discord can't find them. Some will do it. Most will quietly decide the community isn't worth it, and you will never hear from them again — which is the part that makes this expensive: the failure looks like silence, not like complaints.
“Just change your Substack email”
Worse. That address is where they actually want to read you, and changing it touches a live billing relationship. Nobody should have to restructure their subscription to join a chat server.
Both fixes share the same flaw anyway: they treat the two addresses being different as an error to be corrected, when it's just a fact about how people use the internet. The right move is to stop requiring them to match.
How claim codes solve it
A claim code is a one-time code sent to the address on the subscription, which proves the person holding it controls that address. Redeem it and the Discord email is never consulted at all. That is the entire point: it's the path that works precisely when the two addresses don't line up.
In StackPass, the subscriber can do this without involving you. When the link fails to find a subscription, the page doesn't dead-end on “not subscribed” — it names the email it tried, points out that it's their Discord address which often isn't the one they subscribed with, and offers My subscription uses a different email. That goes to a page where they type the address they subscribed with and a code arrives in that inbox.
Some details of that flow that are deliberate rather than incidental:
- It always says “check your inbox.” Whether or not the address matched a subscriber. If it reported failure honestly it would be a free tool for testing whether any given person subscribes to your newsletter, one address at a time.
- The code goes to the address on record, never to whatever was typed into the form. They're the same thing when it matches — but a form that emails credentials shouldn't take its destination from user input.
- Three codes per address per hour. Enough for someone fumbling, not enough to spray a mailbox.
- Self-serve codes expire in 15 minutes. The subscriber is sitting there waiting for it. Codes you send from your dashboard last 7 days, because those get read later.
The code itself is built to be retyped
Codes look like SP-7K2M-9QX4. Eight characters, from an alphabet with no I, L, O or U in it, so the usual 0-versus-O and 1-versus-l confusion can't arise. And because people read codes off one screen and type them into another, the input is forgiving: lower case works, the dashes are optional, the SP- prefix is optional, and typing an O where a zero belongs is accepted.
Small thing. But a code that can't be read aloud over a call or pasted out of a forwarded email generates its own support queue, which rather defeats the purpose.
What happens after they redeem it
This is the part that separates a claim code from a manual override, and it's worth being clear about.
The code binds to the Stripe customer, not to the email. So once it's redeemed, that Discord account and that subscription are tied together, and everything automatic resumes: cancellation removes the role within seconds, a nightly reconciliation catches anything a missed webhook would otherwise have left stale, and a Substack pause and resume works without anyone touching anything.
Binding to the customer rather than the email is also what makes it survive the subscriber changing their Substack address later. The email was only ever the delivery mechanism for the code; it isn't what the access hangs off.
One code is live per subscription at a time — issuing a new one retires the previous one — and one Discord account holds the access. If a code is forwarded and redeemed elsewhere, the second account takes the role and the first loses it. Sharing a code costs the sharer their own access instead of duplicating it, which is the behaviour you want when the alternative is one subscription quietly backing five roles.
Sending a code yourself
When someone writes to you directly rather than working through the page, your dashboard has Subscribers → Give someone access. Enter the email on their subscription— not their Discord — and hit Send code. It goes to the address on the Stripe record and lasts seven days.
The most useful habit here: when a subscriber writes in, ask “which email did you subscribe with?”rather than debugging. It's frequently not the address they're emailing you from either, and one question resolves most of these in a single reply.
If the emails really do match and it still fails
It happens, and the people it happens to are usually right when they insist their emails match. Two distinct causes, both worth checking before you assume anything else:
- The customer exists but the subscription isn't active.An expired card, a failed renewal, a subscription that lapsed a while ago. To the subscriber this looks identical to a mismatch, and sending them a code will not help — it will redeem successfully and grant nothing, leaving both of you thinking it worked.
- Their payment genuinely isn't in your Stripe account.A comp, an Apple in-app purchase, a gift, a group plan. Different problem with a different fix — see comped subscribers and app, gift and group subscriptions.
One thing to rule out rather than rule in: European payment methods. SEPA Direct Debit, iDEAL and Bancontact do create Stripe records — Substack's own documentation says so — so a subscriber paying that way is in your Stripe account and this article is their answer, not the other two.
Reduce the volume before it starts
Every one of these that a subscriber resolves without writing to you is an email neither of you sends. Two things help:
- Pin the code page in your #welcome channel, alongside your subscriber link. One line: “Subscribed with a different email than your Discord? Get a code here.”
- Say it in the welcome email too.The moment somebody joins the Discord is the moment they're most willing to spend thirty seconds sorting this out. A week later they've forgotten the community exists.
The underlying principle is worth stating plainly, because it's the thing most setups get wrong: identity on Discord and identity on Substack are separate, and any system that assumes they're the same will fail on a real fraction of your paying subscribers. Give people a way to prove the link instead of requiring it to already exist.
Related reading
- Comped subscribers and Discord access — when no payment exists at all.
- App, gift and group subscriptions — when the payment exists but not in your Stripe account.
- How to set up a paid Discord community for your Substack — the full setup, including the bot role-hierarchy trap.
Try StackPass free for 14 days
Claim codes and the self-serve code page are standard on every plan — the mismatch is too common to treat as an add-on. 14-day trial, 14-day money-back guarantee, about five minutes to set up.