Ghost membership gating latency and session refresh
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:
- Stripe webhook payloads are sent to Ghost within seconds of the payment event; Ghost processes the payload and updates its internal member record immediately.
- Ghost’s session cookie is refreshed only when the next authenticated request is made; there is no built‑in endpoint to force an immediate session refresh after a checkout.
- Ghost’s built‑in checkout button redirects to
/members/confirm after webhook handling, which implicitly triggers a new session request and refreshes the cookie.
Steps to verify latency and refresh behavior
- Enable Ghost debug logging (e.g., set
LOG_LEVEL=debug in the environment) and note the timestamp of the Stripe webhook receipt in the logs.
- Immediately after checkout, issue a client‑side request to
/members/me (or use the browser dev tools to inspect the Set-Cookie header) and record the timestamp of the response.
- Calculate the difference between the two timestamps; this measured interval is the actual latency for your environment.
Forcing a session refresh after custom checkout flows
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.
Missing diagnostic detail
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.
ghost