Ghost membership tiers: set prices and test who can read each article

Check the article each membership tier can read

A membership tier is complete only when the right people can buy it and read the content it promises. A tier appearing in a checkout menu does not prove that its members have the correct access to posts.

Ghost is publishing software with built-in memberships and subscriptions. Its tiers define membership offers and prices, while post access settings determine who can read particular content. Portal is Ghost’s reader-facing signup and account interface; use Ghost Admin to configure the offer and choose what Portal displays.

In Ghost Admin, create the product under Settings → Membership → Tiers. Set its benefits and monthly or annual price, then choose which prices appear in Portal. Stripe is the payment processor connected to Ghost; Ghost’s documentation says tier-price changes should be made in Ghost Admin, rather than directly in Stripe. (Ghost paid tiers documentation ↗ · Ghost: canceling member subscriptions ↗)

Test a report intended only for one tier

Suppose you create a tier called Research for detailed reports. If a report is available to all paid members, creating Research does not make that report exclusive. Check the post’s access setting and select the intended eligible tier. Then open the same URL with a Research account and a different paid account. The table describes the intended result for this example. (Ghost post access levels and specific tiers ↗)

Cancellation and loss of access are different events

Use separate signed-in sessions for the account states in the table so a previous Research login cannot contaminate the test. Read the article itself, not just the account screen. Compare the promised benefits with the content each account actually receives.

Canceling a renewal and ending paid access are different events. A member with paid time remaining should retain the promised access through that period; after it ends, check the restricted view again. Record the actual access end date in the test rather than assuming cancellation means immediate expiry.

Run the test again when entitlement changes

Make a test account for each tier and record what it can read before and after an upgrade, downgrade, and expiry. Use a specific article that should change access under each transition. Note the effective time so that a downgrade scheduled for the end of a paid period is not mistaken for a broken restriction during the current period.

Test through the same public page a member uses. A successful purchase screen proves that one step completed, while the article response tells you whether access matches the offer. If a member still cannot open the article, capture the account state and expected tier before changing the offer for everyone.

Test a downgrade that takes effect later

Suppose a reader on the top tier downgrades today but should retain premium access until the end of their paid period under your offer. Test the same premium article immediately and again after the effective time. Record what the payment system and website each report at both points. An early lockout and a failure to remove access later are different defects.

Also try a newly published premium article after the change. An old page can be served from a cache while a new page uses the current entitlement. If the two differ for the same account, send the exact URLs and account state to the developer rather than changing the tier’s promise for every subscriber.