Optimal Fraud Prevention with Stripe Radar Rules

Many guides and references about Stripe Radar are damaging sales and conversions due to improper setup and configuration. Copying another businesses’ rules to your account is bound to end in more lost sales than if they were left alone. Instead, you need to selectively enable the rules that apply to your business and where they are seen to make an impact against fraud. Luckily, Stripe gives you an estimate on any rules configured and the effect but only if you have substantial processing with them already. When you decline a transaction, there is no way to know if it was genuine fraud unless you contact the customer and ask why they abandoned the sale. In cases where you are talking to a fraudster, they might lie to you, and a good customer might ignore you. In both scenarios, you are unable to discover the truth of the lost sale.

At this point in 2021, Stripe’s Radar tool has improved substantially since its early days. It used to be critical to layer on another fraud tool if you wanted any elevated protection. However, with the advancements in their machine learning and breadth of data, Radar has become a standalone product that can compete against many other fraud prevention tools. Stripe even added reasoning into their risk scoring, which is critical when evaluating the components of their decision, such as if the card number was typed or pasted. Stripe and other payment services can improve their machine learning models since they process so much volume that only the top fraud tools can collect.

New Stripe Radar Insights 2021

Now you might ask, how do I improve Stripe Radar and prevent fraud the right way? To start, you need to baseline who the real fraudsters are vs. good customers. This step is more manual but can be skipped if you already have a good handle on your fraud. One way to do this is using some friction after the transaction before the delivery of your good or service. This is a critical time to act upon the fraud as it is when Stripe Radar gives you the risk scoring. Unfortunately, with Stripe, it only happens at this step which is a potential con vs some other fraud tools which can better monitor a customer throughout their entire journey (signup, login, cart, etc.). Another downside with Stripe is they don’t customize their model per a certain category of goods you sell. (For example, if you sell mostly T-Shirts but also sometimes a risky item like an iPhone the score will not be adjusted per your defined metadata). If you are looking for another risk scoring tool we currently recommend Amazon Fraud Detector. It is difficult to setup and use so if you are looking for a easier way to get started with it you can use Trust Swiftly as we already have it built in our dashboard.

The friction you add can be various methods such as email or calling the customer to verify their purchase. This is one method Amazon leverages when you make a sizeable risky transaction that needs review. You will receive a call from a person asking questions about your order and address. However, this type of friction is not fool proof and requires dedicated staff to the problem. Instead, if we use a tool like Trust Swiftly, we can add many methods of verification to confirm an order tailored to your customer’s preferences. Trust Swiftly is an automated tool that can request various verifications for the customer to complete. In many cases, the customer will turn out to be good, and the order can be successfully processed. For the scenarios where you believe it is fraud, you can step up the friction to a point where you are confident about the decision. Doing step up checks might be a hassle for your team, but the greater burden falls on the fraudster who must have varying levels of information ready to bypass a verification. Usually, starting with an easy level of verification works and then a gradual increase of friction will keep sales and fraud in balance.

Some businesses might think 3D Secure is enough, but there are plenty of scenarios where it can cause conversion losses or not actually prevent fraud. When applied blanketly across all transactions, there are factors that should be considered to avoid conversion losses. We have even seen a case where a client was declining all cards that didn’t support 3D secure using Stripe Radar. The denial of a substantial amount of business caused customers to complain and loss of long-term relationships. To look at 3D secure in detail we outlined some problems with it below:

3D Secure Cons

  • Customer are not familiar with it and not enrolled which requires added steps.

  • More than doubles page loading time until payment complete

  • Ignores the message thinks its fake

  • No cell reception and bank only allow SMS for the authentication

  • Phone not accessible (International travel, power, broken, etc.)

  • Family member shopping as a favor

  • Customer number SIM swapped or malware can capture the 3DS code

  • 3DS2 skips the code request but also likely to authenticate cases of a compromised shopper due to behavior cloning.

However, these tradeoffs are not a reason to remove 3D secure all together. Instead, 3D secure should be another type of dynamic friction that is used for your customers. Fraud chargebacks can be stopped with 3DS authenticated transactions and in some cases can be a better value than a guarantee option like Stripe’s Chargeback Protection. A balance of 3D secure with other types of friction will lead to optimal growth. Allowing non authenticated orders to still be completed is useful to creating the fastest checkout process.

We have also seen some businesses only attempt 3D secure for the first-time payments and future charges by the customer can be whitelisted if they use the same card. This same method can be applied using Trust Swiftly’s different verification methods. If a customer verifies their phone, they should be allowed to order as long as Stripe risk scoring doesn’t call for a more secure review. In the end, a healthy balance of 3D Secure with other methods from Trust Swiftly will allow you to have complete coverage for all types of card issuers no matter the country.

