This is the second time I’ve had someone sign up for paid membership, with receipts on Stripe, while Ghost still shows them as free members. I’ve had to grant them complimentary memberships on Ghost for the time being, which isn’t ideal.
The user is using the same email address they signed up with.
Does anyone know why this happens? And how to fix it?
Sorry if this has already been answered, I searched and couldn’t find any thread.
My best guess is that Ghost is sometimes not receiving webhooks from Stripe. As for why, the place to start would be the webhook logs in Stripe for the customers who were affected. Then I’d look in your Ghost logs around the same time and see if there are clues there. E.g. does Stripe think the webhook was sent? Does Ghost log show the webhook being received.
FYI I have not seen this reported anywhere before, so it’s likely to be something odd.
@Hannah How are the webhooks set up when launching a Ghost server? My assumption is that the server makes some API requests to set up the products and webhooks automatically behind the scenes?
I think what is happening in our case is that we spin up a QA environment and the webhook URL is being updated to the QA endpoint. I can see that around the same time we launched a QA server that the webhooks for new subscriptions were being sent to the QA URL, which is why member’s subscriptions weren’t being updated in production.
Interestingly, the webhook seems to have been reset to the production URL some time since then. I’m just trying to figure out whether this theory could be correct.
@samrapdev Your debugging sounds correct, if your QA server was connected to the same Stripe account then it would have taken over the Stripe account.
Where Ghost lives can change e.g. the config can be changed, but only with a restart. Therefore on boot Ghost talks to Stripe to let it know it’s current location. This would explain why the QA server took over and then production re-corrected the URLs.
The solution is to use a dedicated Stripe account for the QA site.