All articles
substackdiscordcompedtroubleshooting

Comped Substack subscribers can't reach your Discord

By Michael Sikand

You comped a few people. Your first hundred readers, a friend who gave you your first quote, a journalist you want in the room. Substack makes it one click, and it feels like the least you can do.

Then you open a paid Discord, wire up the sync, and every one of those people writes to say it told them they aren't a subscriber.

They're not doing anything wrong, and neither is the tool. This is a structural gap, and it's worth understanding exactly where it sits before you go looking for a setting to fix it, because there isn't one.

Why Stripe has nothing to tell you

Every Discord sync tool for Substack — StackPassincluded — works the same way underneath. Substack processes paid subscriptions through your ownStripe account. So the tool connects to that Stripe account, reads the subscriptions in it, and treats “has an active subscription” as “should have the Discord role.” That's the whole mechanism, and for people who pay you it works very well.

A comp is the case where the mechanism has nothing to read. No money changes hands, so Stripe is never involved: there is no charge, no invoice, no customer, and above all no subscription object. Substack knows the person is a paid subscriber, because Substack is holding that fact in its own database. Stripe has never heard of them.

So when a comped reader clicks your Discord link, the lookup runs, comes back empty, and the honest answer is “no subscription found.” The tool isn't missing them. There is genuinely nothing there.

This is also why no amount of re-checking helps. A subscriber whose email simply doesn't match — a much more common problem, and one we wrote about separately — can be found by searching for the right address. A comped subscriber can't be found by any address, because the record does not exist to be found.

The three bad workarounds

Before the good option, the three that creators reach for first, and what each one costs.

Charging them $1 to create a Stripe record

This does work, in the narrow sense that it produces a subscription the sync can see. It also means telling someone you comped that they need to enter a card, which undoes the gesture, and it leaves you with a real subscription you now have to remember to keep alive or the role disappears on its own.

Granting the role by hand in Discord

Fast, free, and the reason most creators eventually have a Discord full of roles nobody can account for. The problem isn't granting it, it's that a hand-granted role has no record attached: six months later you are looking at a name in your member list with a paid role and no way to reconstruct whether that was a comp, a test, or a mistake. If the comp ends, nothing tells you.

A second “friends” role with its own channels

Tempting, and occasionally right if the comped group genuinely gets something different. But if the point of comping someone is that they get the full thing, splitting them into a parallel role means splitting the conversation too, and the community you wanted them in is now the one they can't see.

What StackPass actually does

We built a manual grant for exactly this, and we built it to behave like the exception it is rather than like a second, easier way to hand out roles.

In your dashboard, under Subscribers, there's a panel called Give someone access. You type the email on their subscription and hit Send code. Stripe gets asked first, every time. If there's a live subscription on that address, a claim code goes out and you're done — nothing manual happens, because nothing manual was needed.

The grant form only appears afterthat lookup has come back empty. That ordering is deliberate. Reaching for a manual grant when the person actually has a subscription quietly switches off automatic revocation for them forever, which is the kind of mistake that costs you nothing today and a paying-subscriber-shaped hole in a year. You can't reach the manual answer here without first establishing that you need it.

Once it appears, the grant asks for two things:

  • A label. Either Comped or Paid outside Stripe. These are not cosmetic; they change what happens next, which I'll come to.
  • A reason, in free text, plus your initials.Required — the grant won't save without it. If more than one person has your dashboard login, this is the only field that can say who did this and why.

Submit it and two things happen. A grant is recorded against that email address, and StackPass emails them a claim code — something like SP-7K2M-9QX4, good for seven days. They click through, authorize Discord, get added to your server if they aren't already in it, and the role lands.

Why a code, and not just a Discord username

The obvious design would be a box where you type someone's Discord handle. We deliberately didn't build that, for two reasons.

First, a typed handle is unverified. Discord usernames are not unique in the way people assume, and a one-character slip hands paid access to a stranger with no signal that anything went wrong. The email round-trip is the only proof available that the person on the other end is the person you meant.

Second, and more practically: adding somebody to a Discord server requires theirauthorization, not yours. That authorization only exists at the moment they click through and approve it. A grant made straight to a handle would have been an entitlement we could record and then couldn't act on.

Comped and “paid outside Stripe” are treated differently

This is the part most worth internalizing, because it's the difference between a grant you can forget about and one you can't.

Compedcarries no review date. A comp is true because you decided it's true. There is no external system holding a fact that could contradict you, so asking you to re-confirm your own decision every month would be noise, and noise in a review queue is how real reviews get ignored.

Paid outside Stripe— an Apple in-app purchase, a gift, a group plan, all covered in the companion piece — is an assumption about somebody else's billing, and assumptions go stale silently. Those grants get a review date 30 days out. When it comes due the grant is flagged in your dashboard and you confirm against your Substack subscriber list: still paying, or not. One click for Still paying, which pushes the date out another 30 days, or Revoke.

The failure mode this exists to prevent is invisible by design: somebody stops paying, nothing in Stripe changes because nothing in Stripe was ever there, and they keep a paid role indefinitely while every dashboard you own reports that everything is fine.

What a grant does and doesn't do

Worth being precise, because “manual” is doing real work in that phrase:

  • It does not sync.A granted subscriber keeps the role until you revoke it. Nothing else will take it away — not a cancellation, not the nightly reconciliation, not a failed payment, because there is no payment to fail.
  • Revoking takes the role back immediately.Not on tomorrow's cron. The role comes off in the same request, and any claim code they were sent and never used stops working at the same moment.
  • The record survives revocation. The grant row stays, with its label, its reason and who wrote it. What you lose when you revoke is the access, not the history of why it was there.
  • It doesn't need them to remember the code.If the comped reader's Discord account happens to use the same address you granted, the normal subscriber link just works for them — the grant is found directly and they're let in. The code is the fallback for when the two addresses differ.
  • One Discord account per grant. If a code gets forwarded and redeemed on a second Discord account, the second one takes the access and the first loses the role. Sharing a code costs the sharer their own access rather than multiplying it.

A working habit for comps

Two suggestions from watching this go wrong. Comp people in small batches rather than all at once, so the grants list stays something you can read down and recognize. And write reasons a stranger could act on: “launch-week comp, MS” is useful in a year, “friend” is not.

That's really the whole argument for doing this in the product rather than by hand in Discord. The role is the easy part. What you actually want is to still know, twelve months from now, why each person holding it has it.

Related reading

Try StackPass free for 14 days

14-day trial, 14-day money-back guarantee, and we email you 3 days before the trial ends so nothing charges you by surprise. Setup takes about five minutes.

→ Start your StackPass trial

Ready to try it?

StackPass gives your paying Substack subscribers a role in your Discord. 14-day free trial.

See pricing