Search

Are you looking for test card numbers?

Would you like to contact support?

Consistency rules

Consistency checks analyze shopper data for fraud by comparing transaction data points with each other. For example, comparing a provided bank address with known banks.

Airline Data Leg Check

This rule allows you to block or trust transactions based on the legs of a journey.

You must submit airline-specific data with the payment request.

Submit each leg individually, in IATA format. Give the leg a positive score to block it, or a negative score to trust it. Set each leg individually. For example, if you create a rule between AMS and JFK, you must create a separate rule between JFK and AMS.

Airline Data One Way Ticket Check

Triggers when the airline ticket purchased is a one-way ticket. One way airline tickets are more likely to be fraud.

You must submit airline-specific data with the payment request.

Bank Account is not Likely to be a Consumer Bank Account

Triggers when the provided account number is likely not a real consumer bank account.

This check confirms the provided number has the correct number of digits and has a check digit (in the case of ELV).

Bank Address Does Not Match Any Branch Offices

Triggers when the provided bank address does not match any registered branch office for that bank. This check is specific to ELV payments.

Bank Name does not match bank location id (blz.) (ELV)

Triggers when the provided bank name does not match any registered branch office for that bank. This check is specific to ELV payments.

Billing Address Differs From Delivery Address

Triggers when the billing address is different to the delivery address.

An address must be submitted in the payment request for this check to work properly.

Fraudsters often deliver goods to a different location than indicated in the billing address of the stolen payment details. Addresses are normalized for accurate matching when minor differences in spelling and formatting occur. Comparison is limited to the country, postal code, and house number.

Billing Address Does Not Match Card Holder Address (AVS)

Triggers when AVS reports a mismatched cardholder address. Address Verification System (AVS) is a security feature that verifies the billing address of the cardholder. It does this by comparing the billing address the shopper enters with the address on file with the card issuer. AVS validates the street address and zip/postal code of the shopper.

AVS gives you better protection against fraud, and lower interchange fees in the United States, as you can qualify for the lowest rate.

AVS for Visa and Mastercard is supported by Adyen in all countries, for a limited number of issuing banks. For payments outside Canada, the United States and United Kingdom, some additional configuration may be required. Contact the Support Team for more information.

This risk rule is based on the issuer and may not be available for every transaction.

The settings for Address Verification Service (AVS) check screen allows you to set the minimum level of matching required for AVS checks, and whether an unknown response is permitted.

AVS is only supported on a limited set of acquiring connections and card types. For more information, see AVS. If AVS is not supported, this risk rule is not performed.

Configuration Options

For both the postal code and address, there are three separate configuration options. They are in order of strictness:

  • Need to Match: - Triggers when a request receives a Match does not occur or Unable to perform check response.
  • Match or Unable to Perform Check: - Triggers only when a non-match response is received. 
  • No Need to Match: - Turns off this check for this data point (address or postal code).

In some scenarios, Adyen receives back an Unknown error response. You can select to either allow or disallow transactions with this response.

The suggested implementation for this check is below: 

You should only configure this check more strictly if they want to be confident in an address match (not recommended).

Trigger AVS checks

AVS for Ecommerce

Supply the full address of the shopper using the billingAddress child element of the payment authorisation request, as shown below:

{  
  "billingAddress":
  {  
    "country":"US",
    "city":"SF",
    "street":"Example street",
    "houseNumberOrName":"40",
    "stateOrProvince":"California",
    "postalCode":"91351"
  }
}
<billingAddress xmlns="http://payment.services.adyen.com">    
  <country xmlns="http://common.services.adyen.com">US</country>
    <city xmlns="http://common.services.adyen.com">SF</city>
    <street xmlns="http://common.services.adyen.com">Example street</street>
    <houseNumberOrName xmlns="http://common.services.adyen.com">40</houseNumberOrName>
    <stateOrProvince xmlns="http://common.services.adyen.com">California</stateOrProvince>
    <postalCode xmlns="http://common.services.adyen.com">91351</postalCode>
  </billingAddress>
billingAddress.country=US&billingAddress.street=Example+street&billingAddress.houseNumberOrName=40&billingAddress.postalCode=91351&billingAddress.stateOrProvince=CA&billingAddress.city=SF

