#goodwill2046 - Payment Timeout
1 messages ยท Page 1 of 1 (latest)
HI ๐
How are you integrating Stripe? Are you using a Checkout Session?
You cannot "set a timeout" on a Payment Intent. But what you can do is trigger your integration to Cancel the Payment Intent after a specified amount of time.
How so?
because the UI is interacting with customer while I have a background job call cancel at the server side?
Have you looked into testing out our Server-Side finalization beta?
https://stripe.com/docs/payments/finalize-payments-on-the-server
The intent of this flow is to allow for allocation of inventory only after a customer has submitted payment information
Or other server-side checks on your part
wow reinventing server side express checkout after paypal has did it for like 15 years?
I dont want to test that:
- I have a production customer to operate, I am not paying with beta now, coz even if it works I wont be able to deploy for production
- This will significantly change our payment flow which support other payment gateway solutions as it will change how user interacts with payment
a timeout is actually easy and very crucial
I can make a feature request from your comments. However, at this time a timeout does not currently exist on the Payment Intent API
pls do
indeed this is critical
coz if stripe is controlling the timeout together it can keep the atomcity
I have been handling a customer complaint for a whole day
My question is, how is the payment Intent timing out any better for the UI than the payment intent being canceled?
because in this case the frontend SDK control the experience directly in the same flow. If I do a cancel say using a server side job with my intended timeout value then customer could be filling in the payment info while actually the payment intent has already be cancelled behind the scene
Oh, you want to be able to set the timeout from the client side?
yes
actually when I create the intent
server / client doesnt matter
it should be embedded together
Which occur server side. So what is the difference between timeout and cancel?
And we have clear demarkations between actions that are safe on the client vs the server
there is no "embedded', they are entirely different platforms
What i mean is, when I create a payment intent then to allow the frontend SDK to let customer fill in their payment information, the payment intent (created from server side) should actually let the Stripe SDK knows the max time it will allow user to use to finish the payment
Currently there is no such thing, which means customer can sit there and exceed the order timeout we have at the backend while the stripe API will still allow payment request to be made, so the authorization actually would already happened while actually the order itself is no longer transactable due to the timeout
this current design requires an additional background job to call cancel payment intent at the back while also allowing a subpar experience with customers as they can still try to pay when practically the payment should no longer be handled due to the timeout has already exceeded
so not only design is not straightforward, also the user experience is not great
You could manage all of this in your own integration. Making a call to your server when the user has abandoned the interface.
you are living in the ideal world. Customer does not interact with your UI when they go idle / kill browser / kill app
in my case its the idle that caused issue
my order timeout in 10 mins
my customer sit there enjoy your UI and finally fill in payment in 13 mins
stripe gone thru, IPN comes back, then boom my order has already cancelled
a slightly improved version is I implement a payment intent cancel call at 10mins on server, but then the customer still is playing with your UI, only realise its no longer payable, then I have a brunch more frontend exception to handle
when practically all we need is paymentIntent.expires_at
which interesting enough the session based API has similar feature
Okay but let's say we do implement the payment_intent.expries_at. This parameter can only be set/updated from the server. Doesn't your user stil wind up with a UI that will not accept a payment because they lingered too long?
I think the current flow is I created the payment intent, then I pass the payment intent ID back to the frontend SDK so the frontend SDK will know the necessary requirements from the server side payment intent?
as we are already using paymentIntent to limit payment types
So why don't you create your own timeout parameter that you pass to your front-end along with the Payment Intent client secret?
its definitely doable - just super painful. I would expect such important feature to be handled directly by SDK out of the box. Now I have another setTimeout to dismiss the dialog + trigger another API call to my server to call stripe paymentIntent cancel, and then another complete different implementation for mobile app, you think this is very intuitive?
Stripe is charging 3.4%, not the usual cyberSource 2.x%, if we end up have to do something so painful I could just do CyberSource
I've recorded your feedback but I'm suggesting how you could address this currently
ok noted - stripe is not that young anymore as a payment gateway product tho, this is quite a major overlook
I think the design of this payment flow has not carefully consider the atomicity factor of the payment process
this is especially important for JS SDK because now you are suggesting a lot of compensation measures that even relies on frontend which we have no control on how well the coordinated execution could be with a browser + JS / mobile app
even the dinosaur paypal enforce a frontend based timeout for 5 minutes that just completely kick user out from payment, so I have a clear guideline that I do say 10 minutes (some extra buffer) to abort my order I would be safe
๐ I'm hopping in since @scenic socket has to head out - give me a minute to catch up
๐