Appearance
Stripe Radar Rules
We have configured a range of Stripe Radar rules to prevent fraud on our Payment Gateway. These rules should be maintained since they may - inadvertently - negatively influence our success rates if we do not check them every once in a while.
Our current rules
In the Stripe Dashboard we can activate/disable existing radar rules, add new ones and review the effected transaction in some cases.
First, when should a payment be sent through 3D Secure?
3D Secure authentication will be requested for matching payments using Checkout, Stripe Billing, or the Payment Intents or Setup Intents APIs.
[Active] Request 3D Secure if 3D Secure is required for card
Payments will request 3D Secure authentication if the card requires it. This rule will not apply to authenticated payments created by Apple Pay or Android Pay.[Disabled] Request 3D Secure if 3D Secure is supported for card
Payments will request 3D Secure authentication if the card supports 3DS authentication with minimal conversion lost. We don't enforce it to avoid any drop in conversions.[Disabled] Request 3D Secure if 3D Secure is recommended for card
Payments will request 3D Secure authentication if the card supports 3DS authentication regardless the potential conversion drop. We don't enforce it to avoid any drop in conversions[Active] Request 3D Secure
if :card_3d_secure_support: in ('required', 'recommended', 'optional') and :risk_score: > 50
For transactions with a high risk score above 50 we enforce the 3DS authentication if possible.
Review Effected Transactions
Then, when should a payment be allowed?
These payments will not be assessed by block or review rules.
- [Disabled] Allow if payment matches one or more values in default Stripe allow lists
For security concerns are we not allowing any transaction to bypass all block or review rules even if they match a configured element in a Allow List. This way we avoid some human errors through configuration mistakes. - [Active] Allow if payment is not high risk, is authenticated with 3D Secure and has a liability shift
Payments that don't have a high risk level, are authenticated with 3D Secure and protected from fraudulent disputes will always be allowed
Review Effected Transactions
Then, when should a payment be blocked?
These payments will not be assessed by review rules.
[Active] Block if payment has a risk score of 75 or higher
Stripe's machine learning algorithm automatically evaluate the risk level of card payments. Stripe blocks all payments with a high risk score of 75 or more
Review Effected Transactions[Active] Block if payment matches one or more values in default Stripe block lists
A payment will be blocked if it matches one or more items in our default Stripe block lists
Effected Transactions: 0[Active] Block payments from prepaid cards if they have daily 3 or more charge attempts per card number.
Review Effected Transactions[Active] Block if CVC verification fails
A payment will be blocked if the cards issuing bank cannot verify the CVC
Review Effected Transactions[Disabled] Block if Postal code verification fails
We don't block payment where the cards issuing bank can't verify the billing postal code[Active] Block if the risk level is
elevatedorhighestand CVC check fails.
This seems to be a redundant custom rule since all payments not passing the CVC validation are blocked.
Effected Transactions: 0[Active] Block payment if one IP tried to charge more than 5 times a day if no CVC validation is available.
There are legit cards which don't have CVC check available, so testing CVC of those cards is not an explicit fail. People try to abuse this case are surprisingly frequent.
Review Effected Transactions
Finally, when should a payment be placed in review?
These payments will not be placed in review if they match allow or block rules.
- [Disabled] Review if payment has a risk score of 65 or higher
Stripe's machine learning algorithm automatically evaluate the risk level of card payments.Stripe places successful payments in the review queue if their risk score is above 65 and below 75