RevenueProtect

Risk management consists mainly of preventing the reversal (chargeback) of transactions after the product or service has been delivered. Chargebacks are caused by fraudulent users using another person's payment credentials to make a purchase. For many transactions, merchants are financially liable for fraudulent transactions, so it is important to keep control over this process. 

Adyen deals with fraud and risk management in an innovative way. The most important goal for a risk manager is to minimize fraud costs while maximizing conversions.

The primary advantages of the RevenueProtect system are:

  • Fully-Integrated and Hosted: RevenueProtect is fully integrated into your Adyen payment processing.

  • Full-Stack: RevenueProtect offers features across the risk mitigation process, ensuring Adyen is your one-stop-shop for fraud prevention.

  • Real-Time and CustomizableAll aspects of RevenueProtect work in real-time and each aspect of your strategy can be adapted as your trends change.

  • Technology-Driven: Features like ShopperDNA and the Risk Engine Optimizer put advanced transaction linking algorithms and machine-learning prediction modeling at your fingertips.

  • Dynamic: Fraud is never binary and neither is RevenueProtect. Features like Dynamic 3D Secure and Manual Case Management allow you to control where your transactions go.

Managing

Accepting payments comes with risks. The primary risk to merchants is having a transaction reversed by the bank – this is called a chargeback. 

 Possible reasons for chargebacks include:

  • Fraud, where a credit card or bank account of someone else is used by a fraudster.

  • Not enough balance on a bank account (Direct Debit).

  • The transaction is not recognized by the cardholder who made the payment.

  • There has been a problem in the delivery or return of the product.


The purpose of a risk management system is to detect transactions that have a high likelihood of being charged back.  Although not every chargeback can be detected beforehand, it is still possible to detect and avert most fraudulent transaction attempts. At its core, the primary role of the risk manager is to predict as many chargebacks as possible without negatively affecting the conversion rate on good transactions.

Finding the right balance

For every blocked transaction, there is a chance that it would have been a legitimate transaction. A risk mitigation system that is set up too aggressively may block many genuine transactions and have a negative impact on revenue. Conversely, setups that are too lenient may result in too many fraudulent transactions being approved, resulting in chargebacks (and thus lost revenue). 

Classifying Accuracy

Accuracy for any risk system can be quantified using the classification table below. This terminology is used throughout this manual.

True Positive False Positive

This is fraud.

The transaction is correctly blocked.

You blocked fraud.

This is not fraud, but the risk mitigation system thinks it is fraud.

The transaction is blocked, but it shouldn't have.

You miss a legitimate revenue.

True Negative False Negative

This is a genuine transaction.

It passes the fraud mitigation system and is not blocked.

You enabled legitimate revenue.

This is fraud.

The transaction is missed by the risk mitigation system.

You lose revenue on chargebacks.

Balance

An aggressively configured fraud detection system that blocks most fraudulent transactions may result in many false positives, impacting revenue. Conversely, a weak approach to risk mitigation can result in false negatives, which increases your fraud exposure and chargeback costs. As such, it is important to constantly be assessing both false positive and false negatives in order to have a holistic understanding of the effect a merchants risk setup is having on their lost and gained revenue.

How the risk scoring works

While submitting a transaction, a merchant can provide a multitude of required and optional data fields along with that transaction.

It is important to ensure the following:

  • The payment request should contain as many details about the customer as the merchant knows (e.g. name, phone number, IP address, etc.).
  • Data specific to the transaction (e.g. shipping method) is important for identifying fraud trends and should be submitted as well.

The more data a merchant is able to provide, the more effective RevenueProtect can be at mitigating fraud. Fraudsters tend to test many aspects of a merchant's given risk setup and identify data points not being tracked to take advantage of those vulnerabilities.

Risk Engine Scoring

Each transaction assessed by the RevenueProtect engine receives a risk score. The logic works as follows:

  • Each risk rule has a score associated with it. If the risk rule fires for a transaction, that score is added to the aggregate score for the transaction.
  • A rule can have either a negative or positive score associated with it. Negative scores lower the aggregate risk score are good signals.
  • All rules scores are aggregated and the transaction score is calculated. 
  • If the fraud score is 100 or higher, the transaction is refused by Adyen automatically. A score less than 100 is sent for authorization.

RevenueProtect+

Several features of RevenueProtect are a part of the RevenueProtect+ suite. This collection of tools are advanced functionalities suggested for merchants with significant risk exposure and advanced needs in mitigating risk. A breakdown of features included in RevenueProtect+ are:

If you are interesting in enabling RevenueProtect+ features, please reach out to Adyen Support Team

Audience

The content of this manual is primary focused on Risk Managers. Risk Managers are responsible for setting and maintaining the various risk mitigation strategies for a merchant. While this manual goes into some description on the various technical integrations required to utilize RevenueProtect, it is largely focused on describing best practices and implementation advice for merchants looking to mitigation fraud using Adyen's platform. 

Feedback

We strive to provide you with clear, concise, and complete documentation. We are committed to improving it continuously to make it accessible and easy to understand.

We appreciate your comments, and we'd love to hear your voice: drop us a line and share your thoughts with us!

  Adyen Support Team

Risk last update

Version

Date

Changes

4.1.4 2016-09-29 Added new option for Dynamic 3D secure.

Version

Date

Changes

4.1.4 2016-09-29 Added new option for Dynamic 3D secure.
4.1.3 2016-14-07 German SCHUFA Check.
4.1.2 2016-10-06

Updated the configuration options for Shopper name referral list.

4.1.1 2016-08-03

Added Chargeback guideline.

4.1 2016-20-01

Added Fraudulent behaviour on payment page.

4.0 2015-10-12
  • Documentation migration from PDF to web-based online deliverable as main distributable asset.
  • Versioning: version reset and adoption of semantic versioning as per v. 4.0.0.
  • Manual redesign to improve readability, navigation, content search.
1.1 2014-12-02
  • Update payments for manual review.
  • Update risk checks.
1.0 2014-09-14

Initial version.

ShopperDNA

This feature is part of RevenueProtect+. To have RevenueProtect+ features enabled on your account, contact the Adyen Support Team.

What is ShopperDNA?

Many risk mitigation platforms work under the assumption that a transaction is a standalone entity. More advanced systems cluster transactions based on the user's login credentials or credit card number. Fraudsters use a multitude of techniques to circumvent this kind of clusters, usually by using new compromised credit card numbers and changing devices and login identities. 

ShopperDNA builds on this idea of clustering using advanced linking algorithms to track fraudsters even as they change devices, networks, and identities. In this, the shopperDNA clusters a merchant's transactions by the shopperDNA shopper that committed those transactions. This shopper entity is dynamically re-evaluated and can change as the shopperDNA system receives more information about the user's behavior. The power of this system is that it allows the creation of automated rules that monitor the behavior of this shopper, effectively eliminating the ability of fraudsters to hide their behavior across different transactions. 

How Does ShopperDNA Work?

The goal of the ShopperDNA algorithm is to identify and link these transactions that, most likely, are generated by the same shopper. Both fraudsters, and good users.

 

The figure above displays a network of transactions generated by the same shopper. Transactions are shown as squares and the linkable attributes (also called identifiers) are shown as circles. Each linkable attribute (such as an IP address) is continually assessed for its uniqueness and this affects the weight it gives to any given transaction connection. 

The ShopperDNA Algorithm Logic is as: 

  1. All transactions that share attributes with the parents transaction are determined.
  2. The strength of those attributes is tracked (algorithmically based on various uniqueness and temporal signals).
  3. All transactions that mean a dynamic confidence threshold are linked and considered part of the same shopper entity.

Things to Keep In Mind

  • Seemingly high confidence attributes may not be used for linking in some scenarios. For example, when an IP address has been identified as being a shared address or a credit card has been identified as being shared, like in an office setting. 
  • A shopperDNA shopper is always a malleable construct. ShopperDNA networks change over time and should be considered simply another way to track users, in addition to other methods like shopper reference or name.  

How to use ShopperDNA

ShopperDNA can be utilized in two primary ways:

  • Rule Creation: A large subset of rule types are built on top of a shopperDNA logic. These represent the most impactful aspect of shopperDNA, as merchants can largely automate their risk mitigation using these rules.
  • Visualization: The Adyen Customer Area (CA) includes several ways that merchants can view visualizations of shopperDNA networks. These are particularly useful in the context of manual review.

The Oil Splash Visualization

Oil splash is a visualization available in the Adyen Customer Area (CA) which displays a list of attributes contained within the shopperDNA network. 

Key features include:

  • A breakdown of distinct email addresses, credit card numbers, and IP addresses for a shopper.
  • The ability to trace an attribute to the various transactions that used it. This can be done by hovering or clicking the attribute. 
  • A breakdown of payment statuses - refused, disputed, or authorized - for each attribute type. 
  • A table of all transactions in the oil splash, with customizable columns to see payment data.

The below example displays an email address that has utilized five different credit cards to make 21 transactions from one IP address. 

Device Fingerprinting

Device Fingerprinting is a technique by which unique attributes about a shopper's device are logged and analyzed during repeat visits. The goal of fingerprinting is to be able to identify the same machine across multiple sessions, despite the user changing login identities, clearing cache and cookies, and attempting other obfuscation techniques.

This allows the ShopperDNA system to track a user across multiple transactions, despite their user of proxies, giving you a more accurate representation of a fraudsters behavior and allowing for significant automation opportunities on such profiles.

Getting the Device Fingerprint

The device fingerprint is calculated on the client side and needs to be submitted on the server side, you need to include it as a hidden field on a form that you submit to your own server. You can calculate the device fingerprint by calling the dfDo function with the id of the hidden input field as its parameter. 

<html>
  <head>
    <title>Your Website</title>
  </head>
  <body>
<p>Your Checkout page.</p> 
    <script type="text/javascript" src="https://live.adyen.com/hpp/js/df.js?v=20150801"></script>
    <form action="http://www.yourdomain.com/checkout" method="POST">
      <!--
      Your other payment related fields
      -->
      <input type="hidden" name="foo" id="bar" />
      <input type="submit" value="Submit" />
    </form> 
    <script> 
      //<![CDATA[ 
      dfDo("bar");
      //]]> 
    </script>
  </body>
</html>