When you submit the billingAddress object for AVS, the following child elements are required:

  • city
  • street
  • houseNumberOrName
  • country

You have the option to provide the postalCode or stateOrProvince of the shopper, though AVS does not validate stateOrProvince.

If you are collecting multiple address lines, such as collecting apartment or unit number, append the lines and pass them as part of street.

See Address for more information about the fields.

To qualify for better interchange rates submit the billing address and zip code for card not present transactions. This is not guaranteed, contact Support Team to know more.

The country value format needs to adhere to the ISO 3166-1 alpha-2 standard. An invalid country code results in a transaction/request rejection. You can look up country codes on the ISO website.

Different card brands and networks have specific AVS response codes. They are mapped to our generic response codes, which are the ones you receive by default. If you prefer to receive the actual response code from the card or network, contact the Adyen Support Team to request enabling the raw AVS reason for you. After enabling, this information is included in your notifications.

AVS for Hosted Payment Pages (HPP)

To turn on AVS for an HPP skin, go to Customer Area > Skins > [Skin Code]. Under Skin Options, select the Billing Address Fields (AVS) checkbox. 

The AVS check setting is skin-specific, so you need to turn it on for each skin that you want an AVS check.

For a list of parameters required for this call, refer to HPP billing address and AVS fields.

You can choose to have the HPPs pre-populate the billing address information from your own system, as shown below:

<input type="hidden" name="billingAddressType" value="1" />
<input type="hidden" name="billingAddress.country" value="US" />
<input type="hidden" name="billingAddress.city" value="SF" />
<input type="hidden" name="billingAddress.street" value="Example Street" />
<input type="hidden" name="billingAddress.houseNumberOrName" value="40" />
<input type="hidden" name="billingAddress.stateOrProvince" value="California" />
<input type="hidden" name="billingAddress.postalCode" value="91351" />

AVS result testing

To test your system's response to an AVS result, avsResult, include and define all the required billingAddress parameters. You can use our provided AVS test cards and billing addresses or create your own test cards.

For the street parameter, use the value Test AVS result. For houseNumberOrName, use the Result value that you want to test from the table below:

Result value Description
0 Unknown.
1 Address matches, but the postal code does not match.
2 Neither postal code nor address match.
3 AVS unavailable.
4 AVS not supported for this card type.
5 No AVS data provided.
6 Postal code matches, but the address does not match.
7 Both postal code and address match.
8 Address not checked, postal code unknown.
9 Address matches, postal code unknown.
10 Address doesn't match, postal code unknown.
11 Postal code not checked, address unknown.
12 Address matches, postal code not checked.
13 Address doesn't match, postal code not checked.
14 Postal code matches, address unknown.
15 Postal code matches, address not checked.
16 Postal code doesn't match, address unknown.
17 Postal code doesn't match, address not checked.
18 Neither postal code nor address were checked.
19 Name and postal code matches.
20 Name, address and postal code matches.
21 Name and address matches.
22 Name matches.
23 Postal code matches, name doesn't match.
24 Both postal code and address matches, name doesn't match.
25 Address matches, name doesn't match.
26 Neither postal code, address nor name matches.

Card Security Code (CVC2/CVV2/CID) Does Not Match

Triggers when the card issuer responds that the user-entered verification code did not match that of the card.

The issuing bank usually declines mismatching transactions, however in some rare scenarios they may not. These transactions have a high likelihood of fraud, even though the issuing bank authorized the transaction.

Configuration Options

There are three separate configuration options for handling these responses. They are in order of strictness:

  • Need to Match: When this is selected, the rule fires when the Match does not occur response, and Unable to perform check response is received.
  • Match or Unable to Perform Check: In this configuration, the rule fires only when a non-match response is received. 
  • No Need to Match: Under this configuration, the rule will not fire if a non-match response is received. This essentially turns off this check.

In some scenarios, Adyen receives back an Unknown error response. You can select to either allow or disallow transactions with this response.

Corporate Card Check

Triggers when the card being used in the transaction is a corporate credit card.

