#brandan_unexpected
molten mossBOT
👋 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/1447700515650535454
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
robust veldt
Oh if you're trying to turn off 3ds you can't
That's something banks request from the customer
Is the goal to simply decline a payment if the bank requires 3ds?
Rather than put it in incomplete?
bitter drift
Yes, the goal right now until we have our 3DS flow built out is to decline cards requiring 3DS until we support it. Is that something possible to do via the dashboard?
We have a way of doing it manually server side if the payment requires 3DS we were going to cancel the payment intent so that it wasn't stuck in 'incomplete'. But if there is a way via the dashboard to just flat out decline payment if the bank requires 3DS that would mean less work for us to do in the interim until we finish our 3DS support feature.
I have chatted quite a bit with Stripe devs on this but no one has ever mentioned you could flat out decline 3DS cards in Stripe Dashboard so never though that was possible, is that an option?
robust veldt
You might be able to write a radar rule to do this but not sure
Also are these payments where the customer is on-session?
bitter drift
some are and some aren't on session. Currently in production we have no 3DS logic. We are in the middle of building out things to align with Stripes 3DS recommendations of using the off session flags and setting thigns up for future usage.
So for now the 1 question is:
Can you block 3DS cards to decline them rather than be stuck in an incomplete status via the dashboard/radar rules.
The goal is to mitigate getting payments stuck in an incomplete state until our 3DS flow goes live. ie decline 3DS cards and don't allow them. As I mentioned we have a way of doing it manually using the api by checking if it required action, if so cancel the payment intent and we return a internal declined message to the user and ask them to use a different card. We just want to know if it can be done via the dashboard or radar rules because to us it seemed like we already had that rule but it didn't do anything
robust veldt
Ok so to be clear:
That radar rule, when enabled, would request that a bank attempt 3ds if it's supported for the card. Disabling it just defers to the bank when 3ds should be requested.
I'm not an expert on crafting radar rules, but I think you should be able to write one to block charges that require 3ds
Like I think Block if :is_3d_secure: might work
molten mossBOT
bitter drift
hm I am not sure that one would work for the case we are needing. That would work if the charge did use 3d secure, no?
Because a lot of cards have the "request_three_d_secure": "automatic" it seems challenging to figure out how to use a radar rule to block it
robust veldt
Yeah I'm not sure. We're not really experts on crafting radar rules in here. Off session transactions by default are declined when 3ds is required (if you pass off_session=true). The tricky thing is your on-session charges when your customer is confirming client-side. You could move to a server-side confirmation flow and just always pass off_session=true: https://docs.stripe.com/payments/finalize-payments-on-the-server
bitter drift
Right that is what I am thinking too. Based on what I have read online it seems like doing this check on our backend to just see if the status is requires_action and if so, then cancel it and return a custom error to our user?
A radar rule seems like it wouldn't really suffice for what we are attempting to do by blocking any card that required 3DS, we really have to attempt to capture check if it needs 3DS and if so, cancel it/bubble up an error. That is until we have 3DS supported.
robust veldt
If you do what i suggested ^ (ie. always pass off_session=true on confirmation) the PI will never transition to requires_action
But your approach is fine as well
Up to you
bitter drift
So off_sesion always being true when requiring 3DS will result in a declined payment vs requires_action?
slender hare
👋 Hi Codename_duchess had to head out, i'll be taking over the thread. And that is correct