Browsers typically cache JavaScript files we recommend specifying the current date (YYYYMMDD) to the URL (e.g. https://live.adyen.com/hpp/js/df.js?v=20111130). This ensures you benefit from future updates to the calculation of the device fingerprint. The JavaScript file that calculates the device fingerprint has been minified to reduce loading time.

Note that calculating the device fingerprint takes some time varying based on the shopper's computer speed and internet connection. Because of this it is possible that the hidden text field is not yet filled in when the form is posted to your server. 

Submitting the Device Fingerprint

Using the API

After the device fingerprint is calculated and submitted to your own server you can include it in the SOAP payment request. The calculated value needs to be entered in the deviceFingerprint field. The Adyen Payment System uses this fingerprint for fraud checks on the payment request. 

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance">
   <soap:Body>
      <ns1:authorise xmlns:ns1="http://payment.services.adyen.com">
         <ns1:paymentRequest>
            <amount xmlns="http://payment.services.adyen.com">
               <currency xmlns="http://common.services.adyen.com">EUR</currency>
               <value xmlns="http://common.services.adyen.com">2000</value>
            </amount>
            <card xmlns="http://payment.services.adyen.com">
               <cvc>737</cvc>
               <expiryMonth>08</expiryMonth>
               <expiryYear>2018</expiryYear>
               <holderName>Adyen Test</holderName>
               <number>4111111111111111</number>
            </card>
            <merchantAccount xmlns="http://payment.services.adyen.com">YourMerchant</merchantAccount>
            <reference xmlns="http://payment.services.adyen.com">Your Reference
           Here</reference>
            <shopperEmail xmlns="http://payment.services.adyen.com">s.hopper@test.com</shopperEmail>
            <shopperIP xmlns="http://payment.services.adyen.com">61.294.12.12</shopperIP>
            <shopperReference xmlns="http://payment.services.adyen.com">Simon Hopper</shopperReference>
            <deviceFingerprint xmlns="http://payment.services.adyen.com">m7Cmrf++0cW4P6XfF7m/rA</deviceFingerprint>
         </ns1:paymentRequest>
      </ns1:authorise>
   </soap:Body>
</soap:Envelope>

Using the HPP

After the device fingerprint is calculated and submitted to your own server you can include it in the payment session of the hosted payment page. This is especially useful when you skip the payment method selection page. The calculated value needs to be put in the dfValue field. The payment system uses this fingerprint for fraud checks on the payment request. 

<input type="hidden" name="merchantReference" value="Internet Order 12345" />
<input type="hidden" name="paymentAmount" value="10000" />
<input type="hidden" name="currencyCode" value="GBP" />
<input type="hidden" name="shipBeforeDate" value="2007-10-20" />
<input type="hidden" name="skinCode" value="4aD37dJA" />
<input type="hidden" name="merchantAccount" value="TestMerchant" />
<input type="hidden" name="shopperLocale" value="en_GB" />
<input type="hidden" name="orderData"
value="H4sIAAAAAAAAALMpsOPlCkssyswvLVZIz89PKVZIzEtRKE4tKstMTi3W4+Wy0S+wAwDOGUCXJgAAAA==" />
<input type="hidden" name="sessionValidity" value="2007-10-11T11:00:00Z" />
<input type="hidden" name="merchantSig" value="33syARtfsxD47jeXzOlEyZ0j3pg=" />
<input type="hidden" name="dfValue" value="m7Cmrf++0cW4P6XfF7m/rA" />

Case Management - Manual Review

This feature is part of RevenueProtect+. To have RevenueProtect+ features enabled on your account, contact the Adyen Support Team.

What is Case Management?

In some scenarios, merchants want to manually review a transaction before it is captured. This an optional, yet powerful second layer of enforcement that can go on top of standard risk rule management. 

There are two ways that a transaction can be set aside for manual review:

  1. The transaction reaches the amber threshold that has been established by the merchant.
  2. The transaction triggers a risk check which has an amber override.

The specifics of these setups are explained in the following sections.

Who is Case Management Right For?

Manual review introduces additional operational overhead to a merchant's risk mitigation strategy. It is entirely possible for a merchant to protect themselves against fraud simply by managing the automated risk rules inherent to revenue protect. However, there are some scenarios in which is makes sense to prioritize manual review:

  • High Transaction Value Merchants: Merchants with very high average transaction values (ATVs) have more of an incentive to utilize manual review. For example, airlines and high-end retail merchants find that the monetary loss of even a single chargeback justifies some or significant manual review operational costs. 
  • Merchants Expanding into High-Risk Markets: When a merchant first expands into a high-risk region, it can be useful to prioritize manual reviews. This allows for higher confidence in detecting fraud and enables the risk management team to get a quicker understanding of the fraud in that region. 

Who is Case Management Not For?

There are two scenarios in which manual review does not make significant business sense:

  • Low Transaction Value Merchants: In these cases, the cost associated with manual review often overshadows any potential losses from chargebacks. 
  • Digital Goods Merchants: For merchants who do not sell a physical good, the loss associated with fraud is usually minimal. While the business can potentially loose out on revenue, the product itself has a limited monetary value in-and-of-itself. As such, operationalizing manual reviews is usually not a priority. 

Implementing manual review

Following are the steps to help implement manual overview:

  1. Use the fraudResultType field in the payment response for AMBER status.  AMBER status means the payment was authorized but not auto-captured.  This fraudResultType is included in the AdditionalData of the API response of your authorization request.  Our support can also enable the setting/feature to have this included in your asynchronous notification.
  2. In your system, place the order in a different status to ensure you don’t ship the product. It is recommended that you update this in your ERP.
  3. A user with access to the Case Management UI can now perform the manual review in include  and decide whether to accept or reject this payment.
  4. Define the modification requests you want the manual actions for and the notifications you want Adyen to send to your servers for these decision points:
    1. Accept: Capture or no action
    2. Reject: Cancel_or_Refund or no action
    3. Expiry: Define what modifications you want no action for at the end of 7 days: Cancel_or_Refund or Capture.
  5. Use the asynchronous notifications with event code MANUAL_REVIEW_ACCEPT or MANUAL_REVIEW_REJECT to update the status of the order in your system.

Capture or cancel modifications can be handled by Adyen or you can also choose to handle it yourself. Contact support to know more.

Case management details screen:

Configuration

There are two ways that a transaction can be set aside for manual review:

  1. The transaction reaches the amber threshold that has been established by the merchant.
  2. The transaction triggers a risk check which has an amber override.

Establishing an Amber Threshold

In the revenue protect system, any payment that reaches a risk score of 100 or more is refused. Merchants can also establish an amber threshold. After this score is reached, the transaction is sent for manual review. Note that if the score reaches 100, it is still be refused and not sent for manual review. For example, if a merchant establishes a manual review threshold of 60, the behavior of the account follows this pattern:

Risk Score Result
25 Authorize
60 Manual Review
105 Refuse

The Amber threshold value is established at the merchant account level on the primary risk configuration page. Note that the configuration option is not visible for users that are not opted in to RevenueProtect+. For accessing this feature, contact our support.

Establishing an Amber Override

Each risk rule can have the amber override option enabled. When this option is enabled, the transaction is sent for manual review whenever that rule was triggered. Note that the transaction is still refused if the overall risk score still reaches 100.

A common way to use the amber override is to establish monetary thresholds for manual review by utilizing the Transaction Amount Check. For example, a merchant can always review transactions over $1,000 by establishing that amount in the check and giving the check an amber override.

Manual Review Expiration

Merchants have 7 calendar days to accept or reject a payment after it was selected for manual review. If the review has not been actioned in that 7-day window, the payment is automatically accepted and the funds are captured. These reviews are logged as expired.

Payment Behavior and Notifications

At the time of manual review, the transaction has already been authorized by the issuing bank. From there, the behavior of the case management system then determines if the transaction is to be captured, refunded, or cancelled. 

Notification of Manual Review

Some merchants implement additional logic based on whether or not a transaction is in the manual review. For example, they may delay shipment until the manual review has occurred. The payment request response includes this crucial information in the fraudResultType field. Note that a manual review is indicated with the AMBER status.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance">
   <soap:Body>
      <ns1:authoriseResponse xmlns:ns1="http://payment.services.adyen.com">
         <ns1:paymentResult>
            <additionalData xmlns="http://payment.services.adyen.com">
               <entry>
                  <key xsi:type="xsd:string">fraudResultType</key>
                  <value xsi:type="xsd:string">AMBER</value>
               </entry>
               <additionalData />
               <authCode>85883</authCode>
               <dccAmount xsi:nil="true" />
               <dccSignature xsi:nil="true" />
               <fraudResult>
                  <accountScore>0</accountScore>
                  <results>
                     <FraudCheckResult>
                        <accountScore>0</accountScore>
                        <checkId>7</checkId>
                        <name>ShopperIpUsage</name>
                     </FraudCheckResult>
                     <FraudCheckResult>
                        <accountScore>0</accountScore>
                        <checkId>8</checkId>
                        <name>ShopperEmailUsage</name>
                     </FraudCheckResult>
                  </results>
               </fraudResult>
            </additionalData>
            <issuerUrl xmlns="http://payment.services.adyen.com" xsi:nil="true" />
            <md xmlns="http://payment.services.adyen.com" xsi:nil="true" />
            <paRequest xmlns="http://payment.services.adyen.com" xsi:nil="true" />
            <pspReference xmlns="http://payment.services.adyen.com">9914169226820173</pspReference>
            <refusalReason xmlns="http://payment.services.adyen.com" xsi:nil="true" />
            <resultCode xmlns="http://payment.services.adyen.com">Authorised</resultCode>
         </ns1:paymentResult>
      </ns1:authoriseResponse>
   </soap:Body>
</soap:Envelope>

Modifications

Merchants can decide what action takes place to the payment after it has expired or has been accepted/rejected by the manual reviewer. Note that these configurations are implemented by Adyen support based on the merchant's needed behavior.

  • Manual Review has been accepted:

    • CAPTURE: The payment is captured.

    • None: No modification is performed to the payment. 

  • Manual Review has been rejected:

    • CANCEL_OR_REFUND: The payment is cancelled or refunded (whichever is appropriate for the payment method).

    • None: No modification is performed to the payment.

  •  Manual Review has expired:

    • CAPTURE: The payment is captured.

    • CANCEL_OR_REFUND: The payment is cancelled or refunded (whichever is appropriate for the payment method).

    • None: No notification is performed to the payment.

Notifications

Merchants can receive notification when a payment has been accepted, rejected or expired in the Case Management system. This is important because most merchants wish to have additional logic to process such rejections. For example, they may send a notification to their warehouse to not ship the goods in question. In the case of digital goods, they may choose to have the user's account disabled upon notification of a manual review rejection. 

  • Manual Review has been accepted:
    • ACCEPT_NOTIFICATION. Adyen sends an ACCEPT notification to the merchant when an agent has selected to approve the manual review.
    • None: No notification is sent.
  • Manual Review has been rejected:
    • REJECT_NOTIFICATION. Adyen sends a REJECT notification to the Merchant when an agent has selected to reject a transaction in the manual review.

    • None: No notification is sent.

  • Manual Review has expired:

    • ACCEPT_NOTIFICATION. Adyen sends an ACCEPT notification to the merchant when the review has expired and the account was configured to accept upon expiration. 

    • REJECT_NOTIFICATION. Adyen sends a REJECT notification to the merchant when the review has expired and the account was configured to reject upon expiration. 

    • None: No notification is sent. 

An example SOAP notification indicating the result of the manual Review. Note the 'MANUAL_REVIEW_ACCEPT' eventCode.

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance">
   <soap:Body>
      <ns1:sendNotification xmlns:ns1="http://notification.services.adyen.com">
         <ns1:notification>
            <live xmlns="http://notification.services.adyen.com">false</live>
            <notificationItems xmlns="http://notification.services.adyen.com">
               <notificationRequestItem>
                  <additionalData xsi:nil="true" />
                  <amount>
                     <currency xmlns="http://common.services.adyen.com">EUR</currency>
                     <value xmlns="http://common.services.adyen.com">1700</value>
                  </amount>
                  <eventCode>MANUAL_REVIEW_ACCEPT</eventCode>
                  <eventDate>2014-10-22T16:33:27.787+02:00</eventDate>
                  <merchantAccountCode>TestMerchant</merchantAccountCode>
                  <merchantReference>TMRef1234</merchantReference>
                  <operations xsi:nil="true" />
                  <originalReference>9914135462408734</originalReference>
                  <paymentMethod>visa</paymentMethod>
                  <pspReference>9914135462569048</pspReference>
                  <reason>accept</reason>
                  <success>true</success>
               </notificationRequestItem>
            </notificationItems>
         </ns1:notification>
      </ns1:sendNotification>
   </soap:Body>
</soap:Envelope>


User Permissions for Manual Review

In order access the case management section of the Adyen Customer Area (CA), a user must have the appropriate role added. To add the manual review role to an existing user:

  1. In the Settings section select Users.
  2. Select the user to be modified.
  3. In the Roles list, enable the Merchant Manual Review Role.

Reviewing Payments

Accessing The Manual Review Queue

The manual review queue is available through the Adyen Customer Area (CA).   In the Primary menu, click Manual Review.

It has the following features:

  • The ability to customize column configurations.
  • CSV download of transactions currently enqueued for review.
  • Queue filtering. 
  • Quick-actioning via the queue.

Assigning Reviews

When multiple agents are reviewing transactions it is important for agents to assign reviews to themselves, so as to avoid agents duplicating effort. A user can self-assigned a review by selecting the magnifying glass in the Actions column. After being assigned, that review is available in the Under Investigation tab. It is possible to see which agent a transaction is assigned to by viewing the User Name column in the queue configuration.

Actioning on Reviews

Reviews can be actioned in two ways:

The Quick-Action Widget: Reviews can be approved or denied directly from the queue with the quick-action widget. 

The Actioning Widget: The manual review interface has a widget devoted to passing an action on the review.

Changing the Decision on Past Reviews

After a manual review has been submitted, there are no other actions available to change the result of the review (for example, if the review was rejected and the transaction was canceled. That is a permanent decision and cannot be reversed. However, it is still important to document the proper status for a manual review in case future transactions for that shopper are enqueued.

The actioning widget gives merchants the possibility to tag all their payments under manual review for future reference. This can be done by setting up the field Manual Status that can be found under the Payment Details view. The manual status has two values Fraud and Genuine.

These can be referenced later during future reviews.

The Manual Review Interface

There are several sections in the Manual Review Interface, each with a unique function allowing agents to manually review transactions.

Actioning Widget

The Actioning Widget is where the agent takes action on the review. It has the following functions:

  • Accept the payment by clicking the check icon. After this, the Adyen platform performs a capture on the payment.

  • Rejecting the payment by clicking the X icon. After this, the Adyen platform cancels the transaction.

  • Flag the payment for further investigation by clicking the magnifier glass icon. A payment that is flagged for investigation is moved to the Under Investigation tab.

  • Add notes to the review for referencing later.

  • Information on what score or rule resulted in the transaction is being isolated for manual review.

Fraud Control Widget

The primary function of the fraud control widget is to allow the agent to add various user attributes from the transaction to Block and Trust lists. This allows for agents to quickly ensure that this customer is either trusted or automatically blocked in the future. This is particularly important in reducing friction for known, good shoppers. 

The following attributes can be added or removed from this widget:

  • Card/Bank Account Number
  • Shopper Email Address
  • Shopper IP Address
  • Card Holder Name
  • Passenger Name (airline specific)

There are other Block and Trust list types (ex. Paypal ID) that are not accessible via this widget, but are accessible via the primary risk configuration menu in the Adyen Customer Area (CA).

Payment Details Widget

The payment details widget gives a breakdown of key information about the transaction and the payment instrument used. Some key features to call out:

  • Links to search shopper reference, emails, and IP addresses across other payments. 
  • 3D Secure results, including a liability shift indicator. 
  • A link to the ShopperDNA for the shopper.

Scoring Widget

The scoring widget provides a breakdown of all the risk checks that triggered resulting in the transaction being set aside for review.

 

Vertical-Specific Data Widget

The vertical specific data widget displays data that is usually only required for certain businesses. For example, airlines may submit additional flight information associated with the transaction and e-commerce websites may include the payment and shipping address. 

Airline Specific Data

E-Commerce Address Data

ShopperDNA 'Oil Splash'

The Oil Splash is a visualization of the shopperDNA network associated with the transaction. This visualization is useful in provided a quick glimpse at the transaction history for the shopper. The full view of the shopperDNA is available via a link. 

Dynamic 3D Secure

What is 3D Secure?

3D Secure is a platform provided by the credit card schemes which allows you to implement another layer of security on your Card-Not-Present transactions. During a 3D Secure transaction, the shopper is redirected to a site controlled by the issuing bank of the card to answer additional security questions - usually a unique password or SMS verification. This further reduces the chance that a fraudulent transaction can occur.

There is an automatic chargeback liability shift to the issuing banks for personal cards once 3D Secure has been initiated by a merchant for a transaction.

While the liability shift with 3D Secure is appealing, there is a significant risk to lowering your conversion rate during 3D Secure. Many customers are still not familiar with 3D Secure and may not successfully pass verification. Further, client-side technical errors may occur with the redirect.

In order to mitigate any effects on conversion, Adyen has developed a robust dynamic 3D secure system where merchants can optimize which transactions they send to 3D secure while letting most trusted transactions through without 3D Secure. 

This functionality is not enabled by default, as it requires additional configuration on Adyen's end. Contact the  Adyen Support Team to request enabling it for you.

Dynamic 3D secure criteria

The following criteria can be used to configure dynamic 3D secure rules. Different criterium can be combined to create nested rules. For example, a merchant may decide to only use 3D Secure when the transaction is an issuing card from Mexico, with a risk score above, 70, and a transaction value above $100. 

Criteria

Description

Issuer country

The country that the card is issued out of.

Shopper Country

The country of the shopper, based on the IP address submitted with the payment.

Payment Method

The payment method type for the transaction (ex. Amex, Visa Platinum, etc.)

Device Type

You can indicate mobile vs. desktop transactions. The transaction must have device data submitted with it for this feature to work.  

Amount

Allows for the configuration of rules based on transaction value in multiple currencies. The rule will automatically convert currencies. For example, a 20 Euro rule would trigger on the equivalent amount in GBP automatically.

Risk Score

Allows the targeting of 3D Secure for only transactions that meet certain risk score thresholds.

Note: If a transaction's risk score is 100 or more, it is always rejected by RevenueProtect and, thus, will not use 3D Secure.

BIN and BIN Range

Merchants can target sets of BINs or BIN Ranges to use 3D Secure only for transactions from certain issuing banks.

BIN Group Allows you to select a BIN Group from the pre defined list of groups. These BIN groups are predefined by Adyen specifically for 3DS usage.

Configuring Dynamic 3D secure rules

The Dynamic 3D Secure rules engine allows for the creation of unlimited stack-ranked rules, through which you can manage whether or not a 3D secure enabled transactions goes through 3D Secure.

A few things to keep in mind about the rules Engine:

  • All rules are maintained at the Merchant Account level and effect transactions in that account.

  • Some generic rules may be system wide and thus trump rules in the Dynamic 3DS Engine, such as the mandate that all Maestro payments use 3D Secure.

  • Rules trigger from first to last - if any rule triggers, it follows the configured option for that rule to either use or not to use 3D Secure.

  • If no rules trigger, the 3D Secure enabled transaction uses 3D Secure.

A few tips on creating rules:

  • Wherever possible, create several simple rules as opposed to combining many logic points into a single rule.

  • The sub-components of the rules always comprise an AND statement. If you want to use OR statements, you need to create a new rule.

  • The default option that you choose (to use or not to use 3D secure) should always be the last option. This way the system first checks the all the previous rule that you may have created abd then goes on to the default rule.

Rule configuration Examples

Scenario 1:

You experiencing significant fraud in transactions above $200 in the U.S. and €250 in Germany. You decide to focus on high-risk transactions in these regions but not use 3D Secure for other trustworthy transactions.

Rules you should set up:

  1. ALWAYS use 3D Secure when transaction >= $200 AND risk score >50 AND issuing country = United States

  2. ALWAYS use 3D Secure when transaction >= €250 AND risk score >50 AND issuing country = Germany

  3. NEVER use 3D Secure

The use of a NEVER rule should always be the last rule. This rule catches any scenarios that don’t match rule 1 and 2 and not use 3D Secure.

Scenario 2: 

You are planning expanding your business in the United States. You have previously used 3D Secure in the U.K. where conversion rates are high and want to avoid using 3D Secure in the United States. All your traffic is from U.K. and U.S.

Rules you should set up:

  1. NEVER use 3D Secure when issuing country = United States

Only a NEVER rule is needed since the default action is for transactions to use 3D Secure. With this setup all U.K. transactions would use 3D Secure. If you want to be more explicit, you can create an ALWAYS rule for U.K.

RevenueProtect engine rules

The engine has numerous rules available for configuration. There are several classes of rules that are assessed at the time of a transaction.

Rule Class Description Example Rule
ShopperDNA Rules These rules are calculated over the ShopperDNA network associated with a transaction. ShopperDNA allows merchants to track fraudsters across devices and networks and created rules on that entire network of transactions. Shopper Has a Previous Chargeback
Referral Lists These are lists of known good and bad shopper attributes (e.g. card numbers). Merchants can use these lists to ensure that loyal customers are unaffected and that known fraudsters are no longer able to attempt transactions. Shopper Email Referral List
Consistency Rules These are rules that look for known fraudulent trends in the customer behavior or data. Shopper Using Anonymous Proxy
Velocity Rules Velocity rules allow merchants to set specific thresholds on how often a shopper can attempt transactions in a given time period. Shopper Email Usage Frequency
External Risk Checks Plugins to various third-party risk mitigation systems that allow them to be used in coordination with RevenueProtect. Perseuss Airline Check

Each of these rules is highly customizable. This section of the manual will break down a description of each rule and the various configuration options therein. 

Configuring Rules

The engine rules are configured at the merchant account level. Depending on a merchant's fraud exposure, they may configure significantly different risk mitigation rules for each account. Generally speaking, merchants tend to isolate low-risk transactions from high-risk, enabling differentiated risk configurations for each profile.

Remember that transactions are blocked when their score reaches 100.

Note the following about the risk configuration setup:

  • Each rule has a score threshold associated with it. This is the score that adds to the aggregate transaction score if the rule triggers.

  • Many rules need additional configuration. Click the pencil icon to configure the rule-specific settings for that rule. 
  • Inactive checks are not displayed by default. Click Show inactive checks to see rules that have been de-activated. 

Risk Engine Rule Management

Optimiser

This feature is part of RevenueProtect+. To have RevenueProtect+ features enabled on your account, contact the Adyen Support Team.

One of the biggest risks for a risk manager is making significant changes to fraud settings and possibly introducing large numbers of false positives or negatives into their screening. The Optimiser allows merchants to experiment with risk settings in a what-if manner, so they can understand the effect that a set of changes will make on their action rates.

Based on a subset of past transactions and historical data, the risk optimiser can breakdown which check has been triggered most often and what the effect of each check's score has been on the total score. Further, it can provide predictive statistics on pending changes and give suggested risk profiles to improve action rate.

The risk optimiser is accessible through Adyen Customer Area (CA) in the Reports section, and via the risk configuration page. Note that only Risk Admins can access the Optimiser, so Risk Manager should check with their Adyen admin if they don't have the necessary role.

The Optimiser uses chargeback data to calculate its results. If your acquiring configuration does not result in chargebacks being displayed in the Adyen Customer Area (CA), you should not utilise the Risk Engine Optimiser until you have uploaded your chargebacks with the Chargeback Uploader.

 

The image below shows an example of a simulated scenario that the Risk Engine Optimiser determined. In this visualisation, merchants can review a simulation of the expected outcome in chargebacks and false positives after the proposed change. In this example, 127 chargeback transactions could have been rejected, saving more than 96,000 Euros to the merchant. Also, the proposed settings could have resulted in 9 less false positives, preventing over 1,900 Euros in lost revenue. Thus, this set of changes is very positive, resulting in over 98,000 Euros in additional revenue.

There are two ways to use the Optimiser:

  1. Manual configuration: The Merchant proposes specific changes to various rules and the Risk Engine Optimiser computes the expected results.

  2. Automatic configuration: The merchant indicates a preference of lower chargeback rate vs. allowing fewer false positives and the Optimiser computes a set of risk configurations and displays the expected performance.

Manual Configuration

Manual Configuration is for merchants who wish to test tweaks to their settings and predict the expected outcome of the selected settings. The outcome display shown below is a table of the active risk checks on the account. Each column gives important information about the sample being used to calculate the outcome:

  • Triggered: The percentage of transactions in the sample that this risk check triggered on. 

  • Chargebacks: The percentage of chargebacks of the total number of accepted transactions that triggered the risk check.

  • Refusals: The percentage of transactions that were refused of the total number of transactions that triggered the risk check.

After the merchant has finished adjusting the risk scores of the risk checks by filling out the New Score column, they can request the Optimiser to simulate these new values on past transactions. To perform this action click Calculate Expected Results, the final results are displayed in the panel show above.

Automatic Configuration

Manual configuration can be time-consuming for the merchant, in particular when complex calculations are required to predict the expected outcome of changes. For this reason, Adyen has developed a machine-learning algorithms that can decide which risk checks should changed and what their new risk scores should be.

To be presented with an automatic configuration, select a position on the Proposed Risk Configurations scale. Based on these preferences, ranging in aggressiveness, the table is populated with a set of risk settings. Note that the number of options on the configuration slider are dynamic, based on the number of configurations the model is able to produce. The number of available configurations can very from none to many. 

ShopperDNA Rules

This feature is part of RevenueProtect+. To have RevenueProtect+ features enabled on your account, contact the Adyen Support Team.

ShopperDNA is a game-changing approach to linking transactions across sessions. Using advanced linking algorithms, ShopperDNA trackers users across networks, devices, and online identities and ties their transactions into a single ShopperDNA profile. By using this technology, RevenueProtect builds profiles of both good and bad shoppers, aggregating their  behaviour across Adyen's network. ShopperDNA rules are risk checks that use this concept of a shopper to track behaviour and velocities. As such, these rules are dynamic and can continue to be effective even as fraudsters attempt to circumvent detection.

An abandonment of the shopper after redirecting to a payment method or 3D Secure is counted as an attempt and adds to the count for ShopperDNA Rules. Not all of these abandoned attempts can be found in the payment list since this list only contains authorized and refused payments.

Authorised Transaction Amount Velocity Check

This risk check fires when the total transaction volume of a shopperDNA Shopper exceeds a set threshold in a configured timeframe. It allows merchants to set caps on what they expect good customers to spend in a given period and identifying outliers that may be committing fraud.

Most merchants understand the average transaction values for most of their transactions. Often fraudulent transactions are significantly higher than the average amount, making it easy to identify at-risk transactions. This check is focused on being able to identify such high-risk transactions. 


Configuration Options

  • Merchants can establish various amount thresholds with individual scores for each. A single timeframe is established for the check.

  • The risk check fires on any transaction that results in the configured threshold being met. 

  • If multiple amounts meet the criteria for the check, the one with the highest score triggers. 

Different Countries used by Shopper

This risk check fires when the number of countries a shopper has used in the configured timeframe has been met.

Note that in some verticals it is much more common for good shoppers to have a diverse country footprint - this is particularly common in the travel industry. Merchants should take note of this and configure this rule accordingly.

Fraudsters often use randomized proxies to commit fraud. As such, their fraud profile often spans multiple regions in a short period of time. Further, fraudsters tend to use cards not associated with the country they are in at time of transaction, further increasing their country diversity footprint. This check is aimed at identifying users whose geographic diversity fits the profile of a fraudsters. 

Countries are recorded based on both the issuing country of their payment method, as well as the IP address at time of transaction.

Configuration Options

  • Merchants can establish a threshold for both the number of countries and the timeframe allowed. The default is 2 times over 30 days.
  • The risk fires on the transaction after the set threshold. So, if you set a threshold of 2 in 30 days, it fires on the 3rd country recorded in that 30 days. 

Issuer Blocked (Previous) Card Used by Shopper

This feature is part of RevenueProtect+. To have RevenueProtect+ features enabled on your account, contact the Adyen Support Team.

This risk check fires when the shopper has previously had a transaction that got a blocked card response from the issuing bank.

Issuing Banks refuse transactions for a multitude of reasons, varying in correlation with fraud. Blocked card refusals usually indicate that the card has been canceled due to fraud and, as such, this can be used as a significant signal indicating a likely fraudulent user. 

Configuration Options

This risk check requires no additional configuration. 

Loyal Shopper Trust Check

This risk check fires when the ShopperDNA Shopper fits the established profile of a 'loyal shopper,' as determined by the configuration options. Shoppers with fraud-related chargebacks will never be considered loyal, whereas other elements (such as non-fraud chargebacks and risk refusals) can be configured.

Different merchants have different definitions of a loyal shopper. Regardless, identifying who your best customers are is one of the easiest ways to reduce frictions and false positives on your most profitable customers. 

Note that for this check to work properly, Adyen must have visibility to the merchant's chargebacks. Depending on the type of acquiring integration, this can be variable. Note that chargeback uploader can be used in scenarios where Adyen does not receive chargeback data for transactions. This allows this risk check to have visibility on fraud incidences.

Configuration Options

There are several configuration options for this check:

  • Minimum Number of Days: This established the minimum number of days that the rule will assess to determine their loyalty.
  • Do Not Allow Risk Refusals: When this option is checked, having risk refusals will negate the user from being considered loyal.
  • Do Not Allow non-Fraud related chargebacks: When this option is checked, non-fraud chargebacks negates the user from being considered loyal. Note that fraud-related chargebacks will always remove a shopper from being loyal.

Multiple Distinct Cards/Bank Accounts Used by Shopper

This risk check fires when the number of payment methods a ShopperDNA Shopper has used in the configured timeframe exceeds the specified threshold.

The primary approach to most payment fraudsters is to attempt payment with as many compromised payment methods as possible. As such, fraudsters have a large diversity of unique payment methods associated with their shopper profile. This check is aimed at identifying users whose payment method diversity fits the profile of a fraudster. 

This risk check should be configured based on a merchant's unique fraudster profile. Different verticals and business models have a wide diversity of expectations on how many payment methods a legitimate user may use; this trend also varies significantly by region. For example In the United States, it is common for consumers to have 3 or more credit cards. Merchant's should take care to analyze their fraudster and good-customer profiles in order to understand where to best configure this rule.

Configuration Options

  • Merchants can establish a threshold for both the number of unique payment methods and the timeframe allowed. The default is 2 times over 30 days.

  • The risk check fires on the transaction after the set threshold. So, if a merchant sets a threshold of 2 in 30 days, it fires on the 3rd payment methods recorded in that 30 day period. 

Multiple Distinct Email Addresses Used by Shopper

This risk check fires when the number of email addresses a ShopperDNA Shopper has used in the configured timeframe exceeds the specified threshold.

It is common practice for fraudsters to cycle through lists of email addresses in an attempt to appear to be separate, legitimate users. This check is aimed at identifying users whose email address diversity fits the profile of a fraudster. 

Configuration Options

  • Merchants can establish a threshold for both the number of unique email addresses and the timeframe allowed. The default is 3 times over 3 days.

  • The risk check fires on the transaction after the set threshold. So, if a merchant sets a threshold of 3 in 30 days, it fires on the 4th email address recorded in that 30-day period. 


Multiple Distinct IP Addresses Used by Shopper

This risk check fires when the number of distinct IP addresses a shopper has been used in the configured timeframe exceeds the configured threshold.

Fraudsters often use randomize proxies to commit fraud. Their fraud profile often spans multiple IP addresses. This check is aimed at identifying users whose IP address diversity fits the profile of a fraudster. 

Adyen dynamically determines if an IP address is a shared IP address and does not include these in the rule calculation. This is to reduce the effect that using networks such as WiFi hotspots has on good users' scores. The shared IP address check allows merchants to flag for the use of these shared IP addresses if needed.

Configuration Options

  • Merchants can establish a threshold for both the number of unique IP addresses and the timeframe allowed. The default is 2 times over 3 days.
  • The risk check fires on the transaction after the set threshold. So, if a merchant sets a threshold of 2 in 3 days, it fires on the 3rd IP address recorded in that 3-day period (not counting shared IPs). 


Multiple Distinct Shopper References Used by Shopper

This risk check fires when the number of shopper references a shopper has used in the configured timeframe exceeds the specified threshold.

The shopper reference is a unique identifier for a shopper that a merchant provides in the payment request. This is most commonly the unique User ID associated with the user's login alias. 

It is common practice for fraudsters to use multiple account logins in an attempt to appear separate, and legitimate users - this includes creating new accounts, utilizing account takeover attack vectors. This check is aimed at identifying users whose Shopper Reference diversity fits the profile of a fraudster. 

For this risk check to work properly, it is imperative that merchant's ensure that there is parity between their internal reference numbers/ID associated with a unique user and what they are passing to Adyen via the shopperReference field.

Configuration Options

  • Merchants can establish a threshold for both the number of unique email addresses and the timeframe allowed. The default is 2 times over 30 days.

  • The risk check fires on the transaction after the set threshold. So, if a merchant sets a threshold of 2 in 30 days, it fires on the 3rd shopper reference recorded in that 30 day period. 

Shopper Authorized Velocity

This risk check fires when the number of payment authorizations a shopper has used in the configured timeframe exceeds the specified threshold.

A core practice for most fraudsters is to try many attempts at payments. While rules around refusal velocity are a stronger signal of fraud, it can also be useful to track users who are successfully authorization payments in high velocity. This can indicate a fraud attack that is being undetected by the Issuing banks. This check is aimed at identifying users whose rate of authorizations fits the profile of a fraudster. 

It is important to note that there is a wide diversity of expected authorizations per merchants, based on their business model and vertical. For example, airlines can expect significantly less velocity than businesses based on micro-transactions.

Configuration Options

  • Merchants can establish a threshold for both the number of authorized transactions and the timeframe allowed. The default is 3 times over 7 days.

  • The risk check fires on the authorized transactions after the set threshold. So, if a merchant sets a threshold of 3 in 7 days, it fires on the 4th authorization recorded in that 30-day period. 

Shopper Automated Referral Check

This risk check fires when a shopper has committed fraud anywhere on Adyen's network, including with other merchants. The threshold by which a shopper is put into this category includes the diversity of payment methods they have entered, as well as their Issuer responses.

ShopperDNA is tracked across all of Adyen's network, allowing aggregation of both good and bad signals across verticals. With this check, it is possible that a fraudster may have committed fraud with another merchant and the check triggers on their first interaction with a new property. While the check cannot be transparent about the source of the fraud, it is nonetheless extremely powerful in being able to predict fraud on even a first-time interaction.

Shopper Consecutive Refusals Check

This risk check fires when the number of payment refusals a ShopperDNA Shopper has used in the configured timeframe exceeds the specified threshold.

A core practice for most fraudsters is to try many attempts at payments. Many refusals in a row can indicate a fraud attack that is being detected by the issuing bank, but not blocked by the merchant. This check is aimed at identifying users whose rate of refusals fits the profile of a fraudster. 

Configuration Options

  • Merchants can establish a threshold for both the number of refused transactions and the timeframe allowed. The default is 3 times over 7 days.

  • The risk check fired on the refused transactions after the set threshold (assuming that all the refusals occur consecutively with no authorizations breaking the chain). So, if a merchant sets a threshold of 3 in 7 days, it fires on the 4th consecutive refusal recorded in that 30-day period. 


Shopper Has a Previous Chargeback

This risk check fires when the shopper has a fraud-related chargeback in the past.

For this check to work properly, Adyen must have visibility to the merchant's chargebacks. Depending on the type of acquiring integration, this can be variable.

Note that chargeback uploader can be used in scenarios where Adyen does not receive the chargeback data. This allows this risk check to have visibility on those fraud incidences.

Configuration Options

No additional configuration options are required for this check. 

Shopper Used Shared Card/Bank Account

This risk check fires when a shopper uses a known shared payment instrument. These can indicate users utilizing compromised card numbers, which have been widely circulated amongst fraudsters.

The legitimate environments can also meet the threshold for shared card/bank account, most importantly office environments where the same card can be used across many users. For a payment instrument to be considered shared 6 or more unique users should have utilized it.

Configuration Options

No additional configuration options are required for this check.

Shopper Used Shared IP Address

This risk check fires when the shopper uses a known shared IP address. These can indicate users utilizing proxies and WiFi hotspots, which tend to correlate with fraud.

The legitimate environments can also meet the threshold for shared IP address, most importantly offices, hotels, and apartments with certain network configurations. For a payment instrument to be considered shared 6 or more unique users should have utilized it.

Configuration Options

 

No additional configuration options are required for this check. 

Referral Rules

Referral checks allow merchants to establish block and trust lists of both good and bad attributes, affecting the risk score based on a known trend on many different shopper attributes. 

Merchants should avoid using referral lists as true block and trust lists. No shopper should be trusted, or blocked based on one list or rule, rather these lists should affect the score significant but work with other checks to either clear or block that transactions. The threshold score of each risk check is configurable, and weighting is possible.

Note that all referral lists function at the company level. While a merchant must go to the merchant account level to change risk rules, all referral lists are aggregated at the company level, so any particular value only needs to be provided once to apply to all merchant accounts.

Airline Data Leg Check

This referral list allows the merchant to make, block, and trust lists based on the legs being flown on an itinerary. Note that the use of this check requires submission of airline-specific data in the payment request.

Configuration Options

  • Merchants are able to submit legs individually, utilizing the IATA format. 
  • Each leg can be given a specific scoring, negative to give it a trust value and positive to give it a block value.
  • Each leg must be quantified explicitly. For example, if a merchant established a rule for AMS to JFK. A separate rule would also need to be created for JFK to AMS.

Bank Account Number Non-Fraud Referral List

This referral list contains all ELV and Bank Account bank account numbers which had been used in chargeback transactions where the chargeback had a non-fraudulent reason (ex. Insufficient Funds). This is a global list across Adyen's entire network.

Friendly fraud is when good shoppers use their own bank account, but chargeback even when their goods have been delivered. These fraudsters range from one-time offenders who may have been unhappy with their product to consistent abusers of their ability to chargeback on legitimate transactions.  This risk check is focused on finding friendly fraudsters and highlighting that they have committed chargebacks on Adyen's network in the past.

Business Hours to Delivery

This referral list allows the merchant to make block and trust lists based on how close the transaction is to the delivery date (as measured in business hours). This can be used by airlines to calculate how far the transaction is to the takeoff time or by e-commerce merchants to correlate with express shipping.

The merchants must provide the delivery time value in the payment request.

This risk check is is based on the configured business hours and is similar to time to delivery check. This allows merchants in manual reviews to quantify risk based on the availability of their operations team to review the transaction. 

Configuration Options

  • Merchants must indicate active hours during the day. 
  • Merchants are able to submit thresholds in a day, hour, or minute format. 
  • Each value can be given a specific scoring, negative to give it a trust value and positive to give it a block value.
  • In situations in which two different values match, the one with the highest score triggers.

Card/Bank Account Number Referral List

This referral list allows the merchant to make block and trust lists based on bank and card numbers.

Configuration Options

  • Merchants are able to submit credit card numbers, SEPA Direct-Debit numbers, and ELV numbers. 
  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • The score associated with the trust list is established as a sub-setting. 
  • Payment instruments can be added in the configuration settings. Merchants can also check if a value is in either referral list. 

Carte Bancaire Scheme Blocked Cards Referral List

Adyen received up-to-date lists of cards that have been blocked by Carte Bancaire, a local scheme available in France. This allows merchants to block the transaction prior to sending an authorization request.

Email Domain Referral List

This referral list allows the merchant to make block and trust lists based on the domain of the provided shopper email address.

The merchant must be submitting a shopper email value in the payment request for this check to perform correctly.

It is common for fraudsters to use certain domains which allow them to create many email addresses at a time. This check can be used to combat that, as well as to trust very high trust domains.

Configuration Options

  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • The score associated with the trust list is established as a sub-setting.

Issuer referral list

This referral list allows the merchant to make block and trust lists based on the issuing bank of the card or bank account number.

Configuration Options

  • Merchants are able to submit credit card numbers and ELV numbers. 
  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • The score associated with the trust list is established as a sub-setting. 
  • A minimum of four digits is required for cards, however, more can be accepted to narrow to a specific BIN range. 

Issuing Country referral list

 

This referral list allows the merchant to make block lists based on issuing country of the card.

Configuration Options

  • Merchants are able to submit countries individually.
  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • There is currently no ability to create a trust list for countries. 

Payment Method Check

This check can be used to apply higher or lower risk scores to transactions based on the payment method used.

Some payment methods have higher or lower correlations with fraud. This check allows merchants to affect the risk score based on the payment method behavior that have noted with their fraudsters and good users. 

Configuration Options

  • Merchants are able to submit scores for any of their configured payment methods (note that payment methods not currently being used are not on the list).
  • Both positive and negative values can be added accordingly. For example, in the example below Paypal payments receive a score of -50, lowering the fraud score. 

Paypal ID Referral List

This referral list allows the merchant to make block and trust lists based on the domain of the provided shopper Paypal ID.

The merchant should submit a Paypal ID value in the payment request for this check to work properly.

Configuration Options

  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • The score associated with the trust list is established as a sub-setting.

Persistent Cookie referral list

This referral list allows the merchant to make block and trust lists based on the specific persistent cookie of the shopper. Note that the merchant must be submitting a cookie value in the payment request for this check to work properly.

Configuration Options

  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • The score associated with the trust list is established as a sub-setting.

Note that the provided value must be an exact match of the cookie string contained in the payment request.

Phone Number Referral List

This referral list allows the merchant to make block and trust lists based on the domain of the provided shopper phone number.

The merchant must be submitting a shopper phone number value in the payment request for this check to work properly.

Configuration Options

  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • The score associated with the trust list is established as a sub-setting.

Shopper Account Age Check

This check increases or decreases the fraud score depending on shopper account creation date. The shopper age can either be provided as part of the payment request (via the API) or the check can use the oldest transaction within the shopper’s ShopperDNA network.

RevenueProtect+ must be enabled to use the ShopperDNA age. 

Configuration Options:

  • There are three different configuration types for this check:
    • Use merchant-provided creation date: This uses the creation date provided as part of the transaction request. See risk fields for more information. 
    • Use the date of the oldest ShopperDNA transaction: This uses the timestamp of the oldest transaction in the ShopperDNA network of the shopper. Note that this requires the use of ShopperDNA, which is part of RevenueProtect+.
    • Use the oldest of the two: This uses the oldest of the two above, when applicable. 
  • Merchants can establish thresholds of age in days, hours, and minutes. Both positive and negative scores can be provided. 

Shopper Address referral list

This referral list allows the merchant to make block and trust lists based on the specific address of the shopper, either shipping or billing. The Shopper Address must have an exact match on the country, postal code and house number, so it is imperative that these fields are properly submitted in the payment request.

Configuration Options

  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • The score associated with the trust list is established as a sub-setting. 
  • A score can be provided for partial matches in which not all three elements of the address match. 
  • Email addresses can also be provided via CSV upload (max 1,000 per upload). The CSV should have the following six columns (with no header):
    • street 
    • house number
    • city
    • postal code
    • state 
    • country code (two letters)
  • The wildcard (<all>) can be supplied for a field to accept any value in that field. For example, '<all> <all>, 91234 <all>, <all>, FRANCE'  triggers on any address in France with the postal code 91234.

Shopper Email referral list

This referral list allows the merchant to make block and trust lists based on the specific email address of the shopper. Note that these emails must be an exact match or utilize a wildcard.

Configuration Options

  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • The score associated with the trust list is established as a sub-setting. 
  • Email addresses can also be provided via CSV upload (max 1,000 per upload). 
  • Wildcards (* and ?) can be used to simplify matching. For example by using test*, you will block names like 'test user'. 

Shopper IP originates from high-risk country

This referral list allows the merchant to make block lists based on the shopper's IP country. This check comes with some countries included by default (ex. Nigeria).

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

Configuration Options

  • Merchants are able to submit countries individually.
  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • There is currently no ability to create a trust list for countries. 

Shopper IP referral list

This referral list allows the merchant to make block and trust lists based on the specific IP address of the shopper.

Configuration Options

  • Merchants are able to submit IP addresses in either v4 or v6 format.
  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • The score associated with the trust list is established as a sub-setting. 
  • IP addresses can also be provided via CSV upload (max 1,000 per upload). 

Shopper Name referral list

This referral list allows the merchant to make block and trust lists based on the specific name of the shopper. Note that these names must be an exact match or utilize wildcards, although the check is case sensitive. This check analyses both the card holder name field and the passenger name field (if provided).

Configuration Options

  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • The score associated with the trust list is established as a sub-setting. 
  • Names can also be provided via CSV upload (max 1,000 per upload). 

Shopper Reference Referral List

This referral list allows the merchant to make block and trust lists based on the specific Shopper Reference of the shopper. Note that the merchant must be submitting a shopper reference value in the payment request for this check to work properly.

The shopper reference is a unique identifier for a shopper, usually associated with their login identity. This allows the tracking of users across multiple sessions. It is common practice to establish a unique shopper reference for each guest transaction when the transactions are allowed without logging in.

Configuration Options

  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • The score associated with the trust list is established as a sub-setting.

The provided value must be an exact match of the shopper reference string contained in the payment request.

Social Security Number Referral List

This referral list allows the merchant to make block and trust lists based on the domain of the provided shopper social security number.

The merchant should submit a social security number value in the payment request for this check to work properly. This check works on any provided social security-type number, such as with Brazilian CPF.

Configuration Options

  • The score associated with the block list is established by the score associated with the rule in the main rule menu. 
  • The score associated with the trust list is established as a sub-setting.

Time To Delivery Check

This referral list allows the merchant to make block and trust lists 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 e-commerce merchants to correlate with express shipping. Note that merchants must provide the delivery time value in the payment request.

Configuration Options

  • Merchants are able to submit thresholds in a day, hour, or minute format. 
  • Each value can be given a specific scoring, negative to give it a trust value and positive to give it a block value.
  • In situations in which two different values match, the one with the highest score will trigger.

Transaction Amount Check

This check can be used to apply higher risk scores to transactions 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.

Configuration Options

  • Merchants are able to submit thresholds in any currency.
  • Amounts should be specific in minor units. 
  • In situations in which two different values match, the one with the highest score triggers.

Consistency Rules

Consistency checks compare two or more transaction data points with each other.

Airline Data One Way Ticket Check

This risk check fires when the ticket purchased is a one-way ticket. This check is only applicable for airline merchants.

 

One way airline tickets have a significantly higher likelihood of fraud. This check is only usable when appropriate airline-specific data accompanies the authorization request. 

 

The airline data must be submitted with the transaction request for this risk check to work properly.

Configuration Options 

No additional configuration options are required for this check. 


Bank Account is not Likely to be a Consumer Bank Account

This check fires when the provided account number is likely not a real consumer bank account.

 

This check includes confirming whether or not the provided number has a check digit (in the case of ELV) and that the account number has the correct number of digits. 

Configuration Options

After this risk check is enabled, there are no further settings to configure. 

Bank Address Does Not Match Any Branch Offices

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

Configuration Options

No additional configuration options are required for this check. 

Bank Name Does Not Match Bank Location ID

This check fires when the provided bank name does not match the location ID of the provided account number. This check is specific to ELV payments.

 

When an ELV transaction is carried out, the bank's name must be filled in. We receive regularly updated details from ELV about the bank name and store these in our system. If the bank name does not match the Bankleitzahl, then the check is triggered accordingly.

 

Configuration Options

No additional configuration options are required for this check. 


Billing Address Differs From Delivery Address

This risk checks fires when the billing address is different from the delivery address.

 

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

 

Because payment credentials are often stolen in fraudulent transaction, it is common for fraudsters to have goods delivered to a different location than indicated in the billing address.

In order to improve the accuracy of matching when minor differences in spelling and formatting occur, the addresses are normalized in the Adyen Customer Area (CA). Further, this check limits the comparison to the country, postal code, and house number.

Billing Address Does Not Match Card Holder Address (AVS)

This check fires when the user-provided billing address does not match their registered address. The AVS check is only available in the US, Great Britain, and Canada.

 

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, card types, and only for a limited set of countries (United States, Great Britain and Canada). If AVS is not supported, this risk check 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: 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 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: 
Merchants should only configure this check more strictly if they want to be confident in an address match (not recommended).

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

This risk check fires when the card issuer responds that the user-entered verification code did not match that of the card.

 

The issuing bank mostly declines mismatching transactions, however in some rare scenarios a CVC/CVV/CID mismatch may accompany an authorization. These kinds of 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

 

The risk check fires 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

This risk 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 have higher amounts of risk associated with them. 

Configuration Options

  • In the rule configuration, provide a list of values separated by a comma that you wish to result in the rule triggering.

Email Address does not Contain Shopper Name

This check fires when the shopper name is not part of the email address. It does dynamically account for partial matches.

 

A match between shopper's name and email address content tends to coordinate favorably in predicting if a shopper is legitimate. While it is common for fraudsters to havefirstname.lastname@email addresses, it is rarer for them to actually match them to the name on the payment methods. As such, this risk check is a good prediction of a shopper's intent.  

Email is likely to be fake or automatically generated

This check fires when the algorithm has predicted that it is likely that the provided email address is fake or automatically generated. There are two levels of sensitivity for this check.

 

Fraudsters set up scripts to automate the creation of email addresses. These email address may appear as gibberish or may be sophisticated enough to appear legitimate. Our prediction algorithm analyzes email address across our entire network and correlates certain attributes with fraud and known card-testing schemes. 

Configuration Options

There are two threshold levels for this check. This allows merchants to set different score modifiers depending on how likely the algorithm thinks the email is fake. Only the email addresses that meet one of the two thresholds trigger the check. 

Fraudulent behaviour on payment page

This feature is part of RevenueProtect+. To have RevenueProtect+ features enabled on your account, contact the Adyen Support Team.

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

Fraudsters employ various scripting techniques to test cards at high velocity. The algorithm behind this risk check analyses temporal, key-based, and mouse-based behaviour of users interacting with the payment fields. The primary risk vector this risk check is focused on is detected high-velocity card testing scenarios.

This risk check is only available for merchants utilising Client-Side-Encryption version V0.1.12 or higher. It is currently not available via API directly or Hosted Payment Page solutions.  

Configuration Options

There are two threshold levels for this check. This allows merchants to set different score modifiers depending on how likely the algorithm thinks the behaviour is fraudulent.

Interactions that meet a minimum threshold of suspicion triggers this check. Most interactions do not trigger either of these threshold level. 

No Liability Shift

This check is fired 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 check should be triggered only for 3D secure transactions or all e-commerce credit card transactions. Note that 3D Secure has significant implications on conversion rate and, as such, changes to these settings should be scrutinized before implementation.

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 our support if you want to disable ContAuth transactions (via Transaction Rules) on this merchant account.

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. 

Shopper Country Differs From Issuing Country

This risk check 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 the merchant's 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 check 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 check 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. 

The Card/Bank Account Holder Name Contains Non-Alphabetic Characters

This check will fire when the card 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"

Velocity Rules

Velocity checks allow merchants to set velocity thresholds on various customer attributes, controlling how often a customer can attempt transactions. These checks are intended to identify high-speed fraud attacks. 

To best utilize these checks merchants need to understand the behavior of their shoppers. Because the average number of transactions by a good user (e.g. once a day, twice a day, and so on) varies significantly across verticals, merchants need to have a firm understanding of their customers before enabling these checks. Velocity thresholds should be set at the threshold at which customers go from standard behavior to fraudulent behavior.

Velocity Rules are calculated at the merchant account level. If a merchant has several merchant accounts under their company account, velocity counts do not aggregate across the entire company.

For example: A single credit card is used for 2 transactions in merchant account A and 3 transactions in Merchant Account B. The Velocity Rule counts 2 in Account A and 3 in Account B.

An abandonment of the shopper after redirecting to a payment method or 3D Secure is counted as an attempt and adds to the count for velocity rules. Not all of these abandoned attempts can be found in the payment list since this list only contains authorized and refused payments.

Card/Bank Account holder name usage frequency

This check fires when the number of transactions associated with the same card holder name exceeds the configured threshold. The time threshold is a moving window calculated backwards from the moment of the transaction. 

Fraudsters often use the same card holder name when testing cards, so as to more easily automated their process. This check is aimed at detecting when the same name is being used across a set number of transactions. 

Configuration Options

  • Merchants can establish a threshold for both the number of transactions and the timeframe allowed. The default is 6 times over 6 hours.
  • The risk fires on the transaction after the set threshold. So, if you set a threshold of 6 in 6 hours, it fires on the 7th transaction in that 6 hours. 

Card/Bank Account Number Already Used by Other Shopper

This check fires when a the payment method for the transaction has already been used with a different Shopper Reference.

Fraudsters often create multiple accounts and attempt to use the same compromised account with different techniques and attack vectors. This check is aimed at identifying when a payment method is being used across multiple accounts. Note that there are some legitimate cases in which this would occur:

  • The user may have multiple accounts. 
  • It may be a shared card in a family or business setting. 
  • The shopper may attempt a transaction as a guest (assuming the merchant is assigning guests a shopper reference).

Configuration Options

  • By default, this check only cross-checks transactions within the same merchant account. The rule can be configured to assess all transactions across the merchants entire company account.

Card/Bank Account Number Usage Frequency

This check fires when the number of transactions associated with a payment methods exceeds the configured threshold. The time threshold is a moving window calculated backwards from the moment of the transaction. 

Configuration Options

  • Merchants can establish a threshold for both the number of transactions and the timeframe allowed. The default is 6 times over 6 hours.
  • The risk fires on the transaction after the set threshold. So, if you set a threshold of 6 in 6 hours, it fires on the 7th transaction in that 6 hours. 

Card Number Chunk Usage Frequency

This check fires when the number of transactions associated with the same first-12-card-digits exceeds the configured threshold. The time threshold is a moving window calculated backward from the moment of the transaction. 

Fraudsters often target a particular range of credit card numbers for some attacks. This check is aimed at generalizing the card number velocity check to also include velocity across an entire BIN range. 

Configuration Options

  • Merchants can establish a threshold for both the number of transactions and the timeframe allowed. The default is 6 times over 6 hours.
  • The risk fires on the transaction after the set threshold. So, if you set a threshold of 6 in 6 hours, it fires on the 7th transaction in that 6 hours. 

Different Cards/Bank Accounts Used by the Same Shopper

This check fires when the same payment details have been used by the same shopper reference in the last 48 hours.

The optional shopperReference field allows merchants to pass a unique user identifier with the transaction. This is usually the unique user ID used to identify the user in the merchant's internal systems. By using this field, this check acts as a velocity check on any particular user on the merchant's site. This is particularly important for account takeovers, which tend to come from registered accounts with otherwise good history.


Shopper Email Usage Frequency

This check fires when the number of transactions associated with the transaction email address exceeds the configured threshold. The time threshold is a moving window is calculated backward from the moment of the transaction. 

It is time intensive for fraudsters to collect new email addresses. As such, fraud is often attempted in clusters coming from the same email address in a given time period. This check is aimed at allow merchants to set velocity limits on any particular email address.

Configuration Options

  • Merchants can establish a threshold for both the number of transactions and the timeframe allowed. The default is 5 times over 30 minutes. 
  • The risk fires on the transaction after the set threshold. So, if you set a threshold of 5 in 30 minutes, it fires on the 6th transaction in that 30 minutes. 

Shopper IP usage frequency

This check fires when the number of transactions associated with the shopper IP address exceeds the configured threshold. The time threshold is a moving window calculated backwards from the moment of the transaction. 

Fraudsters often use the same IP address for a number of fraudulent transactions in a row, possibly attempting different cards or techniques. This check is aimed to allow merchants to set velocity limits on any particular IP address.

Configuration Options

  • Merchants can establish a threshold for both the number of transactions and the timeframe allowed. The default is 5 times over 30 minutes. 
  • The risk fires on the transaction after the set threshold. So, if you set a threshold of 5 in 30 minutes, it fires on the 6th transaction in that 30 minutes. 

Shopping Frequency

This check fires when a set threshold of transactions-per-shopper is met in a given time period. Unlike other velocity checks, which are based on a single matching attribute, there are multiple attributes used to quantify a shopper for this check.

Configuration Options

  • Merchants can establish a threshold for both the number of transactions and the timeframe allowed. The default is 5 times over 90 minutes.
  • The risk fires on the transaction after the set threshold. So, if you set a threshold of 5 in 90 minutes, it fires on the 6th transaction in the 90-minute period preceding the transaction. 
  • The following data types can be used with this check:
    1. Device Fingerprint: Device fingerprinting is a technique used to identify shoppers by making a fingerprint of their device/browser. In most cases, the fingerprint is unique for each device/browser. It is the same only if shoppers have exactly the same browser, same settings, same plugins, etc. Contact support to inquire about having device fingerprinting enabled on your account.
    2. Persistent Cookie: A persistent cookie is a unique identifier stored in different places on the shoppers device. This persistent cookie is extremely hard to remove by the shopper, and can even work cross-browser. To enable persistent cookie tracking on your account contact support.
    3. Shopper IP
    4. Shopper Email Address
  • Each data type selection increases the required number of attributes that need to match to consider two transactions coming from the same shopper.


External Risk Checks

RevenueProtect includes several checks that allow merchants to use scores and results from other third-party risk mitigation systems.  

By default, External Risk Checks are not viewable in RevenueProtect Customer Area. Please contact support to inquire about using any of these checks, as they require coordination with the third parties.

Airline Perseuss External Referral Check

Perseuss is an airline-specific risk mitigation system. This checks allows merchants to call perseuss and receive a risk score for the transaction, thus affecting the Adyen risk score.

Configuration Options

  • The merchant provides their perseuss API token, username, and password. Note that the merchant must have a perseuss account configured to use this function.
  • The merchant sets a minimum threshold value for the check. If the perseuss response exceeds that value, the rule triggers. For instance, if the perseuss score threshold is configured with 60, and the rule itself is configured with 40, if perseuss replies with a score of 65 for a transaction then the Adyen risk score for the transaction increases by 40.

Brazil CPF Check

The Cadastro de Pessoas Físicas (CPF) is the national tax registry in Brazil. This check allows merchants with Brazilian transactions to check the shopper's credentials against the CPF database.

Note that some of the data points used for this check (e.g. phone number) are optional values in the payment requests. In order for this check to work properly, a complete set of shopper data should be submitted in the payment request.

Configuration Options

There are multiple sub-checks associated with this risk check. Each allows for an individually configurable score to be added to the transaction score if the rule matches.

The checks are as follows:

  • Invalid CPF: The shopper-submitted CPF is not a valid CPF number.
  • Names not matching: The name associated with the transaction does not match with the name in the CPF database. 
  • Addresses not matching: The billing address associated with the transaction does not match that in the CPF database.
  • Phone numbers not matching: The phone number associated with the transaction does not match that in the CPF database. 

German SCHUFA Check

SCHUFA (Schutzgemeinschaft für allgemeine Kreditsicherung) is a German private credit bureau. Adyen's RevenueProtect allows merchants with German SEPA transactions to check shoppers credentials against the SCHUFA database.

Some of data values are usually optional in payment requests (e.g. shopperName, birthDate, and billingAddress), but are required for this check to work properly. The shopperName and billingAddress fields are mandatory for the SCHUFA check, while providing gender and similar information is optional (though highly recommended). Submit all the required data fields to use this check and achieve a more accurate risk score.

Configuration Options

The risk check has several filters, so that you can target only high-value/high-risk transactions:

  • Transaction Euro amount: You can indicate an amount threshold, so that only SEPA payments above the specified threshold are checked. This field's value is measured in minor units.

  • Pre-authorization total risk score: Most risk checks run prior to the authorization request. Specify a threshold value for this field to initiate the SCHUFA check only when the pre-auth risk score exceeds this threshold value.

SCHUFA responds with a value associated with a shopper. The risk check allows you to specify two separate thresholds, with a corresponding risk score for each. If both are applicable based on the SCHUFA response, the highest of these scores is used for the risk check.

For example, in the given configuration a response of A or above is set to give a score of 10, while a response of E or above is set to give 20. With this configuration, a SCHUFA response of C returns an Adyen risk score of 10, while a response of M results in a score of 20.

SCHUFA Response

Risk Score

Riskiness

P

97.79%

High

O

79.10%

N

49.16%

M

40.96%

Medium

L

22.96%

K

18.52%

I

14.65%

H

10.99%

G

6.84%

Low

F

4.11%

E

2.67%

D

1.80%

C

1.36%

B

0.92%

A

0.44%

Contact the Adyen Support Team to enable this check.

External Risk Score (Generic)

This risk check intakes a score submitted in the payment request and allows the merchant to affect the Adyen risk score as they choose. The external score must be calculated before the payment request is submitted (pre-auth).

This risk provides merchants with a flexible mechanism to pass an external risk score without solution-specific configuration. This is particularly useful when a merchant has a risk system of their own, but they also want to use RevenueProtect in coordination with it. 

Configuration Options

  • The merchant can set values to receive in the external risk score and the corresponding value of the rule should be added to the Adyen risk score. For example, an external value of 5 may add 40 to the Adyen risk score. This setting is an exact match. 

Dispute Management

Manually Disputing Chargebacks

For information on how to manually dispute chargebacks refer to the Payment dispute section, and to know more about chargebacks read chargeback guidelines.

Automatically Disputing Chargebacks

Revenue protect includes an auto-defense system which automatically disputes applicable chargebacks with no action needed on the part of the merchant. These chargebacks include:

  1. Already refunded transactions (in which the refund occurred before the chargeback was sent).

  2. Situations in which there is a liability shift (such as with 3D Secure or ApplePay payments).

  3. Chargebacks that include technical errors that invalidate them (such as when a chargeback is sent outside of the timeframe allowed by the schemes).

Chargeback guidelines

Chargeback process is used by an issuing bank either on behalf of or at the request of a cardholder to remove a charge from the cardholder's account and to collect back funds. The issuing bank or the cardholder can initiate a chargeback for various reasons including clerical errors, such as duplicate billing, to fraud claims which may be associated with identity theft. 
The chargeback may be preceded by a request for information called a retrieval request. The intent of this guide is to provide information concerning the chargeback process, including retrieval requests, and to help the merchant in their decisions concerning which chargebacks to dispute and how to do so successfully.

Adyen is not responsible if the card scheme rules in favour of the Issuer. This guide is meant only as a guideline. 

Terms associated with the chargeback process:

Term Description
Arbitration Review conducted by MasterCard, Visa, or Discover to determine the responsibility for a chargeback related dispute.
AVS A cardholder verification tool designed to reduce the risk of card-not-present (CNP) transactions in mail and telephone orders. AVS helps reduce the risk of accepting fraudulent transactions by facilitating verification of the cardholder's billing address with the card issuer. Verification results help the merchant determine whether to accept a particular transaction or to take further follow up action.
Open arbitration event

Adyen feature that indicates the issuing bank has rejected the merchant's representment or dispute and is filing a second chargeback in an effort to continue the dispute and recapture the associated funds.

Cardholder The person to whom a financial transaction card is issued or an additional person authorized to use the card.
Chargeback The reversal of a charge against a Cardholder's account initiated by the issuing bank.
Chargeback period The number of calendar days (counted from the transaction processing date) during which the issuer has the right to charge the transaction back to the acquirer. The number of days varies from 45 to 180 days depending upon the type of transaction.
Chargeback process A mechanism used by an issuing bank either on behalf of or at the request of a cardholder to remove a charge from the Cardholder's account and to recover the funds.
First chargeback cycle The sequence of events encompassing the first chargeback issued by the credit card company or issuing bank to the merchant. When the merchant receives the first chargeback they have the option to accept the chargeback or dispute and represent it back to the issuing bank.
Issuer Any Discover, MasterCard, American Express or Visa member, or a commercial organisation that establishes and maintains customer credit lines accessed through the use of a card.
Merchant Any entity that sells products or services to their customers.
Representment

An action used when a merchant wants to dispute liability (responsibility) for a chargeback. The merchant should attach supporting documentation to the chargeback case prior to taking this action.

Representment cycle The sequence of events that occur when a merchant chooses to dispute a chargeback and the transaction is sent back to the credit card issuer to reverse the chargeback.
Arbitration

An action used when the Acquirer continues a dispute beyond the arbitration chargeback based upon the merits of the case.

Pre arbitration An action used when submitting an arbitration chargeback to an issuing bank for review. Pre arbitration is a less formal process than arbitration involving only Adyen and the Issuing bank.
Reason code A code used to provide additional information regarding the nature of a chargeback, subsequent presentment, fee collection, funds retrieval request - The request from the issuer to the acquirer either for an original or legible copy of the transaction information document or for a substitute draft.

Topics covered:

Chargeback process (Visa and MasterCard)

A chargeback goes through various steps in most cases starting with a retrieval request. This request is the only opportunity for you to resolve the issue before funds are removed from your account. Whether the process starts with a retrieval request or a chargeback, it is always your obligation to deliver the required supporting documentation and prove the case in their favour. 

Retrieval request

The cardholder via their issuing bank for a sales draft or other sales related information. This request may be also a fraud analysis request and is sometimes the first step taken by the issuing bank after receiving a cardholder's complaint concerning a particular charge on their account. The issuing bank makes the request after examining the complaint and deciding that a resolution might be reached with additional information from you. It includes a reason code providing additional information concerning the cause of the request and in some cases, the required documentation.

The merchant should take action as soon as they receive the request. As with any other part of the chargeback process, there is a set time limit for the merchant to respond.  You have 24 days to submit the required information to Adyen for processing and forwarding to the Issuer.

A retrieval request almost always becomes a chargeback. 

Failure to respond to this request for a MasterCard transaction may result in a chargeback reason code 4801, in which case the you don't have dispute rights.

As of October 17, 2009, Visa allows disputing a chargeback even if it resulted from a failure to respond to a retrieval request. Adyen has an inbuilt "Automatically Generated Response to a Request for Information," in case the you do not respond within the set time frame, to avoid the you losing their dispute rights. Your response, however, would support the case better, as the "Automatically Generated Response" contains only the minimum available transaction information. 

To fulfil a retrieval request, you must supply records that contain the following information (the items in bold are included in the "Automatically Generated Response"):

Both MasterCard and Visa require the merchant to maintain the sales data for a minimum of 13 months after the sale transaction:

  • Cardholder's name
  • Cardholder's account number
  • Card expiration date
  • Merchant name
  • Merchant Address (either physical address or web address for e-commerce merchants)
  • Date of sale
  • Amount of sale
  • Authorization code
  • Name and Address Verification Service (AVS) code
  • Description of the purchased item or service
  • Ship to address
  • Proof of delivery

Visa transaction receipt retrieval request reasons:

Code

Message

28

Request for copy bearing signature

29

Effective for Retrieval Requests up to and including 19 April 2013,
T&E Document request

30

Cardholder request due to dispute

33

Fraud analysis request

34

Legal process request

6305

Cardholder does not agree with billed amount

6321

Cardholder does not recognize transaction

6322

Transaction Certificate (ICC Transaction)

6323

Transaction Information Document (TID) needed for Cardholder's personal records expense reporting

6341

Fraud investigation

6342

Potential chargeback or compliance documentation

6343

Real-time Substantiation Audit Request (IIAS)

First chargeback process

The issuing bank initiates the first chargeback on behalf of the cardholder by sending a chargeback notification to Adyen stating the dispute reason. After Adyen receives the notification, we assign it to you for review via Adyen Customer Area (CA). At the same time, your account is debited for the amount of the chargeback.
After you review the chargeback and based on the chargeback reason, you can decide whether to dispute the chargeback or to accept the chargeback. If the you decide to accept the chargeback, no action is required on their side. Alternatively, If you decide to dispute the chargeback, upload the relevant defense documents via Adyen Customer Area (CA) office within 40 days.  After you have submitted via Adyen back office, it is irreversible and automatically processed for submission through the credit card network or via the respective acquirer (in the cases where this is not Adyen) back to the issuing bank. After representing the documents, your account is credited with the deducted amount.

The issuing bank has 30 days after you have submitted the documents to issue an arbitration chargeback in the case of MasterCard, or request pre-arbitration/arbitration in the case of Visa.

This action by the Issuing bank, if taken, generates a new case in the Adyen Customer Area (CA).

Arbitration Chargeback

The Issuing bank submits the arbitration chargeback along with an explanation of what additional documentation you must supply in order to pursue the case further debiting your account again with the chargeback amount.

MasterCard Chargeback Processing Cycles and Time Frame:


The Adyen chargeback team decides whether or not to assume the arbitration chargeback.

If we decide to pursue the case, we may request you to submit additional supporting documentation to prove the validity of the transaction within 45 days of receiving the arbitration chargeback.

The chargeback team determines if the case should go to arbitration or if pre-arbitration (member mediation) and proceeds accordingly, based on the chance for a positive result or not. 

Pre-Arbitration is a review process that occurs within the MasterCard MasterCom system between the issuing bank and Adyen without the involvement of the card scheme. During this time, the case has an open pre-arbitration status. The issuing bank has the option to refuse or to participate in the review of the case. If the issuing bank declines the case, the Merchant account is debited the transaction amount. 

If the result of the Pre-Arbitration review is unfavourable, Adyen can still bring the case to arbitration. However, doing so is potentially expensive. For MasterCard, there is an initial Filing Fee of EUR 150 and an additional Administrative Fee of EUR 250. The party that loses the Arbitration case is liable for both fees. It is also possible for MasterCard to charge EUR 100 fee for each Technical Error associated with the case. MasterCard can assess technical error fees against either party, win or lose.

Visa system for pre-arbitration and arbitration is that the decision to escalate the case resides with the issuing bank and not the acquirer, e.g. Adyen. If the issuing bank does not agree with your documents, they have two options:

  • File a Pre-Arbitration case in the Visa ROL system.
  • Send the case directly to Arbitration.

Visa chargeback and documents submitting process:


If the Issuer files a pre-arbitration case, Adyen reviews the case and responds on your behalf. If Adyen accepts the case, your account is debited with the disputed amount. If Adyen declines the case, the Issuer still has the option to file with Visa for arbitration. At that point, Adyen has the option to withdraw from arbitration. However, it is liable for 270 EUR Review Fee. 
If the case goes to arbitration, a Visa committee issues a binding decision with the losing party paying the filing fee of EUR 270 and the review fee of EUR 270. 

See also:

MasterCard Chargeback Representment Guidelines
Reason code Reason Description
Code 4834 Duplicate Processing

You should demonstrate that two separate transactions were processed.

  • Provide a proof that there were two separate orders from the cardholder or that recurring billing is properly disclosed (i.e. all invoices, terms & conditions, cardholder agreement, etc).
  • Provide invoices and documents for all transactions referenced in this dispute.
Code 4837 No cardholder authorisation

You should demonstrate that the service or merchandise was a legitimate purchase by the cardholder. The only valid remedy for this chargeback is a proof that the merchant was 3D Secure - enabled.

Adyen recommends representing CB RC 4837 only if 3D Secure transaction.

Code 4841 Cancelled recurring transaction

You should demonstrate that the cardholder did not cancel or canceled after the transaction date; that the you sent a notice of the upcoming charge at least 10 days prior to transaction without a response from the cardholder. Proof that the cardholder used services after the alleged cancellation date or that merchandise was shipped before the cancellation date. Proof that this is instalment billing and not a recurring charge. 

Provide the following:

  • For services: Proof that the cardholder is still interested in using the service; for example: You may have received email(s) or any other communication about the service. It is a good practice for many merchants to engage their customers or email them prior to charging a membership fee, recurring payment, or subscription. As this would allow the customer to cancel the payment before being charged and avoid a possible dispute.
  • For merchandise: Proof that merchandise was shipped prior to cancellation date and no returns have been received (i.e. shipping information/proof of delivery). Proof that notice of upcoming billing was sent to Cardholder at least 10 days prior to transaction (i.e. e‐mail notifications, etc).

Adyen recommends accepting most CB RC 4841 as it is very difficult to prove the Cardholder did not cancel.

Code 4853 Not as described

You should demonstrate that the service or merchandise was as described or that any defects were fixed and/or defected items were replaced. 

Provide the following:

  • For services: Proof that services promised were those that were received by the cardholder (i.e. invoice, terms & conditions, log‐in information, etc).
  • For merchandise: Proof that the cardholder was sent a replacement item (i.e. shipping information, terms & conditions, return information, and invoice, etc). Proof that shipped items were as described, and were delivered to the cardholder's shipping address (i.e. invoice, terms & conditions, proof of delivery, etc).
Code 4855 Services not provided/ merchandise not received

You should demonstrate that services were rendered or that merchandise was delivered. 

Provide the following:

  • For services: Proof that the cardholder utilised the services (i.e. invoice, log‐in information, post-sale service, i.e. communication with the Cardholder after the payment, etc).
  • For merchandise: The invoice that shows cardholder's shipping address and a proof of delivery to that shipping address (i.e. tracking number and a screen shot or a print out of shipper's proof of delivery).
Code 4860 Credit not processed

You should demonstrate that returned goods were not received and terms and conditions, refund policy were properly disclosed prior to transaction, and that merchandise was delivered/services were provided or that a credit was processed. 

Provide the following:

  • For services: Statement that a cancellation of services request was not received, and proof that terms & conditions, cancellation policies are properly disclosed prior to purchase, or proof that a credit was processed. (i.e. proof of refund, cancellation policy, terms and conditions, invoices, etc).
  • For merchandise: Statement that returned goods were not received, and proof that terms and conditions/refund policies are properly disclosed prior to purchase or that a credit was processed (i.e. proof of refund, return policy, terms and conditions, proof of delivery, invoices, etc).

Adyen has an inbuilt automatic defense for "Credit previously issued." 

All of the conditions and requirements previously included in message reason codes 4841, 4853, 4855 and 4860 have been rewritten by MasterCard and are now included in one revised code called 4853 Cardholder Dispute. You will now receive a chargeback for reason code 4853. Message reason codes 4841, 4853, 4855 and 4860 may continue to be used. However they will be eventually eliminated as valid reason codes.

Code 4863 Cardholder does not recognise- potential fraud

You should demonstrate that this is a valid transaction by providing supporting documents.

Provide all available documents pertaining to the cardholder and what was purchased (i.e. invoices, description of service, terms & conditions, log in information, account info, etc) 

Visa Chargeback Representment Guidelines
Reason code Reason Description
Code 30

Services not rendered/ merchandise not received

You should demonstrate that services were provided or that merchandise was delivered. 

Provide the following:

  • For services: Proof that the cardholder used the services (i.e. invoice, log‐in information, post-sale service, i.e. communication with the cardholder after the payment, etc).
  • For an electronic commerce transaction: Representing the sale of digital goods downloaded from a website: one or more of the following: 
    • Purchaser's IP address
    • Purchaser's e-mail address
    • Description of the goods downloaded 
    • Date and time goods were downloaded 
    • Proof that your website was accessed for services after the transaction date.
  • For merchandise: The invoice that shows cardholder's shipping address and a proof of delivery to that shipping address (i.e. tracking number and a screen shot or a print out of shipper's proof of delivery). Documentation to prove a link between the person receiving the merchandise and the cardholder or to prove that the cardholder disputing the transaction is in possession of the merchandise.

 Proof of shipping does not constitute proof of receipt.

