#colink
serene vale
raven fossil
Thanks @serene vale
The Stripe checkout type is approval and passing the setup-intent back to our system, then charging the payment method.
devout crow
Do you know why/how the double-submits are happening?
raven fossil
I'm assuming it's customers using mobile devices and accidently double clicking the submit button on Stripe's payment form.
We had similar problems years ago until we implemented double-click protection on buttons and links in our cart.
devout crow
Digging a bit on this and will circle back shortly
Do you have repeat Events I can look at as examples of this behavior?
raven fossil
I can give you a customer ID that will show the two requests back from our servers. I'm assuming that it's safe to post something like that here?
devout crow
Definitely
raven fossil
cus_MMnJeKtmIlOlTY
If you check the logs, you'll see that they came to Stripe to enter in payment information, then there are 2 payment intent requests, from different IP addresses. I'm taking that to mean two submits on the Stripe form.
Note, we run about 70 checkouts per day, and this has only happened about 3 times in the last 4 weeks, so it's very intermittent, but we'd really like to have the checkout system be as smooth as possible.
devout crow
Still digging. Will jump back in in a couple minutes
raven fossil
👍
devout crow
So, looking at the logs for that Customer: https://dashboard.stripe.com/logs?object=cus_MMnJeKtmIlOlTY
It looks like the duplicate requests (the most recent events on the list) have nothing to do with Stripe Checkout. Somewhere your server is creating Payment Intents.
Does all of that seem correct so far?
raven fossil
Yes, and no
We get passed back a setup intent from Stripe. When the custom returns to the site, it uses the setup intent to change the payment method in the intent. Since it got two sets of those, there had to be 2 form submits.
devout crow
I don't know if that necessarily means that there are 2 form submits (though there could be), but nonetheless it might be worth zooming out a little bit and looking at your integration as a whole.
We get passed back a setup intent from Stripe.
You have to make an API call in order to get a setup intent. If you look at the Events for that Customer, you can see that only 1 setup intent was created: https://dashboard.stripe.com/events?related_object=cus_MMnJeKtmIlOlTY, but 2 Payment Intents were created and neither of them were created by Stripe Checkout
raven fossil
That's correct.
But when the user clicks on the button on the bottom of the payment form on Stripe, they get redirected back to our site. Our site will not send them to two different servers, that can only come from two different redirects from Stripe.
If they hit the back button, and tried to approve the payment again
That wouldn't work, since the cart had already hit the final checkout stage from the first click
Also, given the timing between the two payment intents (2 seconds apart), there's not time for that kind of user action.
devout crow
Right, so it's very unlikely that there were 2 form submits.
But let's back up. Do you know what your integration is doing after the setup intent is completed? Like, can you go to the code and follow it through every step to see what is happening once the setup intent succeeds?
raven fossil
The setup intent comes via a webook. In the webhook, we use the setup intent to look up the payment intent.
When the user returns to the site, it uses that payment intent to charge the payment method, ad then to fetch the charge id association with that payment of funds.
devout crow
I don't think that's what's happening. If you look at the logs of all the Events that are being performed for this customer, you see that less than a second after the setup intent succeeds, a Checkout Session is created, then ~18 seconds after that the 2 Payment Intents are being created.
There's no "use the setup intent to look up the payment intent". The setup intent does not have a payment intent.
raven fossil
Just a moment please, I'm looking up a link
Please see step 4.
"Using the setup_intent ID, retrieve the SetupIntent object. The returned object contains a payment_method ID that you can attach to a customer in the next step."
devout crow
That's a Payment Method, not a Payment Intent
raven fossil
You're right, I used to the wrong terms
devout crow
Ah, okay. That makes more sense then.
raven fossil
I'm sorry if that confused you.
devout crow
All good. Just want to make sure I'm understanding everything. Are those the docs you followed to create this integration? If so, there's still somewhere else in your code that is making requests to create Payment Intents, because those 2 Payment Intents are not being created by Stripe Checkout.
If they were, the Source would say "checkout"
raven fossil
Right. The payment intent is created by our system. But again, if you look at the logs, the two payment intents are coming from different IP addresses. That means that two requests were made by the user to go back to the site, and that can only come from Stripe's payment setup form.
gray pendant
Hi 👋 I'm jumping in as @devout crow needs to go.
raven fossil
@devout crow, thanks for your patience, and for your help.
gray pendant
Can you describe what your integration does here?
- At what point do you use Checkout Session?
- What triggers the Payment Intent creation?
A clear set of steps relating both API requests from your server and Stripe responses will help me understand what is going on here.
raven fossil
We create a checkout session in "setup" mode, to have the user enter in their payment details.
The Payment Intent is triggered by the user returning to the site from Stripe. Once they return, it uses the payment method to create a payment intent with the correct amount.
gray pendant
Okay so the redirect to the return_url is how your integration triggers the Payment Intent?
raven fossil
Yes
On the hardware side of things, for uptime and redundancy and scaling, we run a load balancer and 2+ servers behind it. The load balancer sprays requests across the servers.
gray pendant
And when you look at request logs in your integration you are seeing the redirect occur twice? I can confirm that the Submit button is immediately disabled after the initial click.
raven fossil
With payment intents coming from two different IP addresses, there has to be two incoming requests.
Unfortunately, one of the two servers rotated out of service, so I can't check the logs. I only noticed today while looking in Stripe's logs that the payment intents are coming from different IP addresses.
raven fossil
I'll wait until it happens again, drop the two affected servers from rotation and set aside their logs to show where the requests are coming from.
gray pendant
That would be very helpful. I've been reviewing all our logs for the most recent Checkout Sessions and I only see a single redirect for each
raven fossil
Thanks for your help today. It's very appreciated.