Skip to main content
This is the setup the Paywall page walks you through: the post stays Public in Ghost, the PayGlue snippet marks where the gate starts, and the overlay hides everything below it in the reader’s browser. After a purchase, PayGlue sets the payglue-active label on the member and the overlay opens for them; when the subscription ends, the label goes and the overlay closes again. It is the only option that works without Stripe and still shows the reader your offers at the gate, because the overlay is yours. It is also a client-side gate, and this page says plainly what that means.
In one sentence: the post is delivered in full, the overlay hides part of it in the browser. Everything that reads the post without a browser reads all of it.

What client-side means

Ghost delivers a Public post in full, the same way it delivers any public post. The PayGlue header script then looks at the logged-in member and hides the part below the snippet unless that member has access. The gated part is therefore hidden only where the script runs: in a browser, with JavaScript on. Ghost’s own gating is the opposite. For a restricted post, Ghost never sends the gated part to a visitor who is not allowed to see it. It is not hidden, it is absent, and that holds for every channel Ghost serves. That is option 2 and option 3.

Where the gated part stays readable

The feed and the social web matter most, because reading there takes no effort and no intent. A subscriber of your RSS feed sees the whole post in their reader without knowing there was a gate.

Why it cannot work any other way

Ghost decides on the server what a post contains for a given visitor, and it does so through one mechanism: the post’s visibility, checked against the member’s status. A member is free, paid, or comped. Paid and comped exist only when Stripe is connected. Without Stripe, every member is free, and there is nothing for “Paid members only” to check against. Everything outside Ghost, PayGlue included, talks to Ghost through the Admin API, the Content API and webhooks. Those interfaces can create members, set labels, read posts and receive events. None of them sits in the path where Ghost renders a post for a visitor, builds the RSS feed or federates to the social web. There is no hook for a third party to say “for this visitor, stop the post here”. The official integrations all live on the same side of that line. So an external paywall for Ghost has two options: hide the content after Ghost has delivered it, which is what PayGlue does, or hold the paid part outside Ghost and inject it after checking access, which means the paid part is no longer a Ghost post at all. Other paywall widgets for Ghost work the same way, for the same reason.
Simplified: the PayGlue overlay is a softer paywall than Ghost’s native one, in the same class as most JavaScript paywalls on the web. That is the trade, and it is written down here so you can make it knowingly.

Two classes of paywalls

Server-side paywalls never deliver the paid part. Ghost with Stripe, Substack, Patreon. There is nothing to bypass in the browser, because nothing arrived. Getting past them takes a person: a shared login, a copy from a paying member. Client-side paywalls deliver everything and hide part of it. Many news sites, other Ghost paywall widgets, the PayGlue overlay. Reader mode, JavaScript off or DevTools open them, and a feed reader never saw the gate to begin with. Neither class is wrong. They fit different content.

What this option is good for

Newsletters, archives, community posts, the second half of an article: content where the value is in being a member, not in the text being secret. For that, a soft gate converts well, the reader sees your providers at the moment they decide, and nobody is harmed if a determined reader gets through.
Do not put secrets behind it. Credentials, download links to paid files, personal data, anything that would matter if it leaked: keep it out of a paywalled post entirely.
If the content must stay out of feeds, use Ghost’s own gate instead: option 2 without Stripe, knowing that every free member can read it, or option 3 with an idle Stripe account, which is the real paid gate.
If you want the reasoning at article length, including the comparison with other paywall widgets and why a client-side gate still earns its keep: A Paywall Is a Door, Not a Vault.

Could PayGlue offer a server-side gate of its own?

Only by holding the paid part itself and injecting it after checking access. That is a different product from today’s overlay: the paid part would live at PayGlue, not in your Ghost post, with everything that follows for editing, search and export. If a server-side gate turns out to matter to our customers, it is something we can build. It is not on the roadmap today.