#obo-3ds-testing
lofty mesaBOT
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.
mellow vortex
yes indeed, confirmed in the popup on our test website
desert flint
I'm sorry, you're giving really little information here 😦
3DS is required for every payment on that card
mellow vortex
Happy to provide as much as I can! sorry about that
desert flint
Looking at that PaymentIntent it seems you're using a Subscription maybe and doing something complex but no 3DS anywhere. I assume you use SetupIntent earlier but shared the wrong id maybe?
mellow vortex
I don't think so. Here's my flow:
- have user enter in card via stripe elements
- this gets sent to our API which creates a Setup Intent for off-session use
- confirm 3ds modal that pops up
- attempt to upgrade them to the plan they selected
- keep card on file for future off session payments as this is a recurring subscription
The user I provided, attempted to use a 3ds card, which I confirmed in the modal that popped up from stripe elements, then I attempted to upgrade
desert flint
That card will require 3DS for every single payment forever
that's the part you don't understand I think.
mellow vortex
hmm, possibly not, is that the difference between 3ds and 3ds 2?
desert flint
no that has nothing to do with 3DS vs 3DS2
it's just the way that really old test card is configure. That's why it's under a sub-heading that isn't in the table of contents. It works and is an easy way to always make our API require 3DS no matter what. But it's the wrong card to test with if you're trying to do 3DS set up for future off session payments. You want 4000002500003155 instead that is in the above section
mellow vortex
ahh, I see
my apologies, thank you for the reference pointer
in the test case above, is there a way for me to test "authorizing" for off-session payments for that type of card?
or will that basically always fail
desert flint
I don't understand the question the way it's worded I'm sorry
Are you asking how to collect card details now, do 3DS and then later simulate an off session payment?
mellow vortex
yes
desert flint
gotcha then that's what I explained above right?
it's exactly what you do, you are just using the wrong test card
mellow vortex
Yes sorry, so even if I use: 4000002760003184 for example
which requires authentication on all transactions like you said
I'm asking if stripe provides a way for me to simulate "authentication for an off session payment"
so the setup intent is already there, the card has been confirmed on session (with stripe elements), but then an off session charge is attempted
as I would be off-session, I wouldn't expect a popup to appear on the front-end simulating the authorization flow
desert flint
I'm really sorry I don't get it at all
if a payment is off session, there's no customer around, they are not on your website, they don't see Elements. All you do is confirm the PaymentIntent server-side with an already saved/attached card PaymentMethod + off_session: true right?
mellow vortex
that's my understanding yes
desert flint
okay so why are you explicitly using the test cards that requires 3DS on all transasctions again?
like you want the first one, the one I explicitly called out right?
mellow vortex
I think I may be misunderstanding, but am starting to understand. Let me summarize what I think you're saying
For the cards I have been using, they simply do not work with off-session payments at all, and that's also how they would behave in the real world?
I think my previous understanding was that these types of card would require an initial on-session authorization, and then for off-session payments these specific card types would get some sort of push notification / text from their bank when the off-session charge was about to go through
it sounds like my previous understanding is not how this works in the real world?
desert flint
no you're still misunderstanding
mellow vortex
sorry :/ really trying here, I appreciate your patience
desert flint
Those cards do not model the real world. They are here to make it easy to test 3DS being required.
The real world is drastically more complex than this. You do 3DS on auth, then you do off session payments, and the first one works, and the second one works and the seventeenth one might not work and require 3DS and then you get the customer back on your app/website and get them to do 3DS again and then the 18th also works, etc. etc.
It's super complex, up to each individual banks, there's never any guarantee that you have made 3DS in January 2023 and the card will now forever and ever work 🙂
So we have test cards that simulate the natural behaviour: do 3DS on session, future off session payments just work. Which mirrors most of the real world.
And then we have test cards that just always requires 3DS on or off session, which allows you to simulate "okay what happens if the bank in the future rejects my attempt and asks for 3DS"
desert flint
Sure thing! You're not the only person confused to be clear. Everyone just wants a test card that models the real world. But there's no such thing, since the real world is full of edge-cases 😦
mellow vortex
That seems to be the case, I really do appreciate this explanation.
One last question if you don't mind, since I'm not sure I can test this properly in a testing environment.
If I have a card that needs authorization on every single charge (in the real world), and set it up for off-session payments, what happens if:
- they attempt to upgrade their subscription, it fails because our API assumes it will work off-session
Do they go back and authorize the payment and then try again? or do we need to build something into our flow that basically waits for them to accept the payment?
desert flint
You try to charge their card, the bank asks for an approval and it timeouts and says no. you email them, get them on session, attempt to pay again and approve the transaction
mellow vortex
Hmm okay, I think I may have some more questions, but want to do some further reading as hopefully it's in the documentation. Thanks for your time today