Corporate credit cards are quite common in some verticals. However, in other verticals there are high chances that the card is compromised. This check can be used to affect the risk score in these cases. 

Delivery Method Check

Triggers when the provided delivery method matches a configured value. This is most commonly used to flag express delivery transactions as higher risk.

Fraudsters want to ensure that as little time as possible passes between them committing a transaction, and receiving their goods. As such, faster delivery methods tend to be higher risk. 

Enter a list of blocked delivery methods under Modify blocked delivery methods. The list is comma separated and the risk check is case insensitive. For example: mail,email,download.

Email Address does not Contain Shopper Name

Triggers when the name on the shopper's card is not part of the email address. The check can account for partial matches.

A match between shopper's name and email address content indicate the shopper is probably legitimate. While it is common for fraudsters to have firstname.lastname@email addresses, it is rarer for them to actually match them to the name on the payment methods.

Email is likely to be fake or automatically generated

Triggers when the provided email address is likely fake or automatically generated. Fraudsters set up scripts to automate the creation of email addresses. Our prediction algorithm analyzes email address across our entire network and correlates certain attributes with fraud and known card-testing schemes.

Using this data, our risk system determines how likely the email address is to be fake. You can set a separate risk score for payments that are Somewhat likely to be fraud and Very likely to be fraud. These scores will increase the total risk score of the payment.

Fraudulent behaviour on payment page

Triggers when the algorithm has detected behaviour in the card number and/or CVC fields that appear to be scripted.

Fraudsters employ various scripting techniques to test cards quickly. This risk rule analyses time taken, key-based, and mouse-based behaviour of users interacting with the payment fields.

Using this data, our risk system determines how likely the behaviour is fraudulent. You can set a separate risk score for payments that are Somewhat likely to be fraud and Very likely to be fraud. These scores will increase the total risk score of the payment.

This risk rule is only available for merchants utilizing or Client-Side Encryption (Merchant hosted and Adyen hosted, version V0.1.12 or higher). It is not available for Client-Side Encryption (JavaScript only) and direct API integration types.

Liability Shift Status Check

Triggers if a liability shift has not occurred with the transaction. Note that this check has significant configuration implications.

Liability shift occurs when the liability of chargebacks passes from the merchant to the issuing bank. This is usually done when the transaction has been verified through 3D Secure. Merchants can configure if the risk rule should be triggered only for 3D Secure transactions or all e-commerce credit card transactions.

Be careful when changing 3D Secure settings as they can impact your conversion rate.

This check is only triggered for E-Commerce transactions. Recurring (ContAuth) transactions have no liability shift by definition, thus are not analyzed and are accepted by this check. Contact Support Team if you want to disable ContAuth transactions (via Transaction Rules) on this merchant account.

It is also possible to give a negative (trust) score for the check.

Configuration Options

There are several different configuration options that dramatically change how this check operates.

Apply the liability shift check for (In order of strictness):

  • All E-Commerce Credit Card Transactions: This causes the check to fire for non-recurring credit card transactions where 3D has not been attempted at all, as well as scenarios in which it has. Merchants should only select this option if all transactions on the account are processed with 3D Secure. This kind of strict setup is only suggested for very high risk merchants. 
  • Only 3D Secure Transactions: This option results in the rule firing if 3D Secure was attempted, but liability shift did not take place. In situations in which 3D Secure did not occur (usually due to Dynamic 3D Secure thresholds), this rule is not triggered. Additionally, some transaction types are incompatible with 3D Secure (such as ContAuth). This option ignores those payments and the checks are not fired. 
  • Only 3D Secure Transactions Without Technical Errors: In some situations, a technical error may occur which prevents 3D Secure authorization. In these cases, a liability shift could not occur because of the technical error. This configuration eliminates these situations from being assessed by this rule. 

Trigger check on transactions for which (In Order of Strictness):

  • Full authentication of the card holder has not taken place: The rule triggers when the card holder could not be fully authenticated by the 3D Secure servers. Full authentication is stricter and always requires a (Y)-Authenticated response. Note that the issuing bank may grant a liability shift without an authentication. 
  • 3D Secure liability shift has not taken place: The rule triggers when no liability shift has occurred for the selected transaction types. This does not always require full authentication by the user i.e. the authorization was done via an automated process by the issuing bank. 

