#amrux
kindred idolBOT
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- amrux, 20 hours ago, 7 messages
viscid hawk
Hi there!
lean canyon
Hey :D
viscid hawk
Just wondering with next actions (such as 3D secure), this says to do it via the client...
Yes if 3DS is required, then it has to be done by the user on the frontend, there's no other way.
how can we allow for extra business logic between the initial card "pay" click and then 3DS "pay" click if we are confirming via the frontend?
You mean potientially cancelling the payment if the user took too long to confirm the payment?
lean canyon
So yes along those lines, effectively we need to make sure that the price they are paying is "accurate" to the time.
For example:
A user starts at 10:58, clicks pay and 3DS pops up at 10:59. They do their 3DS check successfully and it's 11:01, the price could have changed on the hour. Does that makes sense as a problem case?
So it's less of a problem of the "frontend" confirming it, Im fine with that, what Im struggling to understand is in a flow where the server is confirming most payments, why with 3DS we're leaving that to the client completely?
I.E. should the 3DS payment not update the payment intent ID which we can then finalise via the server? Or a webhook for the server to say "yes let's take payment now"
I guess what I'm looking for is there a way for the client to update the status to say "3DS confirmed but payment not taken" which the server can then listen for
hollow ledge
👋 taking over for my colleague. Let me catch up.
lean canyon
Hey there :)
hollow ledge
A user starts at 10:58, clicks pay and 3DS pops up at 10:59. They do their 3DS check successfully and it's 11:01, the price could have changed on the hour. Does that makes sense as a problem case?
I can understand the use case, but that shouldn't be the case, normally when someone initiates a transaction the amount should be locked for a certain period of time
so basically if they start the transaction at 10:58, your logic should be to give them a window of x time to pay that amount
it's some sort of a guarantee
that has nothing to do with Stripe, it's just a common practice
and the reason for that, is to avoid possible disputes
disputes are way worse then not updating the price I guess
lean canyon
We have this working with an older implementation of Stripe fyi, we're just trying to migrate to the newer payment elements and using the docs.
hollow ledge
I agree, I'm not saying it's not possible
lean canyon
Gotcha that makes sense! For a bit of context that's not something we're currently doing and we're just trying to migrate to the newer patterns rather than rewrite above our payment layer atm
hollow ledge
I'm just trying to cover the basic ground here and making sure you know the pros and cons before diving deeper into how to implement if you still wish to do so
lean canyon
So given the scope of the work we've been assigned I think we're good to proceed with this approach for the time being, that said I'll raise the points mentioned!
hollow ledge
in that case I think the best thing to do is to use the deferred flow
lean canyon
Okay sure let me take a peek at that
hollow ledge
with a createPaymentMethod flow first https://stripe.com/docs/js/payment_methods/create_payment_method_elements
lean canyon
Okay interesting! Let me take this one away and I'll open up a new thread as required
really appreciate the help and direction
hollow ledge
you don't to create a new thread if this one is still open
but yeah if you're coming way later then yes feel free to send a new message. on the main channel
lean canyon
Yeah sure but I suspect it'll be a bit of time inbetween as I'll nee to liaise with the business etc. ha!