Code 41 Canceled recurring transaction

You should demonstrate that the cardholder did not cancel, or canceled after the transaction date, or expressly renewed membership (if applicable); that you sent a notice of the upcoming charge at least 10 days prior to transaction without a response from the cardholder. Proof that the cardholder used services after the alleged cancellation date or that merchandise was shipped before the cancellation date. Proof that this is an instalment billing and not a recurring charge. 
Provide the following:

  • For services: Proof that the cardholder is still interested in using the service; for example the merchant may have received email(s) or any other communication about the service. It is a good practice for many merchants to engage their customers or email them prior to charging a membership fee, recurring payment or subscription. As this would allow the cardholder to cancel the payment before being charged and avoid a possible dispute.
  • For merchandise: a proof that merchandise was shipped prior to cancellation date and no returns have been received (i.e. shipping information/proof of delivery). Proof that notice of upcoming billing was sent to Cardholder at least 10 days prior to transaction (i.e. e‐mail notifications, etc).

A cardholder may cancel a recurring transaction directly with the merchant or with the issuing bank. 

Adyen recommends accepting most CB RC 41 as it is difficult to prove the cardholder did not cancel. Moreover, Visa only requires that the cardholder provides a date of cancellation without additional proof of this cancellation.

Code 53 Not as described or defective merchandise

