Are you looking for test card numbers?

Would you like to contact support?

Risk-management icon

Consistency rules

Analyze shopper data for fraud by comparing transaction data points with each other.

Airline data leg

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

Triggers if the airline ticket purchased is a one-way ticket. One way airline tickets have a higher probability of being fraud.

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

Bank account is not likely to be a consumer bank account

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

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

Bank account number contains a numeric sequence

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

Fraudsters attempt numeric sequences of bank account numbers until they get a match - an example of a sequence is a bank account number is 1234567890. 

Bank address does not match any branch offices (ELV)

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

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

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

Billing address differs from delivery address

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

An address must be submitted in the payment request for this rule 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 cardholder address (AVS)

Triggers if 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 configuration may be required. Contact the Support Team for more information. If AVS is not supported, this risk rule is not performed.

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

You can configure how AVS is triggered:

  • Need to Match: - Triggers if a request receives a Match does not occur or Unable to perform check response.
  • Match or Unable to Perform Check: - Triggers if a non-match response is received. 
  • No Need to Match: - Turns off this rule 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.

We recommend setting the risk level for this check as Match or Unable to Perform Check for postal code and address. Turn on Unknown Response OK? to allow unknown error responses.

Trigger AVS

AVS for ecommerce

Supply the full address of the shopper using the billingAddress child element of the payment authorisation request:

    "street":"Example street",
<billingAddress xmlns="">    
  <country xmlns="">US</country>
    <city xmlns="">SF</city>
    <street xmlns="">Example street</street>
    <houseNumberOrName xmlns="">40</houseNumberOrName>
    <stateOrProvince xmlns="">California</stateOrProvince>
    <postalCode xmlns="">91351</postalCode>

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

  • city
  • street
  • houseNumberOrName
  • country

Optionally, provide the postalCode or stateOrProvince of the shopper. AVS does not validate stateOrProvince.

Pass address lines, like apartment or unit number, as part of street.

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 the response codes you receive from Adyen. If you prefer to receive the actual response code from the card or network, contact the Adyen Support Team to include this 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 setting is skin-specific. You must turn it on for each skin to apply AVS.

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="" value="US" />
    <input type="hidden" name="" 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" />

Test AVS results

To test your system's response to receiving an avsResult:

  1. Use our provided AVS test cards and billing addresses or create your own test cards.
  2. Include and define all the required billingAddress parameters.
  3. Set the value of street to Test AVS result.
  4. Set the value of houseNumberOrName to the AVS response code that you want to test from the table below. This table shows AVS response codes returned by Adyen, which are mapped to raw AVS response codes from acquirers.
    AVS Response code 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 if the card issuer responds that the user-entered verification code did not match that of the card.

The issuing bank declines mismatching transactions in most cases, as these transactions have a high likelihood of fraud.

You can configure how this rule is triggered:

  • 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 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 rule.

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

Card/bank account holder name contains a non-alphabetic character

Triggers if the card/account holder name has any non-alphabetic characters in it. Fraudsters sometimes insert random characters in the cardholder name field.

This rule is not triggered by Roman, Hebrew, Cyrillic, Chinese alphabetical characters

Card/bank account holder name is one word

Triggers if the card or bank holder name has one word in it.

Fraudsters often enter one word in the cardholder name field, for example, "Jessica", "John", "Bob". The fraud scores triggers if this happens and attributes a score accordingly.

Delivery method

Triggers if 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 rule is case insensitive. For example: mail,email,download.

Email address and shopper name comparison

Triggers if the name on the shopper's card is not part of the email address. The rule 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 if 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 the probability that 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 if the algorithm has detected behavior in the card number and/or CVC fields that appear to be scripted.

Fraudsters use scripts to test a set of cards. This risk rule analyses time taken, key-based, and mouse-based behavioTriggers ifr of users interacting with the payment fields.

Using this data, our risk system determines the probability that the behavior 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 available for if you are using Client-Side Encryption (Merchant-hosted and Adyen-hosted, version V0.1.12 or higher). It is not available for Client-Side Encryption (JavaScript) and direct API integration types.

Issuing country

Triggers if the issuing country for the shopper's payment method is in a list of countries which have a high percentage of fraudulent transactions.

Liability shift status

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

Liability shift occurs when the liability of chargebacks passes from you to the issuing bank. This occurs when the transaction has been verified through 3D Secure. You can configure the rule to trigger for 3D Secure transactions or all ecommerce credit card transactions.

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

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

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

You can determine on which transactions to apply liability shift, all transactions, 3D Secure transactions, or 3D Secure transactions without technical errors.

You can trigger the check on transactions where:

  • Full authentication of the cardholder has not taken place: Triggers if the 3D secure server can not authenticate the cardholder. Full authentication is stricter and always requires a (Y)-Authenticated response. The issuing bank may grant a liability shift without an authentication. 
  • 3D Secure liability shift has not taken place: Triggers if no liability shift has occurred for the selected transaction types. This does not always require full authentication by the user, for example, for automated authorizations performed by the issuing bank.

PayPal auth-result email

Triggers if the shopper email provided matches the shopper email registered with PayPal. 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

Triggers if the payment is eligible for seller protection. Set a negative score to decrease the chance of a transaction being refused. Increase the risk score to highlight orders where seller protection is Ineligible.

  • Set the level of protection eligibility: Full or Partial.

PayPal verified shopper

Triggers if the PayPal account used by the shopper is verified. Otherwise it will be marked as unverified. This rule 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.

Payment method

Triggers based on the payment method used. Some payment methods have more instances of fraud. This check lets you change the risk score based on the payment method behavior.

Shopper IP originates from high-risk country

Triggers if the shopper's country (determined by IP address) is in our list of high-risk countries. This check comes with some countries included by default. See How do I add shoppers to a block or trust list? to know more.

Note that IP addresses are not guaranteed indicators of a user's true country. Proxies and VPNs allow for fraudsters to hide their true location. This check should be paired with the use of the shopper using an anonymous proxy check.

Shopper account age

Triggers based on the date the shopper's account was created. This can either be provided as part of the payment request, or the check can use the oldest transaction within the shopper's ShopperDNA network.

Shopper country differs from issuing country

Triggers if the shopper's country is different to the issuing country of the card, which may indicate fraud. Set the risk score based on your business type. For example, Airlines can expect users are not in the country from which their card was issued. 

Configure certain country combinations to allow mismatches to occur. For example, where IP addresses are cross countries, such as in Belgium/France/Netherlands.

You may need to provide two configurations for any country-pair. For example, a configuration with 'Belgium/Netherlands' and 'Netherlands/Belgium'.

Shopper email validity

Triggers if 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

Triggers if the shopper appears to be using an anonymous proxy service.

Fraudsters often use anonymous proxies 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. 

Time To delivery

Triggers based on how close the transaction is to the delivery date. This can be used by airlines to calculate how far the transaction is to the takeoff time or by ecommerce merchants to correlate with express shipping.

You must provide the delivery time value in the payment request.

Transaction amount

Triggers based on the transaction amount. It is common for fraudsters to focus on higher-priced goods, to maximize their gains. This check can be used to either apply increased scrutiny to higher-priced goods or to focus specifically on the average-transaction-value that correlates with chargebacks.

Transaction time

Triggers if the transaction falls within one of the configured time frames.

Fraud can spike at specific times when legitimate transactions are limited, like during the night. This rule allows you to increase or decrease the risk score accordingly.