#zach-3ds-support

1 messages · Page 1 of 1 (latest)

static stratus
#

Hey @ocean kiln

#

depends a lot on your integration

#

Can you give me an example charge id? I can try and check

ocean kiln
#

Sorry, discord n00b here. pasting my other contextual message in this thread

I'm pretty sure that our current implementation relies on the Stripe Charges API, and therefore does not support 3DS, however I'm not certain as the backend stripe calls are somewhat abstracted by our recurring billing system.

#

Let me see if I can get a charge id for you

#

I personally do not have access to the stripe dashboard, but would this gateway transaction id from our billing system test environment perhaps be what you're looking for? ch_3LZSPpAdMP81f8ce0XrLYqSo

static stratus
#

yep

#

Okay so you use a third-party Connect platform and it's well know and they use the PaymentIntents API so I would say they support 3D Secure already

#

would be easiest to just ask their support team though 🙂

ocean kiln
#

So yeah this is what the Stripe account manager said

static stratus
#

Looking at other logs... yeah maybe not

ocean kiln
#

I'm not quite convinced

#

yeah

static stratus
#

They seem to use a pretty legacy integration via our old Tokens API

#

and they attached the card to a Customer first

#

and that will fail if 3DS is needed

ocean kiln
#

right gotcha

#

confirms what I suspected

static stratus
#

But it's possible they handle that failure and recover from it

#

there are many ways to integrate

#

ah yeah they do

ocean kiln
#

I know that they do have 3DS support, but our implementation doesn't seem to be consistent with their tutorials

static stratus
#

I see other requests where they use the SetupIntents API

ocean kiln
#

righto

static stratus
#

So I do see cases in your account where they did do 3DS

ocean kiln
#

oh awesome

static stratus
#

hum maybe not

#

sorry this is so hard to debug 😅

#

I see them trying and not doing it

ocean kiln
#

lmfaoo algoods

static stratus
#

Ugh that's weird, they are quite big

ocean kiln
#

and same, very confuzzled

static stratus
#

but maybe it's because your account isn't in Europe where it's required

ocean kiln
#

I think it's just our implementation

#

1 sec

#

Would it not be required if we're serving customers in Europe (or India)

#

So our flow is basically just generating a token and sending it to chargebee, rather than doing all this back and forth with payment intents

static stratus
#

India would make it required

#

European banks are not supposed to require 3DS for non European businesses

#

"supposed" being the operative word

#

US banks have started requiring 3DS too in some cases

ocean kiln
#

yeah so they can require the challenge regardless technically speaking

static stratus
#

So yeah you definitely should be doing the PaymentIntent flow

ocean kiln
#

I'm trying to build a case for this refactor to be prioritised, would you have any potential ballpark figure for potential impacts? What proportion of banks in various regions would be likely to be enforcing this? Is there a way I can figure this out?

#

Oooorrr, is this more of a chargebee conversation?

static stratus
#

honestly I can't tell you

#

If I were you I'd focus less on 3DS and more on new payment methods

#

Once you're on PaymentIntent, and assuming Chargebee supports our new PaymentElement (no idea if they do) then you can easily accept a lot more payment methods and increase conversions, lower overall fees, etc.

#

I don't know enough about what Chargebee supports though

ocean kiln
#

So by moving to payment intents, we'll get 3DS sorted and additionally we'll get access to a whole bunch of payment methods that stripe supports that are more region specific and will potentially circumvent 3DS?

#

I have a feeling chargebee does support the payment element

#

Another question, with 3DS1 being sunsetted in October and getting replaced with 3DS2, will 3DS support become more important for us to have?

static stratus
#

yes to the first part

#

no to the latter, I would say, you don't seem to support 3DS1 so it doesn't really change much

#

but over time more and more banks will need 3DS so it's important to migrate (but as a non European business it's not that crucial)

ocean kiln
#

Sorry for the delay, had a bunch of meetings.

#

So I follow your reasoning being a non european business, but if we operate in India surely it becomes crucial for us to support 3DS if we care about that market?

tired robin
ocean kiln
#

Awesome, thanks for jumping in

#

So bringing it back to my initial question, obviously I can also talk to my recurring billing platform support team to confirm this but would I also be able to get an understanding of the application behaviour when 3DS is required by a bank by using this 3DS Required: OK card (listed here https://stripe.com/docs/testing#three-ds-cards) in our non-prod environment?

Testing

Simulate payments to test your integration.

tired robin
#

Yes, in test environment, you'd be able to use those test card number to 'mimic' the 3DS behavior

ocean kiln
#

Awesome, I'll be able to use that information to measure current impacts then