You should demonstrate that service or merchandise was as described or that any defects were fixed and/or defected items were replaced. 

Provide the following:

  • For services: Proof that services promised were those that were received by the Cardholder (i.e. invoice, terms & conditions, log‐in information, etc).
  • For merchandise: Proof that the cardholder was sent a replacement item (i.e. shipping information, terms & conditions, return information, and invoice, etc). Proof that shipped items were as described, and were delivered to the cardholder's shipping address (i.e. invoice, terms & conditions, proof of delivery, etc).
Code 75  Cardholder does not recognise transaction

The merchant should demonstrate that this is a valid transaction by providing supporting documents.

Provide all available documents related to the cardholder and what was purchased (i.e. invoices, description of service, terms & conditions, log in information, account info, etc).

Code 76 Incorrect currency/ transaction code

Typically occurs for a transaction receipt that was processed in error and the merchant processed a credit transaction, within 30 calendar days, instead of a reversal or an adjustment. As a consequence the cardholder suffered a financial loss due to the currency exchange rate. The rule stipulates that you must process a reversal or an adjustment if it processed a

transaction receipt in error. Thus, you have to accept the chargeback. The chargeback is limited to the difference in the credit transaction and the original debit.

Code 80 Incorrect transaction amount/ account number

You should demonstrate that original transaction amount is correct or that the cardholder agreed to the altered amount. 

