This page explains how to use our Fraud Detection solution, so you control what type of payments you accept and reduce the risk of fraud. If you have permissions to alter your risk settings, you will be able to add, edit and delete rules.
Pre-auth and post-auth are the stages in the payment lifecycle that you can use our solution to decide what happens to a transaction. The process the transaction goes through before reaching that outcome is called routing, and each stage has its own route. Routes have several data points that a transaction passes through. These data points can be rules, outcomes or decline lists.
The decision groups you see under Live strategy are affecting your live transactions. It is view only, so you will not be able to directly edit and affect live transactions.
Safely test changes to your decision points under the Test strategy section. It has no effect on your live transactions, but you will be able to see the hypothetical outcome of these changes.
Once you are happy with the results of your test, you can select Replace live strategy to affect your live transactions. This cannot be undone.
Rules are the building blocks of your risk strategy. They are set by Checkout.com and take the form of an expression. When a transaction is compared against a rule, it returns either true or false. This determines how it will be routed and the ultimate outcome, such as decline, or 3DS. Each true and false option is referred to as a branch.
Examples of rules:
Information within a transaction payload, for example ‘Transaction amount over 100USD’.
Additional contextual information, for example, ‘Billing address is valid’.
Statistical data derived from your traffic, for example, ‘Same card used more than 3 times in the last 1 hour’.
Rule groups are sets of individual rules that are grouped by different outcomes. At pre-auth, there are decline and 3DS rule groups. At post-auth, there are void and flag rule groups.
For example, if a transaction returns true for any rule in the decline rule group, the outcome of that transaction will be to decline it.
Add rules to groups by selecting Add rules at the bottom of each group. To remove a rule, select the three dots in the corner of the rule card and select Remove rule.
Transaction count checks the occurrence of a single attribute over a time period. For example, velocity (billing_address, 24h, _attempted_) > 10 will trigger when the number of approved requests for a particular billing address goes above 10 in a 24-hour period.
Cumulative spend USD checks the total amount spent in US dollars (USD) on a specific attribute over a time period. For example, spend_usd (card_number, 24h, _attempted_) > 1000 will trigger when attempted payments on a specific card number exceed 1,000 USD over a 24-hour period.
Relative checks the occurrence of 1 attribute in relation to another. For example, relative_velocity (email_per_cardholder_name, 30d, _attempted_) > 10 will trigger when the number of email addresses for a single cardholder goes above 10 in any 30-day period of attempted transactions.
The custom rules feature allows you to combine conditions to create specific triggers, which better target fraud patterns. When you select Create new rule, choose from a list of pre-defined properties, operators and functions, and velocities (frequency). These are the building blocks that allow you to create specific fraud rules for your risk strategy.
Custom rule examples:
Metadata, for example ‘Product code is 14569’
Same user attempting to pay with 3 different cards in 1 hour
Same user receiving more than 3 insufficient funds declines in 24 hours
IP address contains the range '98.195' AND email domain is either gmail.com or hotmail.com
Lists are sets of custom values that can be referenced in the rules. By default, you have access to a list of high-risk countries that are referenced in verified information rules. For example, the payment IP country is in a list of high-risk countries.
Add a list entry by navigating to the Lists tab and selecting Add entry. Here you will be able to enter a new value.
Create custom lists based on your own strategy. To see all the different properties you can use to build rules, from the Rules page select Create a rule, and navigate to the Properties section.
Different to decline rules, which are formulas that determine an outcome, decline lists are specific attributes that are not allowed.
For example, a decline rule may be amount > 1000 and card_country = Italy. An attribute in a decline list may be a specific card number or IP address.
If a transaction being routed through your strategy matches an item on a decline list, the transaction will be immediately declined. You can create a decline list for 6 fields:
Card number – the card’s 16-digit long number
BIN – the first 6 to 8 digits of the card number, used to identify which issuer the card belongs to
Email address – a customer’s full email address
Phone – a customer’s phone number
Payment IP – a customer’s IP address
Email domain – the domain of a customer’s email, which comes after the @ symbol
You can add to a decline list in 2 ways:
Select a transaction from the Payment details view in the Hub, and use the Decline list button
Add to a decline list from the Decline list tab within the fraud solution
Card numbers can only be added to a decline list from the Hub.
3DS transactions are subject to a liability shift. The shift occurs when the liability for fraudulent chargebacks (stolen or counterfeit cards) shifts from you to the card issuer. Use the Liability shift column to determine what outcomes it applies to.
Recommended transaction risk level
No – unless the issuer decides to challenge the transaction
A 3DS check means that your customer will have to prove their identity, such as through the use of a one-time pass code. This will reduce fraud, but also may impact your conversion rate.
Recommended transaction risk level
Risk profiles are a collection of rules used for scoring-based decision-making. They are made up of 2 sections – scoring rules and decision thresholds.
Each rule has a score between 0 and 100 – 0 being low risk, and 100 the highest. Transactions are compared against each rule in a risk profile, and if a transaction meets the rule criteria, the transaction will receive the points associated with it.
Scores can be a negative or positive number, and the ultimate risk score of a transaction is the sum of all the rules the transaction met the criteria for.
You can select as many rules as you want to be evaluated. The order the rules are defined is not important, because a transaction will be evaluated against each rule.
A transaction risk score must always be a number from 0 to 100. If the sum of scores is less than 0, the transaction risk score will be 0. If the sum is greater than 100, the transaction risk score will be 100.
Once the decisions have been selected, you can define the risk score bands that correspond to them. For example, you may decide to Decline all transactions with risk score above 90, and to Force challenge all transactions with risk scores between 70 and 90.
Our fraud and risk solution uses machine learning to score a transaction between 0 and 100. The closer to 100 a score is, the greater probability of fraud. Our machine learning model is trained on every single transaction that goes through the Checkout.com network. You can use this in your own risk strategy by adding the Checkout Risk - Scoring Rule Threshold rule to one of your lists. The threshold for our machine learning is 70, so if a transaction is scored 70 or above, the rule will return true. This threshold has been selected so only very high risk payments trigger this.
The machine learning algorithms will be more accurate the more data you send to us. To get the best use out of this rule, we recommend that you send IP address data, billing or shipping address data, card data and customer email address.
Set a custom threshold for your machine learning rule. You can use the scores automatically applied to every transaction to direct transactions to different outcomes. This works similarly to a risk profile, and can be used by selecting the Checkout CC Model component in the rule selector.
Troubleshoot our Fraud Detection solution
Understand why certain errors happen, and how to fix them.