Now to look at some of the rules that can be implemented to stop fraud. These won’t prevent all chargebacks and some are a cost of doing business. Once you near higher dispute rates you will even put your Stripe account at risk of closure. The below rules should be lenient and even adjusted further to start off on your fraud prevention. Once you have baselined your fraud thresholds, then they can be further adjusted to include dynamic friction.

Top Suggested Stripe Radar Rules to start (Adjust, Monitor, Test Frequently)

A list of all rule references can be found here or you can add more options with custom metadata.

1.     Request 3D Secure for supported cards when Risk Score > 65

a.     Reasoning – Instead of outright declining high-risk payments or reviewing them we can put them through a first level of check using 3D secure. In many cases this can prevent fraudulent charges but should be monitored for success rates due to the added friction.

2.     Address Zip Check fails and Risk Score > 30 and Amount in USD > 100

a.     Reasoning – Many zip failures are from good customers so we should only have the restriction in place if it matches some other common fraud signals. Also, Zip check (AVS) only works for countries like USA, UK, NZ, AU and CA.

3.     Charge attempts per card hourly greater than 4

a.     Reasoning – Usually after a few attempts for a charge there is something wrong with the data or the bank won’t process it. The fraudster might be trying to change small pieces of information to bypass it. However, good customers can fall into this case too so your support should be able to identify cases that are false.

4.     Block if Risk Score greater than 85

a.     Reasoning – Stripe’s machine learning models are robust and usually anything in the highest risk level mean they seen one of the data points associated with fraud. However, this score should not be trusted completely as there are plenty of cases where the score is incorrect.

high-risk-ruleCustomized rules for high risk

all-stripe-rulesIn the end there isn’t a simple set it and forget option with Stripe Radar and fraud. If you are using rules heavily, they should be monitored and adjusted to ensure they are not harming sales. Once you get a hang of the tool, you can advance your skills to rely more on automation and machine learning scores. Tools like 3DS and Trust Swiftly can provide the extra dynamic friction that will get your business to an optimal setup against fraud. Another aspect to keep in mind is these rules are mainly for real fraud and not cases of friendly fraud where the customer knowing disputes a payment. Using tools like Trust Swiftly however can reduce friendly fraud too as the added information about the customer can make them second guess initiating a dispute and even help as evidence when responding in Stripe. Lastly, another confusion on Stripe rules are payments marked as Failed status. Most decline cases will be out of your control and not caused by radar but instead by the bank with codes such as donothonor.

Our goal is to help you spend less time writing rules and instead put your fraud control in auto-pilot. By adding in some friction it adds costs of doing business for the fraudsters too which should greatly outweigh your own. Now a bad actor might need to procure a real email, ID or phone which costs many factors more than only the stolen credit card number. If you have any questions about setting up Stripe or advancing your configurations please check out our Stripe Radar Integration and we would be glad to take your business to the next level.

Updated Stripe Radar Rules for 2023

We did a check-in with a client to see how well Trust Swiftly has been performing for their business. To no surprise, they can outperform comparable companies in a higher-risk digital goods industry. Having a low block rate increases revenue long term and creates a better experience for their customers. This was not an overnight success, but it took a few months to adjust their rules to reach an acceptable level. The key was removing bad block rules. They gradually incorporated Trust Swiftly into more payment reviews and accepted new customers. Their dispute rate is only marginally higher and no where close to the Monitoring Programs. Our next plan with the client is to automate some of the dispute management. We have seen upticks in disputes across the market due to the downtrend in the economy. Many of the disputes can be won by simply requesting the customer to cancel it with their bank. We are building tools to automate the entire process to contact the customer through multiple channels such as email, phone, and physical letters depeneding on the size of disputes.
Stripe Radar Stats with Trust Swiftly

Next, we recently searched to find out what other Stripe customers used for rules. On Twitter there was a healthy discussion on what can be done about Stripe and fraud. Many businesses are being harmed using these block rules in the long run. They should gradually move to a more review-based system and retain only the most prominent cases of fraud. Fraudsters are getting more sophisticated, and static rules do little to deter them. Our next goal for our clients is to get to a level where they can replace the top rule, which is risk_level = highest, to move the payments to reviews. Not to disparage Stripe's scoring system, but there have been cases where it was inaccurate. All machine and AI systems have faults and Stripe's is no exception which is why having a supplementary fraud management process is critical. You need to weigh the risks of your own business to determine if you can accept more payments. If you have a robust chargeback management process and a low dispute rate, it should allow you to open up to more payments. For most, it won't be a simple switch but may change the rule to a more defined one where it adds another condition, such as order amounts over $200. As seen, fraud is a moving target, and experimenting with Radar rules is critical to keep ahead in the game.

More Example Stripe Rules from Twitter (Not advised to follow these all)

Twitter Stripe Radar rulesRadar bad rules