#Merp-radar-rules
atomic shore
Hi there 👋 interesting question! I'm not certain off the top of my head, so please bear with me a moment while I look for clarification.
bleak nest
The reason I ask is because we were informed by Stripe that we have excessive 402 errors from card testers. The setup_intent is already behind a reCAPTCHA v2 token verification, so, I'm trying to add a rate limit solution, as well, per your suggestions here: https://stripe.com/docs/card-testing
atomic shore
Gotcha, and thank you for your patience while I dug into this. The first thing to confirm is if you've enabled Radar for Setup Intents. You can check this here:
https://dashboard.stripe.com/settings/radar
bleak nest
Yes
atomic shore
Thank you again for your patience while I confirmed with my teammates! Since that setting is enabled, then your rules will apply to setup intents as well. You'll still want to use the blocked_charges_per_ip_address_XXXattributes, as they'll hook onto the authentication charges associated with setup intents.
bleak nest
Cool, thanks for the clarification. One follow up question...
atomic shore
Sure
bleak nest
Since the setup_intents are being performed server-side, the IP associated with all the setup_intent calls is the IP of the server. Is this going to be an issue for a per_ip rate limit?
atomic shore
Just to make sure I understand, are you referring to confirming the Setup Intents server-side? Or something else?
bleak nest
its being created and confirmed with a single call containing the customer ID, payment method and confirm:true flag.
atomic shore
Gotcha, I think those will be treated as coming from the IP of your server. You should be able to test that in test-mode by creating a rule based on the ip_address attribute, and set that IP to your server's address, and then walk through your flow to see if the rule blocks it.
bleak nest
So, if i want to use the "blocked_charges_per_ip_address" rule, I would need to create the setup_intent on the client-side with Stripe.js?
atomic shore
Not created by Stripe.js, but I think it needs to be confirmed by it:
https://stripe.com/docs/js/setup_intents/confirm_setup
bleak nest
Right, its created by the element
atomic shore
Not quite, the Intent is still created server-side, but then its client secret is passed to Stripe.js and the Elements collect the payment details, then Stripe.js is used to confirm the Setup Intent.
bleak nest
Right... so, if the confirmation is being performed client-side, is there some way I can still protect it with reCAPTCHA?
bleak nest
Google reCAPTCHA
Stripe has a captcha?
Oh, I assume you are referring to captcha protection in Stripe Checkout.
We are just using the Stripe payment element with our own reCAPTCHA
Currently, the payment method spit out by the element is being passed to the server via AJAX with a reCAPTCHA token. The PM is not attached to a setup_intent nor confirmed unless the reCAPTCHA token is valid.
If the confirm is happening client-side, I don't really see a way to protect it with a captcha.
limpid pecan
can you confirm the CAPTCHA server-side first, then confirm client-side?
bleak nest
I'm not how I would do that in a secure way that cant be defeated. Any suggestions?
limpid pecan
I'm not sure but it depends on what you're trying to solve against
you could have a captcha before you bring a user to CardELement (and beforte you create SetupIntent)