#nerder
1 messages · Page 1 of 1 (latest)
API-wise there isn't a difference as far as I am aware, unless you are using a legacy API as I think one of them only supports v1. As long as you are using Payment Intents or one of our APIs that use them, we will display the correct 3DS to your users when needed
when you say legacy API you have an approximate version?
consider that we are using https://github.com/stripe/stripe-ios and https://github.com/stripe/stripe-android under the hood when using https://github.com/flutter-stripe/flutter_stripe
and we are not currently on the latest
also, when how we debug this kind of issues when they happen?
By legacy I mean like Sources API vs PaymentMethods API, API Version won't affect this
Can you tell me what your payment flow looks like here from an API perspective (like what API calls are you making?)
I think stripe-ios and stripe-android only support APIs that support v2 but will double check.
from the frontend i'm think we are using payment_intent
this kind of issues are quite painful because there is no much to debug from ourside
but we need to deal with the "blame" in a sense
i also guess that indirectly this happens to you when the issue is on the bank side
Gotcha, it also looks like I was misremembering and we just generally support 3DSv2 across any of our APIs that support 3DS. So you don't need to make any special considerations between 3DS v1 and v2, you just tell Stripe to display 3DS and we handle it from there. Basically, we try 3DS2 and if the bank doesn't support it we fall back to 3DS v1
ok thats good to know