Add support for off_session 3D Secure #240
Conversation
b242aa5 to
25b300e
Compare
|
BTW in a separate thread I started working on a minimal web page form as a GET for I actually don't rely on there being such a page because I'm just testing a backend, and am happy to just have my test harness poke the Let me know if that sounds either horrible (in which case I shall stop building it), useful, or a blocking requirement this PR. :) |
|
Once again, the code looks good and documented 👍 It's interesting because we already use localstripe for 3D Secure payments in off_session mode, by pre-configuring them with setup intents beforehand. So it's supposed to be working already on master branch (al least for our particular use case :))
It looks like a good idea! But it might be redundant with localstripe.js's |
7570a14 to
64fcf73
Compare
Thanks, and thanks for all your work with localstripe! It's super useful for us, and fun to work with as well!
Yeah good point, I clarified this in the commit message better just now. What this special test card does is stop requiring authentication when we confirm a PaymentIntent, if the card was set up for off-session payments and the payment is off-session. This seems to be a realistic behavior (as we at Via are confirming live in production for the last couple weeks!) For context if it's interesting: At Via we are running transit systems, like this one in Avignon... usually the riders of our services pay using a service like Stripe on our app... and usually the rider is off-session when the payment happens—usually but not always their phone is in their pocket or purse because they're stepping out of a van when payment actually happens! So we need to simulate the realistic 3D Secure behavior: small off-session payments are less likely to trigger 3D Secure challenges if the card was set up for it, because Stripe is able to request an exemption. That's what this test card simulates for us.
... okay still looking at this! |
Oh I see... what Let me make an analogy here:
So this addition is indeed redundant. I will provide two not-very-complicated paths forward! Plan AEh, as a matter of taste, it might be a good idea to avoid intermingling item #1 ("The "front door" for starting a SetupIntent confirmation") with item #3 (The "back door" for authenticating a SetupIntent). To do that, what I would do is modify localstripe-v3.js (in this PR) to switch to my new endpoint for the authenticate step. I don't know if that accomplishes much, just, maybe, provides future simplification of My only hesitation is that I don't have a test setup for Plan BI shall delete my new redundant UPDATE 2024-11-09TL;DR I modified this PR to follow plan A above: I made On the topic of "is it a useful idea to make a web page for authentication"... TL;DR probably not? Idunno. I recall now the other wrinkle I have; I am working on adding PayPal support. It doesn't take much... to be a useful simulation, PayPal basically just requires:
When you confirm a SetupIntent on PayPal, the Stripe (test) API seems to always return a SetupIntent response like this: Probably Let me know what you think! |
I'm adding this as a way of testing adrienverge#240 but also because it seems generally useful as documentation.
I wanted to add an example of using localstripe-v3.js, as a way of testing adrienverge#240 and also because it seems generally useful as documentation. Along the way I discovered confirmCardPayment isn't quite right; it skips /confirm and goes right to /_authenticate. This fails on cards that don't require 3D Secure authentication because the /_authenticate endpoint is confused about why it's being called at all. I fixed this, modeled on how confirmCardSetup works. This in turn required a small fix to the localstripe backend to allow calls to /confirm from the browser (i.e., with a client_secret and key as form data).
I wanted to add an example of using localstripe-v3.js, as a way of testing adrienverge#240 and also because it seems generally useful as documentation. Along the way I discovered confirmCardPayment isn't quite right; it skips /confirm and goes right to /_authenticate. This fails on cards that don't require 3D Secure authentication because the /_authenticate endpoint is confused about why it's being called at all. I fixed this, modeled on how confirmCardSetup works. This in turn required a small fix to the localstripe backend to allow calls to /confirm from the browser (i.e., with a client_secret and key as form data).
I wanted to add an example of using localstripe-v3.js, as a way of testing adrienverge#240 and also because it seems generally useful as documentation. Along the way I discovered confirmCardPayment isn't quite right; it skips /confirm and goes right to /_authenticate. This fails on cards that don't require 3D Secure authentication because the /_authenticate endpoint is confused about why it's being called at all. I fixed this, modeled on how confirmCardSetup works. This in turn required a small fix to the localstripe backend to allow calls to /confirm from the browser (i.e., with a client_secret and key as form data).
I wanted to add an example of using localstripe-v3.js, as a way of testing adrienverge#240 and also because it seems generally useful as documentation. The example includes a --real-stripe argument so you can compare the real (test) Stripe API and Stripe.js against localstripe. Along the way I discovered confirmCardPayment isn't quite right; it skips /confirm and goes right to /_authenticate. This fails on cards that don't require 3D Secure authentication because the /_authenticate endpoint is confused about why it's being called at all. I fixed this, modeled on how confirmCardSetup works. This in turn required a small fix to the localstripe backend to allow calls to /confirm from the browser (i.e., with a client_secret and key as form data).
I wanted to add an example of using localstripe-v3.js, as a way of testing adrienverge#240 and also because it seems generally useful as documentation. The example includes a --real-stripe argument so you can quickly compare the real (test) Stripe API and Stripe.js against localstripe. Along the way I discovered confirmCardPayment isn't quite right; it skips /confirm and goes right to /_authenticate. This fails on cards that don't require 3D Secure authentication because the /_authenticate endpoint is confused about why it's being called at all. I fixed this, modeled on how confirmCardSetup works. This in turn required a small fix to the localstripe backend to allow calls to /confirm from the browser (i.e., with a client_secret and key as form data).
I wanted to add an example of using localstripe-v3.js, as a way of testing adrienverge#240 and also because it seems generally useful as documentation. The example includes a --real-stripe argument so you can quickly compare the real (test) Stripe API and Stripe.js against localstripe. Along the way I discovered confirmCardPayment isn't quite right; it skips /confirm and goes right to /_authenticate. This fails on cards that don't require 3D Secure authentication because the /_authenticate endpoint is confused about why it's being called at all. I fixed this, modeled on how confirmCardSetup works. This in turn required a small fix to the localstripe backend to allow calls to /confirm from the browser (i.e., with a client_secret and key as form data).
I wanted to add an example of using localstripe-v3.js, as a way of testing adrienverge#240 and also because it seems generally useful as documentation. The example includes a --real-stripe argument so you can quickly compare the real (test) Stripe API and Stripe.js against localstripe. Along the way I discovered confirmCardPayment isn't quite right; it skips /confirm and goes right to /_authenticate. This fails on cards that don't require 3D Secure authentication because the /_authenticate endpoint is confused about why it's being called at all. I fixed this, modeled on how confirmCardSetup works. This in turn required a small fix to the localstripe backend to allow calls to /confirm from the browser (i.e., with a client_secret and key as form data).
I wanted to add an example of using localstripe-v3.js, as a way of testing adrienverge#240 and also because it seems generally useful as documentation. The example includes a --real-stripe argument so you can quickly compare the real (test) Stripe API and Stripe.js against localstripe. Along the way I discovered confirmCardPayment isn't quite right; it skips /confirm and goes right to /_authenticate. This fails on cards that don't require 3D Secure authentication because the /_authenticate endpoint is confused about why it's being called at all. I fixed this, modeled on how confirmCardSetup works. This in turn required a small fix to the localstripe backend to allow calls to /confirm from the browser (i.e., with a client_secret and key as form data).
I wanted to add an example of using localstripe-v3.js, as a way of testing adrienverge#240 and also because it seems generally useful as documentation. The example includes a --real-stripe argument so you can quickly compare the real (test) Stripe API and Stripe.js against localstripe. Along the way I discovered confirmCardPayment isn't quite right; it skips /confirm and goes right to /_authenticate. This fails on cards that don't require 3D Secure authentication because the /_authenticate endpoint is confused about why it's being called at all. I fixed this, modeled on how confirmCardSetup works. This in turn required a small fix to the localstripe backend to allow calls to /confirm from the browser (i.e., with a client_secret and key as form data).
I wanted to add an example of using localstripe-v3.js, as a way of testing adrienverge#240 and also because it seems generally useful as documentation. The example includes a --real-stripe argument so you can quickly compare the real (test) Stripe API and Stripe.js against localstripe. Along the way I discovered confirmCardPayment isn't quite right; it skips /confirm and goes right to /_authenticate. This fails on cards that don't require 3D Secure authentication because the /_authenticate endpoint is confused about why it's being called at all. I fixed this, modeled on how confirmCardSetup works. This in turn required a small fix to the localstripe backend to allow calls to /confirm from the browser (i.e., with a client_secret and key as form data).
I wanted to add an example of using localstripe-v3.js, as a way of testing adrienverge#240 and also because it seems generally useful as documentation. The example includes a --real-stripe argument so you can quickly compare the real (test) Stripe API and Stripe.js against localstripe. Along the way I discovered confirmCardPayment isn't quite right; it skips /confirm and goes right to /_authenticate. This fails on cards that don't require 3D Secure authentication because the /_authenticate endpoint is confused about why it's being called at all. I fixed this, modeled on how confirmCardSetup works. This in turn required a small fix to the localstripe backend to allow calls to /confirm from the browser (i.e., with a client_secret and key as form data).
This adds a simulation of a canonical Stripe test card that supports 3D Secure in off_session mode, if the configured properly with a setup_intent beforehand. This card stops requesting 3DS authentication at payment time if it was set up for off-session payments. This commit includes addition of a test-only _authenticate endpoint for setup_intents similar to the one that already exists for payment_intents. (Tests can POST to the _authenticate endpoint to simulate asynchronous interaction by the cardholder with 3D Secure challenges.)
This adds a simulation of a canonical Stripe test card that supports 3D Secure in off_session mode, if the configured properly with a setup_intent beforehand. This card stops requesting 3DS authentication at payment time if it was set up for off-session payments.
This commit includes addition of a test-only _authenticate endpoint for setup_intents similar to the one that already exists for payment_intents. (Tests can POST to the _authenticate endpoint to simulate asynchronous interaction by the cardholder with 3D Secure challenges.)