#colink
autumn wedge
soft pond
Hi there
dusty dock
I have logs this time 🙂
dusty dock
Sure
Here are snippets from the logs showing the two requests to the URL to finish the transaction on our side. The lines are separated to highlight them
The two charges are ch_3M8ld6C8zhYigIfx0YCdQRTH
and ch_3M8ld8C8zhYigIfx0eXzY87j
The 302 status in one log is us redirecting the user to the receipt. The 499 status on the other is the client hanging up, because it's made a 2nd request and we can't talk to it any longer.
soft pond
Okay so this isn't Stripe Checkout
This is your own custom checkout form as you are creating PaymentIntents here
So are you disabling your "Pay" button on click?
soft pond
Not that's not the case. Here you are using the setup Checkout flow. See: https://dashboard.stripe.com/logs/req_8EjXGWIe26nLIJ for an example
dusty dock
When the enter in their payment details on Stripe's form, they're sent back our site, sometimes twice.
soft pond
You use mode: "setup",
This means that when Checkout is completed you receive a PaymentMethod
However, no charge is created here.
dusty dock
That's correct. We create the charges in response to the user coming back our site.
soft pond
You are then creating a charge using that PaymentMethod from your Server: https://dashboard.stripe.com/logs/req_OTcmDvVsyNafXN
Right
dusty dock
In this case, they came back from Stripe twice
I can't control what they on stripe's payment information form
soft pond
What does "came back from Stripe twice" mean? Like they could easily just refresh your site's page or something?
You should not be triggering a PaymentIntent based on the redirect here really
Why are you using Setup mode in this case?
dusty dock
Our cart is "special". Not only can users change common items like quantity and address, but they can change the nature of items in the cart. Because of this, we do some very extensive checks on the cart contents. The best option for doing that is the Setup mode.
soft pond
Alright well if you want to go this route then you should use some sort of client-side idempotency based on your success_url
Something is triggering your server-side code twice in terms of creating PaymentIntents
So you need to check if you already received a redirect for the UUID that is in the redirect.
dusty dock
Yes, I agree, and that something is the button on the bottom of the Paymet details form on Stripe's website.
dusty dock
The idempotency check is a race condition on multiple servers, it would not work.
soft pond
Furthermore, you aren't even accounting for the cases where a customer drops off
What about when a Checkout Session is completed and then they never reach your success URL?
Like imagine them losing connection before completing the redirect.
Are you using Webhooks here?
dusty dock
Yes, we are.
soft pond
Alright then I'd really just recommend triggering your server-side code based on those Webhooks
Instead of relying on this client-side action at all
dusty dock
So, to be clear, your feedback is that this isn't Stripe's problem, it's ours, and we have to handle the behavior?
soft pond
Correct. We redirect the client to the success_url, what happens after that is what you need to handle on your end. If you are seeing your client-side code at your success_url run multiple times, then you need to debug or program defensively there as that involves client actions which we don't control.
dusty dock
I think that's the part I don't understand.
The user is sent/redirected to the success_uri by the Stripe's form. It's not something a URI they'd find or guess.
soft pond
Sure but we don't control what happens in your client side code at all. So maybe you are re-rendering multiple times without realizing it or something else.