Where do I look first?

The webhook event log, before touching any settings. It answers the only question that matters at the start: did the event arrive at all? Everything you do next depends on that answer, and guessing wastes an afternoon.

I renamed my organisation. Did that break anything?

Yes, and this is a common one. The webhook URL contains your organisation slug, so renaming changes every provider's URL. The old one stops matching and events go nowhere. Copy the new URL from each provider's connection page and update it in the provider.

The event says processed but the member has no access.

Then the webhook is fine and the mapping is not. A processed event with no result means PayGlue received it, verified it, and had no instruction for that product. Open the Buy Button, Paywall or Pricing Table editor and configure the Ghost tier for it.

Could Ghost be the problem rather than the provider?

Yes. A regenerated or revoked Admin API key produces a 401 and no member gets created, even though the webhook arrived perfectly. The event log distinguishes this: you will see the event with a Ghost API error rather than no event at all.

My Ghost Webhook Isn't Firing: A Diagnosis Checklist

Somebody paid. No Ghost member appeared. The temptation is to start re-entering credentials.

Do not. Three completely different faults produce that same symptom, they need three different fixes, and one look at the event log tells you which one you have.

Start at the event log, always

Open Analytics, then Webhook Events, and find the purchase.

What you see there splits the problem immediately:

What the log shows	What is actually wrong	Where to fix it
No event at all	The webhook never arrived	The provider’s webhook settings
Event with a signature error	It arrived but could not be trusted	The webhook secret, both sides
Event failed with a Ghost error	It arrived and Ghost refused	Your Ghost credentials
Event processed, nothing happened	It arrived and had no instructions	Your product mapping

Those are four different afternoons. Reading the log first is the difference between fixing this in two minutes and rebuilding a working integration for no reason.

Case one: no event at all

The provider never delivered, or delivered somewhere else. Nothing on this side can help, because nothing on this side was ever contacted.

Check the URL in your provider first. It should look like this:

https://api.payglue.io/webhooks/polar?tenant=your-org-slug

Two things go wrong with it.

A truncated copy. People select the visible part of the field and miss the end. Copy the whole string from the connection page using the copy button rather than by hand.

A stale slug. If you ever renamed your organisation, every webhook URL changed with it. The old URL still exists as text in your provider’s settings and still points at a slug that no longer matches. Nothing errors. Events simply arrive addressed to somebody who does not exist.

This is worth checking even when you are sure you did not rename anything, because it is silent and it survives everything else you try.

Then check the provider actually attempted delivery. Most providers keep their own delivery log: Polar, Paddle, Lemon Squeezy and PayPal all show attempts and responses. If the provider shows no attempt, the problem is upstream of the URL entirely, usually an unselected event type.

Which leads to the second most common cause here: the event is not enabled. A webhook registered for subscription.created alone will sit silent when somebody makes a one-off purchase, because that fires order.created. Go back to the setup guide for your provider and confirm every event in the list is ticked, not just the obvious one.

Case two: signature mismatch

The event arrived and was rejected, which is the system working correctly with the wrong input.

The provider signed the payload with one secret and PayGlue checked it with another. Re-copy the secret from the provider and paste it into the connection page. Paste, do not retype.

Two provider-specific notes:

Lemon Squeezy does not generate the secret, you invent it and enter the same string on both sides. So the failure is not a lost secret but two slightly different ones, and a trailing space is enough.

Ko-fi does not sign at all. It sends a verification token in the payload instead, so a mismatch there shows up the same way but the fix is re-copying the token from Ko-fi’s Webhooks settings.

Case three: Ghost refused

The webhook arrived, was verified, and Ghost rejected the member.

Ghost error	Cause	Fix
`401 Unauthorized`	Invalid or expired Admin API key	Regenerate the key in Ghost and update it under Connection, then Ghost CMS
`404 Not Found`	Wrong Ghost Admin URL	Check the URL under Connection, then Ghost CMS
`422 Unprocessable Entity`	Invalid member data, usually the email	Check the email format in the event log

The 401 is the one that appears out of nowhere on a working setup. If you regenerated your Ghost integration key, or somebody on your team deleted and recreated the integration, the stored key stops working immediately and every purchase from that moment fails. Nothing warns you. The first sign is a customer email.

Worth a calendar note: if you ever rotate Ghost keys, update PayGlue in the same sitting.

Case four: processed, and nothing happened

This one confuses people the most, because the log says the event succeeded.

It did. PayGlue received it, verified the signature, matched it to your organisation, and then found no instruction for that product. So it did nothing, correctly, and recorded that it did nothing.

Open the Buy Button, Paywall or Pricing Table editor, find the product, and configure which Ghost tier it grants. Then buy it again.

This is the expected state right after setup and before the first mapping, which is why it is worth knowing it looks like this rather than like an error.

The one-minute version

Open the event log and find the purchase
No event? Wrong URL, stale slug, or the event type is not enabled in the provider
Signature error? Re-copy the secret, both sides must match exactly
Ghost error? Your Admin API key or URL, usually a rotated key
Processed but nothing happened? No mapping for that product

What not to do

Resist re-entering every credential. It feels productive and it destroys the evidence: if the Ghost key was fine and you replace it anyway, you now have two variables instead of one.

Resist deleting and recreating the webhook in the provider before you have checked the URL, because recreating it with the same wrong URL buys you the same silence.

And do not debug with a real customer’s purchase. Buy your own product at a token amount and refund it afterwards. You want to trigger the failure on demand rather than wait for somebody else to hit it.

Prevention, mostly

Two habits catch nearly all of this before a customer does.

Test the revoke, not just the grant. Almost everyone checks that a purchase creates a member. Far fewer check that a cancellation removes access, which is the half that fails without a sound for months. Buy, cancel, confirm the access is gone, then refund.

Then re-run that test after any rename or key rotation. Both change things that look unrelated: renaming the organisation changes the webhook URL, rotating the Ghost key breaks member creation, and neither announces itself.

If you are still stuck after all of this, the event ID in the log is the thing to send me. It points directly at what happened rather than at what should have happened.