Preventing Credit Card Fraud with Stripe Radar

In the article How to Prevent Credit Card Fraud and Chargebacks, we provided red flags to be cognizant of with customer orders, and internal processes you can embrace to be proactive in protecting your business from credit card and e-commerce fraud. In this article, we will specifically delve into Stripe’s anti-fraud service, Radar, and rules to follow to reduce fraud and chargebacks. Further, we’ll discuss added protections and customization options that will ensure the platform is tailored for your business.

*E-Commerce Gorilla has no affiliation with Stripe, and this article is solely based on the positive experiences E-Commerce Gorilla has had with Stripe’s payment platform. In short, he has found it to be well-developed and a good fit for many of his clients over the years, especially smaller businesses and startups.

What is Radar and how much money and time will I need to invest?

Stripe’s Radar is a fraud prevention platform that utilizes machine learning as a means to detect and block fraudulent transactions. Already use Stripe’s standard payment account? Great! We’ve got awesome news for you! Radar is integrated directly into the platform, and with the standard payment account, which you’ve acknowledged you have, you have access to Radar, and there are no additional fees for processed transactions! If you’re not set up on the standard plan, no problem! You will be excited to hear that you will be able to gain access to Radar at a wonderfully low rate. For smaller and newer businesses, employing Radar’s protection provides you with a safeguard against malicious fraudulent attempts against your business. What’s more, is that it is an out-of-the-box solution. That’s right! Unlike many third-party providers, Stripe’s Radar is accessible. There is no need for extensive training or knowledge of fraud prevention algorithms.

So, I have transactions that were flagged as high-risk. What’s next?

3D Secure 2 can help you with how to move forward with high-risk transactions. It is a security standard that adds additional fraud protection. 3D Secure 2 is the next generation of the highly effective 3D Secure standard you may know by its branded names—Visa Secure, Mastercard Identity Check, or American Express SafeKey.

Serving you, through business-centric customization

Okay, so now that we’ve talked about Radar and 3D Secure, let’s talk about custom rules that you can apply that will help you to target those high-risk transactions. Whenever a transaction is flagged for review, running them through 3D Secure enables you to safeguard high-value products or services that are more likely to be targeted for fraudulent activity. As discussed, in general, Radar does a good job with their out-of-the-box solutions for the default setup, but we recommend a stricter Radar setup than the default. There may be instances when you wish you could apply rules that are specific to your business. This is where custom rules provide you with benefits geared toward your business.

As we navigate through custom rules together, we’ll do so with both the rule logic and intent. By the time we reach the end of this article, you will have the knowledge necessary to make a well-informed decision as to how to customize your Radar and 3D Secure package so that it aligns with your business model.

Start with a foundation, and then build with custom rules

*Disclaimer: Before we get started with the custom rules, it is important for you to understand that these are the rules E-Commerce Gorilla suggests. This article is not intended as a consultation or advice for your individual business.

Begin with the default rules

Leave all of the default Stripe Radar rules in place, with the intention of using it as a strong foundation for building out the custom rules. Next, begin assessing each of the four Radar ruleset sections, which are processed sequentially in the following order: Request 3D Secure, Allow, Block, and then Review. Sections can be viewed as a filter. What’s more is that if a transaction matches the criteria of a current block, it won’t move on to any of the subsequent sections.

The Allow Section

This section permits the ability to assign rules that allow a payment to be processed. It is important to note that payments that fit within the Allow rule criteria will not be evaluated by any Block or Review rules because your rule allowed that transaction to pass through the payment acceptance and shipping processes. Placing too many rules in the Allow section is ill-advised, as it is better to err on the side of caution and force payments to run through the exclusion (Block or Review) rules. There are of course a few notable exceptions, which are discussed later in this article.

The Block Section

To block means precisely that—these rules block (stop or prevent completion of) a transaction. Blocked transactions are not evaluated against any of the review rules.

The Review Section

The rules provided in the Review section allow for a transaction to be processed but then places the transaction in a manual review status.

The Rule Process

When writing a Radar rule, the structure has two components: (1) The action the rule should take; and (2) The condition to evaluate the rule.

Action IF Condition

Starting out are our 3D Secure rules all merchants should have:

Request 3D Secure if :card_country: != :ip_country:

This rule forces a card through the 3D Secure authentication process if the country code on the IP address of the individual entering the card details does not match the same country as the credit card issuing bank. For example, if the customer’s IP address placing the order was from France but the card was issued from a bank in South Africa, they would be required to process through 3D Secure. There are numerous legitimate reasons why an IP address and card issuing country might not match. As such you don’t want to block it outright.

