#rpoulose - radar and setup
1 messages ยท Page 1 of 1 (latest)
Hello! Just starting a thread for you -- I'll review and respond as soon as I can ๐
Thank you
First, i want to confirm you enabled Radar for setup intents in your settings
We have Radar enabled for our account. Is there a separate setting to enable it for SetupIntents?
Aha. Thank you for that. If I enable it in 'Test' mode of our account, will we be charged?
I mean if we will be charged in test mode, I'll need to get approvals before enabling it
Q1/ I don't think this is quite what you want, since this will be checking the result of an address check after the auth, rather than before. Instead, I think you'd need to determine when you have a billing postal code or not, and manually request 3DS when you want it:
https://stripe.com/docs/payments/3d-secure#manual-three-ds
On Q2/ correct, 3DS is only ever requested and only "works" if supported by the card.
You can separately use radar to check if 3ds auth was completed using the is_3d_secure_authenticated rule
https://stripe.com/docs/radar/rules/reference
Not the logic about authenticated/support described here:
https://stripe.com/docs/radar/rules#request-3d-secure
Nope, only in live mode
Q1 - Our flow is that our back-end creates a SetupIntent and the front-end confirms the SetupIntent. The postal code is provided only from the front-end and the issue that we are having is that due to a bug in the Stripe library the postal code set in the front-end was not being passed to Stripe. We are fixing that issue in the next release of our front-end. The challenge we have is that not all of our customers will update the front-end (app) and hence these customers will continue to send an empty postal code. If we want to manually request a 3DS if the postal code is empty, then we'll need to update the front end (app) to do this conditional check but will still not fix the issue for customers who do not update the app. So I think it looks like it is not an option for us to request 3DS conditionally for postal code empty cases
Yes, that's true, you may need to force an update on those customers then
You could add rules to block the charges if there is no postal code check and the card supports 3ds but it wasnt completed, if you want to do that
That rule might be too restrictive because there are some customers who entered the postal code but the postal code did not make it to Stripe because of the library issue I mentioned and since we weren't forcing 3DS, 3DS wouldn't have been completed. If we block these customer's charges, they'll not be happy
In that case you can use review rules to allow your staff to manually review and contact the customer if needed
(review rather than block)
I think the only option is to put a radar rule to force 3DS on all SetupItent (irrespective of postal code). Would you know if a majority of cards in the US support 3DS?
I don't know how common this is currently, no
ok, and just to confirm, you said that if we enable 'Radar rules for SetupIntent; in TEST mode, we will not be charged, right? Wanted to be sure I understood that correctly before I enable it ๐
Correct, there are no fees for test mode
Thank you for your help
NP!