#aj_3ds-cloned-payment-methods

1 messages · Page 1 of 1 (latest)

brazen micaBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1347242417975201853

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

inland veldt
#

Hello there

#

That looks like it was a normal decline from the issuer

#

That said, you shouldn't be using a SetupIntent and then creating a Subscription immediately afterwards.

somber peak
#

we create the actual token in our platform account and then clone it to our connect account. First step is a charge and then when a customer accepts to subscribe we attach the payment method and then create setup intent

inland veldt
#

You should just use the Subscription's PaymentIntent or SetupIntent here to collect the PaymentMethod

#

Ah

#

You are cloning

somber peak
#

yes we do paymwent intent

inland veldt
#

Okay that makes more sense.

#

Well, this was just a standard do_not_honor decline from the issuer in this case.

somber peak
#

its just that the charge goes through and then when they accept a subscription, it fails with additional auth needed

#

how about this one - evt_1QzCIVFXh1jGzFlZhi31GQ2J

#

should we create a radar rule to help with this case wherein we force users to go through the 3DS option before creating the first charge?

inland veldt
#

You can do that, yes. The reality is that the issuer can request 3DS go be completed on any authorization.

#

So they might not care about it for the first auth (the SetupIntent) but then they do for the Charge for the Subscription.

#

The second example you shared looks like a normal SetupIntent failed 3DS example

somber peak
#

we have been seeing increased failures as we are moving some of the european payments from our platform to our connect account. can this (move to connect account) be a reason as well?

inland veldt
#

What country is your platform in?

#

Ah

#

Your platform is US

#

And you aren't setting on_behalf_of here, correct?

brazen micaBOT
somber peak
#

no I dont think we are setting on_behalf_of anywhere. where should we be setting it?

drifting urchin
#

Hi 👋

I'm stepping in as my colleague needs to go. I think what my colleague was getting at was to understand clearly who the merchant of record for these transactions are.

somber peak
#

both the platform and connect account belong to us. we created the connect account n Europe to save on soem transaction/interchange fees

drifting urchin
#

Looking at the Setup Intent creation request, it looks like you are passing the the Stripe Account header on the request. This means the UK connected account is the merchant of record

somber peak
#

yes but the tokenization happens in the platform account which then gets clone to connect

drifting urchin
#

But that would not prevent the issuing bank from requesting 3DS for a charge made on the Connected Account

somber peak
#

because of our workflow, we do not currently have an easy way to redirect users for 3DS auth during the subscription but we could possibly do it during teh first charge creation step

#

my worry is tanking conversions by making all European card users to go through 3DS

#

we still see succesful subscriptions being created with teh current workflow and hence the worry about tackling this new issue

drifting urchin
#

So the cards get tokenized on your platform and do not require 3DS. But, when creating the Subscription on the Connected Account, 3DS is being triggered?

somber peak
#

yes

#

and its trigerred only for subscription creation

#

not for the first charge

#

we create a standalone charge first and then create a membership (based on user's consent)

drifting urchin
#

Do the first charge and subscription creation occur on separate accounts?

somber peak
#

nope same account

drifting urchin
#

And the stand-alone charge, is that using a Payment Intent and are the customers on-session at that time?

#

If that is the case, it might make sense to request 3DS for the one-time charge. It's not a guarantee (since issuers can request 3DS whenever they want), but it could reduce the frequency of 3DS requirements when creating the Subscription.

You can include a parameter to request 3DS when creating a Payment Intent here

somber peak
#

can we do this via Radar instead since it would make it easy to toggle on or off?

drifting urchin
#

You could try starting with the lower friction Request 3D Secure if 3D Secure is recommended for card and ramp up to the higher frequency Request 3D Secure if 3D Secure is supported for card rule if you were still getting too many 3DS requests during Subscription creation.

somber peak
#

ok I'll try that but just out of curiosity, this error has increased in occurrence ever since we moved some payments to connect account. does moving to a connect account have a connection here?

drifting urchin
#

Are all your connected accounts based in Europe/Great Britain?

somber peak
#

nope we have one for Brazil, one for Europe (which is technically GB) and one for India (unused for now)

drifting urchin
#

All of thos regions have unique banking regulations, especially India. But the end result is that 3DS is more likely to occur when transacting in those countries.

somber peak
#

ok thanks so much...I'll consult with our team and turn on 3DS and experiment with some countries to start with

drifting urchin
#

Happy to help! I hope the use of 3DS rules alleviates the issue for you.