Request 3D Secure if :amount_in_usd: > 45.00 and :risk_level: != 'normal'

This rule checks if the transaction is more than $45 US, and if the Radar platform identifies the risk level of the transaction as abnormal, it will require the customer to go through 3D Secure authentication for the transaction. This is where the machine-learning of the Radar platform starts to shine, as it can use numerous fraud risk identifiers and place the transaction in a risk matrix to make evaluations about potential fraud. The $45 is just a placeholder. You can set this to any level you feel begins to be in the range of fraudulent transactions for your business. You can use any currency you’d like in this filter and more information on currencies can be found in the Radar documentation.

You could push all abnormal risk levels into 3D Secure with:

Request 3D Secure if :risk_level: != 'normal'

Bear in mind though that each step you place on a customer’s conversion path is another opportunity for abandonment. By using the risk level in conjunction with a minimum dollar amount, you get the best of both worlds—a smooth conversion funnel while limiting high-dollar fraud.

The Allow Rules

Without a very good business-specific related reason, we recommend only enabling one extra rule:

Allow if payment is authenticated with 3D Secure and has a liability shift

What this rule does is say: If a transaction has been processed through the Require 3D Secure ruleset, then it should be allowed to be completed. If the customer failed the 3D Secure authentication, the transaction would already have been declined.

The Block Rules

Besides the default activated rules, we want to ensure we enable the following default rules:

Block if CVC verification fails

Block if ZIP code verification fails

These rules require that both the CVC (the security code on a credit card), and the zip code on the billing address, match that of the card. 

Block if :is_disposable_email: and :is_anonymous_ip:

This rule uses Stripe’s internal list of disposable email providers and then checks to see if the IP address attempting to make a purchase is using a known list of Tor networks or proxies to mask their actual IP address from the payment gateway. This is a very common practice for fraudsters.

Block if :card_country: != :ip_country:

This rule blocks any transaction where the issuing bank’s country does not match the country of the customer’s IP address. Now you might be saying, “Hey wait a minute. We tested for this earlier.” You’re right. We tested for this in the Request 3D Secure and then approved all valid 3D Secure authentications in the Allow ruleset. Here we are now, blocking all orders that didn’t pass the 3D secure validation.

Block if :is_disposable_email: and :card_funding:= 'prepaid'

This rule checks if the customer is using a disposable email account and if the card attempting to make the purchase is a prepaid card. If it is, it blocks the transaction.

Block if :charge_attempts_per_customer_hourly: > 7 and :card_country: != 'US'

This rule blocks the transaction if more than 8 attempts have been made to charge the same customer in the last hour. [[[Charge_attempts_per_customer_hourly]]] starts counting at 0, hence why > 7 actually means 8 charges. While 8 charges are plenty, if you find that your business model customers frequently fail at entering card data correctly, you could move this rule to the Review ruleset so you aren’t losing revenue.

Block if :card_country: != ‘US’ and :risk_level:!= 'normal'

Here we are blocking all transactions that are not charged against a card from the United States, that are not viewed as a “normal” risk level, according to Stripe’s Radar. You can customize this for your business location by using any two-character country code. 

Now, if you find you have a high level of fraud originating from specific countries, you can block those by using the Client IP country block list. Go into the list and add all countries from which you wish to block transactions. This works as we left the default rule of: 

Block if payment matches one or more values in default Stripe block lists

as enabled.

A note of caution: If you are operating in the European Union, there are regulations about blocking purchases and payments from member EU states, so check with your legal counsel about any potential restrictions if you are looking to block entire member states.

The Review Rule

In the Review ruleset, use:

Review if :risk_level: = 'elevated'

which will process, but hold any transaction with a risk level evaluated as “elevated” in the Radar platform.

Also, look to set a high-value limit to automatically hold a transaction for review. This will depend greatly on your business model and its susceptibility to fraud, but choosing a high order amount is a safe strategy.

Review if :amount_in_usd: > 350.00

This rule will still allow the customer to check out without impediment. However, it will hold all transactions over $350 US for manual review. The amount can be set to any amount that works for your business model and your business’ susceptibility to fraud.

As I’m sure you are beginning to realize the power in the Radar rulesets, I will reiterate: You are much better off creating rules to block or review transactions rather than creating rules that allow them, due to the cascade effect of the rule system.