Provide the proof that disputed amount matches price of what was received (i.e. invoice, cardholder agreement, etc).

Code 82  Duplicate processing

You should demonstrate that two separate transactions were processed. 

Provide a proof that there were two separate orders from the cardholder or that recurring billing is properly disclosed (i.e. all invoices, terms & conditions, cardholder agreement, etc).

Also, the invoices and documents for all transactions referenced in this dispute.

Code 83 Fraudulent transaction – card absent environment

The Merchant should demonstrate that service or merchandise was a legitimate purchase by the cardholder. 

Provide the following:

  • For services: Proof of an exact AVS match and that profile/membership information matches card information (i.e. invoices, profile/membership info, etc).
  • For an electronic commerce transaction: Representing the sale of digital goods downloaded from a website: one or more of the following: 
    • Purchaser's IP address
    • Purchaser's e-mail address
    • Description of the goods downloaded 
    • Date and time goods were downloaded; 
    • Proof that the Merchant's Website was accessed for services after the transaction date.
  • For merchandise: Proof of an exact AVS match and that merchandise was delivered to AVS match address (i.e. invoices w/billing & shipping addresses, proof of delivery, etc). documentation to prove a link between the person receiving the merchandise and the cardholder or to prove that the cardholder disputing the transaction is in possession of the merchandise.

