#goodwill2046 - Payment Timeout

1 messages ยท Page 1 of 1 (latest)

scenic socket
#

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.

light canopy
#

Cancel is not a good idea

#

as it becomes a racing condition

scenic socket
#

How so?

light canopy
#

because the UI is interacting with customer while I have a background job call cancel at the server side?

scenic socket
#

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

light canopy
#

wow reinventing server side express checkout after paypal has did it for like 15 years?

#

I dont want to test that:

  1. 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
  2. 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

scenic socket
#

I can make a feature request from your comments. However, at this time a timeout does not currently exist on the Payment Intent API

light canopy
#

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

scenic socket
#

My question is, how is the payment Intent timing out any better for the UI than the payment intent being canceled?

light canopy
#

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

scenic socket
#

Oh, you want to be able to set the timeout from the client side?

light canopy
#

yes

#

actually when I create the intent

#

server / client doesnt matter

#

it should be embedded together

scenic socket
#

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

light canopy
#

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

scenic socket
#

You could manage all of this in your own integration. Making a call to your server when the user has abandoned the interface.

light canopy
#

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

scenic socket
#

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?

light canopy
#

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

scenic socket
#

So why don't you create your own timeout parameter that you pass to your front-end along with the Payment Intent client secret?

light canopy
#

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

scenic socket
#

I've recorded your feedback but I'm suggesting how you could address this currently

light canopy
#

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

woven ember
#

๐Ÿ‘‹ I'm hopping in since @scenic socket has to head out - give me a minute to catch up

light canopy
#

๐Ÿ‘‹