PayPal Auth-result Email

This risk check initiates when the shopper email provided matches the shopper email registered with PayPal. Only applicable for PayPal payments. The trust score can be used for shoppers that should be considered trustworthy, for example, shoppers with a history of legitimate purchases. Setting a negative score will decrease the chance of a transaction being refused.

PayPal Protection Eligibility

This risk check initiates when based on whether or not the PayPal payment is eligible for seller protection. If yes, a negative score can be set to decrease the chance of a transaction being refused. Merchants can also increase the risk scoring to highlight orders where seller protection is Ineligible.

  • Set the minimum protection eligibility: Full or Partial.

PayPal Verified Shopper

This risk check initiates when if the PayPal account used by the shopper is verified. Otherwise it will be marked as unverified. This check also triggers fraud when the payer status is missing. Set a negative trust score for trustworthy shoppers to decrease the chance of a transaction being refused. For example, shoppers with a history of legitimate purchases.

Shopper Country Differs From Issuing Country

This risk rule is triggered when a transaction has the shopper country different from the issuing country of the card.

This check is one of the most effective checks in stopping fraudulent transactions from occurring; the majority of fraudulent transactions occur when the shopper country differs from the issuing country. The scoring for this rule should be set based on your business model. An airline, for example, can expect to see more situations in which users are not in the country from which their card was issued. 

Configuration Options

A merchant can optionally configure certain country combinations to allow mismatches to occur. If these specific mismatches occur, the rule does not fire. This is best utilized when IP addresses are cross countries, such as in Belgium/France/Netherlands/Belgium. It's important to note the following:

  • The left side column represents the shopper country - the right side is the issuing country of the card. 
  • Note that you may need to provide two configurations for any country-pair. For example, a configuration with 'Belgium/Netherlands' and 'Netherlands/Belgium.'

Shopper Email Validity

This check fires when the provided shopper email address does not appear to be a real email address.

This risk rule verifies that the email provided in a transaction is valid, using analysis of both the domain and the DNS mail-delivery MX record. 

Shopper using Anonymous Proxy

This risk rule fires when the shopper appears to be using an anonymous proxy service.

Fraudsters often use anonymous proxies in order to hide their identity. While proxies are not always indicative of fraud (one may use proxies in an office environment), it can be an indicator of possible bad intent. 

The Bank Account Number Contains a Numeric Sequence

This check fires in situations in which the bank account used for Direct Debit payments has a direct numeric sequence.

It is a consistent trend for fraudsters to attempt numeric sequences of bank account numbers until they get a match - an example of a sequence is a bank account number is 1234567890. 

Name Contains Non-Alphabetic Characters

This check will fire when the card/account holder name has any non-alphabetic characters in it.

A consistent fraud trend is for fraudsters to insert random characters in the card holder name field. Note that this check does consider non-Roman Alphabet characters as being alphabetic, so merchants with card holder names in Hebrew, Acrylic, Chinese, etc. can use this check. 

The Card/Bank Account Holder Name Is Only One Word

This fraud check fires when the card or bank holder name only has one word in it.

Fraudsters often only enter one word in the card holder name field, (e.g. "Jessica", "John", "Bob"). The fraud scores triggers if this happens and attributes a score accordingly.

Transaction Time Check

This check fires when the transaction falls within one of the configured timeframes.

Most merchants notice that fraudsters tend to visit their site during certain parts of the day. It is not uncommon, for example, for fraud to spike during the night hours while legitimate transactions are limited. This flexible check allows merchants to specify any date-time timeframe and increase or decrease the risk score accordingly.

Configuration Options

In order to establish a timeframe, select the date and enter two concurrent times. For example, if you want to assign a score of 10 for transactions on Saturday between 10:15am and 2:30pm, select Saturday, enter From = 10:15", To = 14:30, Score=10, and click Add.

You can also define an interval across two days. To define Tuesday 10:30pm to Wednesday 2:00am, select "Tuesday", fill in "From = 22:30" and "To = 02:00".