#groundhogdayrugbyrat_best-practices

1 messages · Page 1 of 1 (latest)

shell pineBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1220000279567798313

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

real oakBOT
karmic stratus
rustic hearth
#

Hey there, so this seems like a useful start.
Just to clarify my route is the following :

  • User clicks pay for let's say £24.98
  • We're using payment elements to create a payment intent
  • Confirming that the amount is correct (and other checks behind the scenes) and then confirming the payment intent server side

The caveats are when we have things such as 3DS to contend with, as such based on the response, Im returning the payment intent status (which might be requires_action), and so calling handleNextAction in my FE.

Does that seem logical?

#

Or is there a better approach? As I say we can't "lock" prices, so if the price was to change we return that from our API call to the FE and say to the user "hey look your price changed".
This works for the "pre-handle next action" flow, however with the handle next action, that confirms it client side and so I'm struggling to see how we can verify the amount at the point of handleNextAction (i.e. they leave the 3D secure window open for 1-2 mins and the price has changed).

karmic stratus
#

Hmm, if they've already initiated 3DS flow then it might be impossible to change the price at that point given we've already communicated with the issuer.

The only option there would be to have a timer (for like 60 seconds) and cancel the PaymentIntent for the old amount (so that the transaction doesn't go through when customer eventually completes 3DS) and try again with new PaymentIntent.

rustic hearth
#

Gotcha, this is very "edge case" but I'm trying to factor that all. Regardless of that,with "handleNextAction" in my JS code there's no need to confirm server side after that correct? I just do "post payment activities"?

karmic stratus
#

I believe so. Would recommend just testing it out to be 100% certain

rustic hearth
#

THanks that helps a lot and helps rationalise my choice here!