Adyen recommends representing CB RC 83 only if 3D Secure transaction. Therefore, Adyen has an inbuilt automatic defense for transactions processed via 3D Secure.

Code 85 Credit not processed

You should demonstrate that returned goods were not received and terms and conditions, refund policy were properly disclosed prior to the transaction; that merchandise was delivered/services were provided; or that a credit was processed. 
Provide a statement that a cancellation of services request was not received, and proof that terms & conditions, cancellation policy are properly disclosed prior to purchase, or proof that a credit was processed (i.e. proof of refund, cancellation policy, terms and conditions, invoices, etc). 

The following are guidelines on proper disclosure:

  • Online transactions: An e-commerce merchant must disclose its refund policy to the cardholder, and the cardholder must be required to acknowledge the policy, before the transaction has been completed. The terms and conditions of the purchase must be displayed on the checkout screen (the screen used to present the total purchase amount) or on one of the pages the cardholder accesses during the checkout process. The cardholder should provide their acknowledgment by selecting a ''click to accept'' button or by entering their initials in a text box.
  • Mail Order transactions: A mail order merchant must disclose its refund policy on the order form, an invoice or a contract near the cardholder's signature or initials.
  • Card present transactions: You should print its refund policy near the signature line of the receipt (typically at the bottom, near the transaction amount). If the return policy is disclosed on the back of the receipt, the cardholder must sign the front of the receipt and initial the back of the receipt near the disclosure statement.

