#Private Citizen
pliant holly
silent sparrow
Hi 👋
Do you have API request IDs for the failed transactions so I could take a look?
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
delicate ginkgo
req_dm9G2s1GuLZPH6
Background. Using stripe for subscriptions, i send a new user to stripe for payment first, when stripe sends me the invoice.paid event i create an account on my side.
silent sparrow
Okay, I see the pattern here.
But the customer needs to exist in Stripe before the Invoice is paid
delicate ginkgo
In this case, the cc was declined, but stripe created a customer anyways then tries to send events for customer.updated but there is no customer on my side because no payment ever happened. So now those events have been bouncing all weekend.
So what is best way to resolve this issue?
I designed my API to reject an event if a customer doesn't exist on my end to have some way of "knowing" when there is an issue, so a real customer doesn't get a silent fail. Because i assumed i should never get an update for a customer that doesn't exist.
silent sparrow
From my perspective I would listen for the customer.created webhook event and track those customers.
The trouble with your approach is that is not how webhooks are designed
The success response you return is simply to acknowledge you received the event
delicate ginkgo
And how can i cancel the two webhooks that have been retrying? I only see a button to [Resend] but not cancel.
silent sparrow
Anything else is something your integration needs to handle
You need to return a 200
Any webhook request from Stripe that you can authenticate should receive a 200 response
Everything after that (does this Customer exist, etc.) is something your integration needs to handle
delicate ginkgo
Okay, and no option to not have a customer created for a failed payment?
silent sparrow
It depends on how they are interfacing. Your integration creates the Payment Method first, which seems odd to me.
But I think it's ultimately how the Subscription is configured to behave
delicate ginkgo
Follow up question to that, since stripe created a customer for this users name and email address. What happens if they come back and try again, get sent to stripe as a new customer with the same name and email in the previously created customer account?
silent sparrow
They can
delicate ginkgo
But I think it's ultimately how the Subscription is configured to behave
Yes, im not manually creating customers. I am only using the checkout call for subscriptions.
silent sparrow
It would be up to your system to ID the the customer by those characteristics.
delicate ginkgo
They can
So no issue with stripe complaining customer exist by that email. I just get zombie customers in the stripe database?
silent sparrow
You can use the payment_behavior setting of error_if_incomplete to cause the whole process to halt and return a 402 if the first payment fails
delicate ginkgo
You can use the `payment_behavior` setting of `error_if_incomplete` to cause the...
You have a doc link explaining more about this?
delicate ginkgo
I think the way my side was designed was because there is no guarantee of the order of events. Sometimes an update comes before the invoice.paid which creates the customer on my side. The way it is now, if i get the update first, it bounces, then i get the paid, customer created, next update retry then works because now the customer exist.
silent sparrow
Either way, you shouldn't "bounce" a webhook event. All that does is cause more work for both your servers and ours. If the event is valid (from Stripe) you return a 200 and figure out what to do from there
delicate ginkgo
Any my desire is to only have to create accounts for paid subscriptions.
silent sparrow
Okay, that's fine
delicate ginkgo
Either way, you shouldn't "bounce" a webhook event. All that does is cause more...
Yes, i understand and will find a solution.
silent sparrow
Makes perfect sense
So if you use error_if_incomplete as your payment behavior it should prevent the customer from being created
how are you creating your subscriptions?
delicate ginkgo
Do you know off the top of your head, in the customer.updated event is there any info contained in that which would flag its for a customer of a failed transaction?
delicate ginkgo
So if you use `error_if_incomplete` as your payment behavior it should prevent t...
I will have to re-read the docs on that, cause i had a different take way.
delicate ginkgo
how are you creating your subscriptions?
I send customer to stripe with
\Stripe\Checkout\Session::create($checkout_obj);
Then when i get a webhook for invoice.paid i use the info from there such as customer object to populate a customer record on my side.
So if someone doesn't complete checkout, no payment made, im not adding zombie meaningless accounts to my SQL.
It would be insane (for me) to create SQL records any time someone online hit "checkout"
silent sparrow
Okay so it doesn't look like we allow modification of the payment_behavior setting on the Subscription through Checkout.
So in this case you would just need to allow your system to ignore the missing customer record.
delicate ginkgo
Ok.
silent sparrow
You can also configure the Checkout Session to only create a Customer record if required: https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-customer_creation
But I think that might still create one in this case because of how the Subscription will behave (assumes the customer will try again with another payment method).
delicate ginkgo
As in try again in same current session without leaving the checkout page, or come back another day?
silent sparrow
In this case it would be come back another day. The purpose for creating the Customer and Subscription from Stripe's perspective is to allow you to do outreach and try to get the customer to pay.
delicate ginkgo
Setting customer_creation to if_required means no customers are created even for successful payments? What does this do to reoccurring payments and the user's billing portal?
silent sparrow
As the doc I linked said:
The Checkout Session will only create a Customer if it is required for Session confirmation. Currently, only subscription mode Sessions require a Customer.
So using that parameter would actually likely not change anything here
I just thought it might be worth a shot. All Subscriptions require a Customer object to be associated with
delicate ginkgo
Guess i read it too fast, i thought it said none of the subs require customers 😊
silent sparrow
No worries. There's a lot of small text on those reference pages
delicate ginkgo
Okay, so summary, im stuck with customers being created on declined payments, and i need to figure out how to deal with those updates on my end and give the webhook its 200.
silent sparrow
Essentially yes. Because the Subscription object will get created (in the hope you can collect payment with another card) and the Subscription object requires a Customer object to be associated with.
delicate ginkgo
Okay, i can't think of anything else, im done, you can close this thread. Thanks for the guidance.
silent sparrow
Happy to help 🙂
delicate ginkgo
Is there a way to see older webhooks from a month ago or are they purged?
silent sparrow
Webhook events are only retained for 30 days