The usual test is: buy the thing, see the member appear, done.
That covers the failure that would have found you anyway, within the hour, in the form of a customer asking where their access is. It leaves the ones that stay hidden for months.
This is the checklist I run, in order. Around twenty minutes for one product, most of it waiting.
Before you start
Two things worth setting up so the test is honest.
A separate email address that is not your admin address. Testing with your own Ghost admin account tells you nothing, because that account already has access to everything.
A product at a token amount. Not free. A zero-value checkout can take a different path at some providers and skip the machinery you are trying to test. The smallest amount your provider will accept.
1. The purchase
Buy it. Watch three things in order.
The event arrives in Analytics, then Webhook Events, marked processed. The member appears in Ghost Admin. The member carries the tier you expected rather than whichever one happened to be granted.
That third one is skipped constantly. A member row exists, and you assume the tier is right because the member is there. Open it and read the tier.
If nothing arrived: webhook diagnosis. If the event processed but no member: the four causes.
2. The gate, from the outside
Log out. Actually log out, or open a private window, because a logged-in admin session sees everything and will tell you your paywall works when it does not.
Open a gated post as a stranger. You should be stopped.
Now log in as the test member. You should be let through.
This is the step people skip because it feels redundant after the member appeared with the right tier. It is not redundant: it is the only step that tests the Ghost side of the arrangement, and a tier that is granted but not actually configured to unlock the content is a real and quiet failure.
3. The cancellation
The one that matters most, and the one nearly everyone skips.
Cancel the subscription at the provider. Check the event arrives. Check the member’s tier is removed in Ghost. Then log in as the test member again and confirm the gated post is closed to them.
Think about who notices each failure. A broken grant is reported by a paying customer, immediately, with feeling. A broken revoke is reported by nobody, because the only person affected got something for free and the only other person involved is you, believing the system works.
Which is why this half of the test needs your eyes on it rather than an assumption.
Also decide which cancellation moment you want. Most providers send two signals: one when the customer clicks cancel, one when the period they paid for actually ends. Whether access should disappear immediately or run out is a product decision. Make it deliberately, then confirm the behaviour matches what you decided.
4. The renewal, if you can
The hardest one to test and the most expensive to have wrong.
A first charge succeeding tells you very little about the second one. Cards expire, mandates lapse, and in some markets recurring payments carry requirements that the first payment does not. That is a whole problem of its own in some countries.
Some providers let you shorten a billing period or force a renewal in sandbox. Use it if you have it.
If you cannot, do not pretend you tested it. Write it down as unverified and check your first real renewal on purpose, in the event log, rather than noticing a month later that a member silently lost access.
5. The refund
Quick, and it answers a question you would otherwise answer live.
Refund the test purchase and see what happens to the member. Some providers send a signal, some do not, and either way it is better to know now than during your first real refund request.
6. The second product
If you sell more than one thing, test the second one too.
The first product proves the connection. It does not prove the mapping for anything else, and an unmapped product is the single most common reason a payment produces no member. Every product needs its own mapping and every mapping is a separate chance to have pointed at the wrong ID.
Duplicated products deserve particular suspicion. A duplicate is a new product with a new ID, and the mapping stayed on the original.
7. Switching to live
Sandbox proves the wiring. It does not prove the live credentials, which are different values and a normal thing to get wrong on the day you switch.
So after switching: buy one real thing at a token amount, watch it work end to end, refund yourself.
Then delete the test members from Ghost Admin. They hold real tiers and will receive real newsletters, and in three months you will not remember which rows they were. If your provider has an explicit sandbox setting, check it is off; a live key with a sandbox switch left on fails in a way that reads like bad credentials.
The whole list
- Purchase: event processed, member created, correct tier
- Access: blocked logged out, open as the member
- Cancellation: event processed, tier removed, access closed again
- Renewal: tested if the provider allows it, noted as unverified if not
- Refund: know what it does before a customer asks
- Every additional product mapped and bought once
- Live credentials proven with one real purchase, test members deleted
Twenty minutes. Compare that against explaining to a few hundred members why their access changed, and it is the best-value twenty minutes in the entire setup.
Related: the setup guides for each provider, and what to check when a payment produced no member.