Adyen has an inbuilt automatic defense for Credit previously issued.

Use of compelling evidence

Effective for representments processed on or after 20 April 2013, you can submit compelling evidence at the time of representment. Allowable types of compelling evidence are listed in the below table:

Allowable Compelling Evidence

Message

Documentation to prove a link between the person receiving the merchandise and the cardholder or to prove that the cardholder disputing the transaction is in possession of the merchandise.

30,53,81,83

For a transaction in a card absent environment in which the merchandise is collected from the your location, any of the following:

  • Cardholder signature on the pick-up form;
  • Copy of identification presented by the Cardholder; or
  • Details of identification presented by the Cardholder.

30,81,83

For a Transaction in a card absent environment in which the merchandise is delivered, documentation (evidence of delivery and time delivered) that the item was delivered to the same physical address for which you receive an address verification service match of "Y" or "M" (if applicable). A signature is not required as evidence of delivery.

30,81,83

For an electronic commerce transaction representing the sale of digital goods downloaded from a website, one or more of the following:

  • Purchaser's IP address and the device's geographical location at the date and time of the Transaction.
  • Device ID number and name of device (if available).
  • Purchaser's name and e-mail address linked to the customer profile held by you.
  • Description of the goods downloaded.
  • Date and time goods were downloaded.
  • Proof that your website was accessed for services after the transaction date.

