A reader tells you they've been paying for eight months. They can forward you the receipt. Your Discord link tells them there's no subscription on their email, and when you go and check, your Stripe dashboard agrees with the link and not with the receipt.
Both are correct. Substack has three ways of taking money for your newsletter that never pass through the Stripe account connected to it, and a subscriber can be firmly, provably paying in all three while your Stripe account has no idea they exist.
Here's each one, why it lands where it lands, and — the part that actually matters — what the right move is, which differs between them.
1. They subscribed inside the Substack iOS app
If someone taps subscribe inside the Substack app on an iPhone or iPad, that's an Apple in-app purchase. Apple collects the money. It goes through the App Store billing relationship that already exists between Apple and that reader — the same one their iCloud storage and their podcast subscriptions run through — and Apple then settles with Substack.
Your Stripe account is not part of that chain at any point. There is no charge in it, no customer, and no subscription object. This isn't a sync delay or a permissions problem you can fix by reconnecting Stripe; the transaction happened in a system your Stripe account has no window into.
Two second-order consequences worth knowing. The email on an Apple subscription is whatever the reader used with Substack, but the billingidentity is their Apple ID, which is very often a different address entirely. And these subscribers renew silently in Apple's system, so when one of them cancels, nothing anywhere in your Stripe account changes — because nothing there ever reflected them.
2. Someone gave them the subscription as a gift
A gift subscription has two people in it and Stripe only knows about one. The giver pays, so the Stripe customer carries the giver's email address. The recipient — the person actually reading you, actually asking for Discord access — appears nowhere on the payment record.
This one is nastier than the Apple case, because it fails in a way that looks like success. Search your Stripe account for the recipient's address: nothing, which at least is unambiguous. But search for the giver's address, which you'll find the moment you go looking in Stripe for the gift, and you get a healthy live subscription. It is extremely tempting to treat that as the match and send a code against it.
Don't, for two concrete reasons.
A claim code is always emailed to the address on the subscription record, never to an address typed into a form — a form that emails credentials shouldn't take its destination from user input. So the code for a gift subscription goes to the giver'sinbox, not the reader's. And a code binds to the Stripe customer, with one Discord account per customer enforced: if the giver is also in your Discord, whichever of the two redeems second takes the role and the other one silently loses it.
A gift is one payment. The reader is a second person who needs access. Those are different things and shouldn't be forced through the same record.
3. They're a seat on a group or team plan
Same shape as a gift, multiplied. A company or team buys a group plan, one card is charged, and your Stripe account gets one customer carrying the buyer's email— usually someone in finance who will never read a word you write. The eleven colleagues on the plan are real subscribers with no payment record of their own.
The single-Discord-account-per-customer rule bites hardest here, and it's doing its job: without it, one subscription would back unlimited Discord roles, which is a hole rather than a feature. But it does mean a group plan cannot be served by handing round one code. Every seat needs its own entitlement.
What doesn't cause this (a myth worth killing)
You'll see it claimed that European payment methods — SEPA Direct Debit, iDEAL, Bancontact — bypass Stripe and produce the same invisibility. They don't. Substack's own documentation is clear that direct debit payments create Stripe records like any card payment does; they're Stripe payment methods, processed by Stripe, landing in your connected account.
This matters practically. If a subscriber paying by iDEAL or SEPA can't get into your Discord, the record isthere and something else is wrong — nearly always a mismatch between their Discord email and their Substack email. Treating them as an invisible-payment case means giving them a manual grant that never expires instead of a code that stays in sync forever. Check the easy thing first.
How to find out which one you're looking at
Ask. It sounds unsatisfying, but there is no reliable way to distinguish these three from your side — all of them look identical in Stripe, which is to say they look like nothing at all.
When a StackPasslink fails to find a subscription, the page doesn't dead-end. It offers a code request for the email-mismatch case, and a prefilled message to you for everything else, which asks the reader to say how they paid — in the Substack app, a gift, a group plan, or something else. The answers come back in your inbox already sorted into the categories you need.
Cross-check it against your Substack subscriber list, not your Stripe dashboard. Substack knows about all three of these; Stripe knows about none of them. That list is your source of truth for this entire class of subscriber.
The fix: a grant labelled “Paid outside Stripe”
Once you've confirmed on Substack that the person is genuinely paying, go to Subscribers → Give someone access in your StackPass dashboard, enter their email and hit Send code. Stripe gets checked first, always — occasionally the answer turns out to be an ordinary subscription after all, and then you're done with nothing manual involved.
When that lookup comes back empty, the grant form appears. Choose the Paid outside Stripe label rather than Comped, and write a reason that records what you learned: “pays via Apple in Substack app, confirmed on Substack 2026-09-11, MS”. StackPass records the grant and emails them a claim code, good for seven days. They click it, authorize Discord, and the role lands.
For a group plan, repeat that per seat. Tedious, but each grant is then a separate thing you can revoke when one person leaves the company, which is the behaviour you want.
Why this label, specifically
The label isn't decoration. A comp is true because you decided it, and stays true until you decide otherwise — so those grants carry no review date. “Paid outside Stripe” is a different kind of claim: it's an assumption about billing you can't see, held in a system you don't control, and it can stop being true without anything happening on your side at all.
So those grants come with a review date 30 days out. When it falls due, the grant is flagged in your dashboard, you check the name against your Substack list, and click Still paying to push it out another 30 days or Revoketo take the role back. Revocation is immediate — the role comes off in the same request, and any unused code stops working.
Without that nudge, “I'll check Substack monthly” is a promise you make to yourself that nothing enforces, and the failure is completely silent: someone cancels in the Substack app, no webhook fires because there was never a subscription to fire one, and they hold a paid role indefinitely.
When they switch to paying you directly
Apple in-app subscribers sometimes move to paying on the web later — often after you mention that more of it reaches you that way. When that happens a real Stripe customer appears for them, and the manual grant is now redundant and actively harmful, because it's suppressing the automatic revocation that a real subscription would otherwise get.
Revoke the grant. They drop back to ordinary automatic sync driven by Stripe, and from that point on their access follows their subscription with nothing manual in the loop. If they happen to redeem a subscription-backed code, that switch happens on its own — the grant is superseded and Stripe takes over.
Related reading
- Comped subscribers and Discord access — the other class of subscriber Stripe can't see, and why it's treated differently.
- When the Discord email doesn't match the Substack email — check this before assuming a payment is invisible.
- How to set up a paid Discord community for your Substack — the end-to-end walkthrough.
Try StackPass free for 14 days
Manual grants, claim codes and the review queue are in every plan — they're not an upsell, they're the part of the job most tools pretend doesn't exist. 14-day trial, 14-day money-back guarantee.