#uhoh-3ds-returnurl
1 messages · Page 1 of 1 (latest)
uhoh-3ds-returnurl
What integration path are you using? Are you on PaymentElement?
@glacial shadow are you still around?
Hi yes!
No, I'm creating a payment intent on my server and confirming it right away with confirm=true
sure but you can't do 3DS server-side. So how exactly are you handling 3DS?
The payment intent has requires_action
and so I send that to the client which goes through the 3DS authentication in an iframe
Is there a way to avoid providing a return_url?
Because I want the client to just go through the 3DS authentication through the iframe, and have it close
Why wouldn't you want to tell you user "yes your transaction succeeded"?
I don't think the flow you're asking is possible today at least
Stripe.js requires the return_url because some payment methods will require a full-page redirect. card 3DS generally run in an Modal, and will simply dismiss the modal on completion (or failure), ignoring the return_url
I do this currently, using the secret from the paymentIntent in "requires_action" status
sure but when you use Stripe.js for this you get a callback completing that tells you about the success. But they just said you don't do that and just hadnle 3DS themselves (which really, in my opinion, is a huge mistake) :p
Yeah, the extremely comprehension services in Stripe JS are very very useful (and secure)
Because my customer is on a payment page and I would like simply close the iframe modal and go back to that payment page
But if I provide a return_url, wouldn't the modal be redirected to that url?
The return_url is sort of a "general" feature - as I mentioned some payment methods aren't run in a modal. But card authentication is in a Modal, and the return_url is just redundant fluff
Not really. If you use PaymentElement, which you should, even card payments will redirect after success (unless you explicitly disable it)
I'd have to go back and check - but I'm pretty sure I do just that - disable it
"redirect if required" as I remember
yeah but you're answering another developer that might not know anything about it 🙂
I'd post snippets - but my dev environment just crashed hard. Whee!
This is the flow I implemented:
-
The client sends the payment method ID to the server
-
The server calculates some prices with some information received, and creates a payment intent and confirms it immediately with
confirm=true. It checks if the payment intent object hasrequires_action.redirect_to_url. If it has, then it needs 3DS, so it returns theurlandreturn_urlto the client. -
The client receives the
urlandreturn_url. It opens theurlin a modal and goes through the 3DS authentication. -
I would like, at this step, that the modal simply closes, without any url redirection.
Sorry if it's unclear, I tried to keep it concise
@glacial shadow yeah the problem is that you're basically side-stepping the default integration path we've had for years now and still doing the whole "collect payment method details, go to a server, oh-no I need to go back to the client"
I think you want to look at that beta we have: https://stripe.com/docs/payments/defer-intent-creation
But as far as I know you can't avoid that return url today sorry (unless you use that beta)
I can't collect the payment method and create the payment intent on the client side because I need to do calculations on the server, and I can't make two separate api requests
hence the beta I showed you
like your flow is fine for card. but you can't use the majority of other payment methods. And you might not care today, but in the future, you will be frustrated to have to rewrite your entire integration
It's still in beta though :/
yeah but it's going to be the default for everyone in the near future