Hi there,
I have noticed this major flaw in the payment flow inside Ghost for Stripe.
For this example, I have a user signed up for a free account in Ghost with email: [email protected]
When the user [email protected] loads checkout to pay for their chosen upgrade subscription, and they choose to pay with Google Pay, if their email address associated with Google Pay is different i.e [email protected], to the email address signed up through the Ghost site, after payment is completed the user is set up with another account and not the one they already have with Ghost.
So the user now has two accounts but ghost redirects to the home page and reports that the user was signed up successfully. If the user then goes to their account it says they are still a free member and not paid - this causes confusion as they have been charged but not linked correctly.
+1 since I upgraded to v3.12.1
The subscriptions were good and now stripe webhook can't push the confirmation to Ghost.


Thanks!
@pascalandy is the webhook failure you are experiencing related to an email mismatch as well or is it something else?
My problem occurs with a fully functional email setup- using Mailgun for all events.
@gargol I'm snot sure to understand what you mean by an email mismatch here.
is the webhook failure you are experiencing related to an email mismatch as well or is it something else?
Also my Mailgun's credentials and API keys are running smoothly since more than 2 years.
@pascalandy the question was to determine if your report is related to this issue. What you've provided so far suggests it isn't, can you move to the forum to try and debug separately please?
Oh I see. I have a "Major Bug for Members Payment Flow in Stripe" but it's not the same scenario. Will document separately. Thanks!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@allouis is this still an issue now that #12055 is closed?
I haven't replicated this yet, but I don't think the fix for #12055 will have affected this