Question
Ghost membership gating and Stripe webhook synchronization latency
Neel Cedar
0 reputation · 14 Aug 2024, 10:50 UTC
98.5K views1
Loading…
0 reputation · 14 Aug 2024, 10:50 UTC
Ghost uses a membership system integrated with Stripe to enforce content visibility settings, specifically for posts marked as 'Paid members only'. This mechanism relies on Stripe webhook events to update member statuses in the Ghost database to grant or revoke access.
There is uncertainty regarding the exact synchronization window between a successful payment event in Stripe and the corresponding status update within Ghost. If a user attempts to access gated content immediately after a subscription change, the server-side session check may not yet reflect the updated tier, potentially leading to unexpected redirects to the sign-up page.
31775 reputation · 14 Aug 2024, 12:48 UTC
Typical delay between a successful Stripe payment and the updated membership tier in Ghost is a few seconds to under a minute, depending on network conditions and Ghost instance load. This latency is not a documented maximum; it is inferred from the usual webhook processing flow.
Confirmed facts:
ghost/members/confirm after webhook handling, which implicitly triggers a new session request and refreshes the cookie.LOG_LEVEL=debug in the environment) and note the timestamp of the Stripe webhook receipt in the logs./members/me (or use the browser dev tools to inspect the Set-Cookie header) and record the timestamp of the response.If you use a custom checkout flow that does not redirect to /members/confirm, you can obtain a fresh session token by calling /members/me after the Stripe webhook has been processed. Replace the existing session cookie with the Set-Cookie header returned in the response.
Note: This approach requires the user to be authenticated; unauthenticated users must log in again after checkout.
If you need a definitive latency figure for your specific Ghost installation (e.g., to set a timeout or alert), please provide the observed time between the Stripe webhook log entry and the updated members record in Ghost’s database.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 14 Aug 2024, 13:07 UTC
Ghost enforces paid access server-side on each request by reading the member record in its database, not by embedding tier data in the session cookie itself. The cookie only identifies the member; the membership check queries the current status after the Stripe webhook has updated the record.
That means a reload or any new authenticated request after webhook processing will reflect the new tier without signing out. The built-in Portal flow relies on redirecting to /members/confirm to generate that fresh request. Custom checkout redirects that land directly on gated content can hit the route before the webhook is processed, which is where the perceived latency appears.