30,81,83

For a transaction in which merchandise was delivered to a business address, documentation to show that the merchandise was delivered and that, at the time of delivery, the cardholder was working for the company at that business address. A signature is not required as evidence of delivery.

81,83

For a Mail/Phone Order transaction, a signed order form.
For a transaction at a passenger transport Merchant, any of the following:

  • Proof that the ticket was received at the Cardholder's billing address.
  • Documentation to show that the ticket or boarding pass was scanned at the gate.
  • Details of frequent flyer miles claimed, including address and telephone number, that establish a link to the Cardholder.
  • Documentation of the following additional Transactions related to the original Transaction: purchase of seat upgrades.

81,83

For a transaction in a card absent environment, documentation to show that the transaction uses an IP address, e-mail address, or address and telephone number that had been used in a previous, undisputed transaction.

81,83

Evidence that the transaction was completed by a member of the cardholder's household or family.

81,83

For airline transactions, evidence showing that the name is included in the manifest for the departed flight and it matches the name provided on the purchased itinerary.

30, 81, 83

For airline transactions, evidence showing that the name is included in the manifest for the departed flight and it matches the name provided on the purchased itinerary.

For travel and entertainment transactions, evidence that the services were provided and any of the following:

  • Details of loyalty program rewards earned or redeemed, including address and telephone number that establish a link to the Cardholder.
  • Evidence of the following additional transactions related to the original transaction: purchase of room/vehicle upgrades; or purchases made throughout the hotel stay which were not disputed.

30

Evidence that the person who signed for the merchandise was authorised to sign for the cardholder or is known by the cardholder.

81,83

Evidence of other non-disputed payments for the same merchandise or service.

For recurring transactions, all of the following:

  • Evidence of a binding contract held between the you and the cardholder.
  • Proof the cardholder is using the merchandise/service.
  • Evidence of a previous transaction that was not disputed purchaser's IP address.

81,83

Proof of the check out page of merchants website where the terms and conditions, and cancellation and refund policy are displayed. Cardholder has to acknowledge the T&C and Cancellation and refund policy by clicking a tick box in order to proceed to payment

85

American Express Chargeback Representment Guidelines

RFI

The American Express (Amex) chargeback process starts with a Request for Information. You can fulfill this request by uploading the necessary documents within 14 days. Each RFI has it's own dispute reason, it can be either a fraud analysis, cardholder doesn't recognise charge, goods/ services not received etc.

Majority of the Amex dispute reason codes, and compelling evidence are similar to the reason codes for MasterCard and Visa.

If an RFI request is not fulfilled, it results in a chargeback where your account is debited and there is no option to defend.

Chargeback

In certain circumstances Amex debits your account without sending a Request for Information. For example, merchants with high enquiry rates (high chargeback levels) or those having a lot of fraud on their account and have a risky business environment. In those cases the transaction is charged back and there is no defense option such as uploading documents.  

If the merchant wishes to dispute the chargeback they have to contact their account manager with all the valid transaction information within 2 weeks of receiving the chargeback. Adyen reviews the documents and contacts Amex if the chargeback is invalid. If the documents are insufficient and the charge is a fraud, Adyen does nor proceed and the merchant has to accept the chargeback.

American Express Chargeback and Representment Process:

Chargeback uploader

Chargeback uploader allows merchants, who use non M-Level acquiring, to upload their chargebacks in the Adyen system. This allows for multiple aspects of revenue protect to leverage this data, including shopperDNA, risk calculator, case management, and risk reporting. Note that the chargeback uploader does not allow for dispute management via the Adyen Customer Area (CA). Merchants must still dispute chargebacks directly with their external acquirer.  

Accessing the Chargeback Uploader

Chargeback uploader is available via the Disputes section at the merchant level. Users with the Upload Chargebacks role assigned to their user account can access the upload tab.


Uploading Chargebacks

While the Chargeback Uploader is available at the merchant level, note that chargebacks can be uploaded for any payments within that company. It is not necessary to upload chargebacks for each merchant account separately. 

The uploader accepts CSVs of 1,000 payments or less at a time. The following headers are required in the CSV:

Fields Required Description
pspReference (tick) This field is mandatory for all chargebacks. It is the pspReference number of the transaction that had the chargeback.
amount (tick) This field is optional. By default, the full transaction value is used for the chargeback. If a partial chargeback occurred, this field should be provided.
reason (tick) This field is optional and can be used to provide more context behind the chargeback. This is only used for customer area visualization.

Possible Error Responses

Multiple errors can occur during upload. The following are the possible error responses and their cause:

  • The CSV file cannot be parsed.

  • The uploaded file is not a CSV file.

  • The uploaded file might contain a virus.

  • The user does not have permission to upload a chargeback file.

  • A user tries to upload a chargeback with a pspreference for a payment that is not for their company.

  • The pspReference is not in our system.

  • The chargeback amount is higher than the captured amount.