{"title":"Validation types and refusal reasons","category":"default","creationDate":1574033460,"content":"

Adyen runs validations to decide whether to authorise a transaction. For example, we evaluate relayed authorisation<\/a> and transaction rules<\/a>, and validate if the transaction complies with scheme rules.<\/p>\n

To find out why a payment was refused, check the validation results and refusal reasons. You can find this information either from the webhooks that Adyen sends, or directly in your Customer Area<\/a>.<\/p>\n\n

\n
\n \n <\/tabs>\n <\/div>\n<\/div>\n\n

Validation results<\/h2>\n

You can find the result for each validation type in the balancePlatform.transfer.created<\/a> webhook, in the validationFacts<\/a> array.<\/p>\n\n\n\n\n\n\n\n\n
Result<\/th>\nDescription<\/th>\n<\/tr>\n<\/thead>\n
valid<\/strong><\/span><\/td>\nThe transaction passed the validation.<\/td>\n<\/tr>\n
invalid<\/strong><\/span><\/td>\nThe transaction did not pass the validation.<\/td>\n<\/tr>\n
notValidated<\/strong><\/span><\/td>\nThe validation was not performed because some services were unreachable or Adyen did not have the information needed to perform the check.<\/td>\n<\/tr>\n
notApplicable<\/strong><\/span><\/td>\nAdyen decided that the validation is not applicable to the state of the transaction. For example, if you are using relayed authorisation but the transaction already failed a transaction rule, then the relayed authorisation is marked as notApplicable<\/strong><\/span>.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Validation types<\/h2>\n

The following are the types of validation that Adyen runs against a transaction.<\/p>\n

accountLookup<\/h3>\n

Checks if the resources (such as account holder and balance account) exist and are active.<\/p>\n

arqc<\/h3>\n

ARQC (Authorization request cryptogram) mismatch between card and terminal. This can be indicative of counterfeit fraud.<\/p>\n

atcCheck<\/h3>\n

ATC (Application Transaction Counter) mismatch between the card and the terminal. This can be indicative of counterfeit fraud.<\/p>\n

authorisedPaymentInstrumentUser<\/h3>\n

The payment is refused due to a sanctioned individual in the list of Authorized Payment Instrument Users attached to the card.<\/p>\n

avsAddress<\/h3>\n

AVS stands for Address Verification Service<\/em>. When an address is included in the payment request, we check if the billing address matches the account holder data. This validation fails if the billing address does not match the account holder's address.<\/p>\n

avsPostalCode<\/h3>\n

AVS stands for Address Verification Service<\/em>. When a postal code is included in the payment request, we check if the postal code matches the account holder data. This validation fails if the billing address does not match the account holder's postal code.<\/p>\n

balanceCheck<\/h3>\n

Checks if the balance account has sufficient available balance to fund the payment amount.<\/p>\n

cardAuthentication<\/h3>\n

Checks if the physical card was authenticated by at least one security factor, such as magstripe or chip-and-pin authentication.<\/p>\n

cardholderAuthentication<\/h3>\n

Checks if the card user authenticated the transaction, for example by providing a CVC or PIN.<\/p>\n

cardholderVerificationResult<\/h3>\n

The PIN or CVC is not valid.<\/p>\n

cashbackAmountLimit<\/h3>\n

The cash back request is beyond the limit set on the card.<\/p>\n

cavv<\/h3>\n

CAVV stands for Cardholder Authentication Verification Value<\/em>, which card schemes send if a payment goes through 3D Secure authentication. When a payment goes through 3D Secure, Adyen checks the validity of the authentication value including the transaction amount.<\/p>\n

cvc1<\/h3>\n

CVC1 (Card Verification Code 1<\/em>) is encoded in the track data on the card itself, and is used in card-present magstripe and contactless transactions. This validation fails if the track data has been tampered with, or the magstripe is corrupted.<\/p>\n

cvc2<\/h3>\n

CVC2 (Card Verification Code 2<\/em>) is printed on the card, and is used in card-not-present ecommerce transactions. This validation fails if the card user enters an incorrect CVC.<\/p>\n

cvc3<\/h3>\n

CVC3 (Card Verification Code 3<\/em>) is used in card-present transactions to identify and prevent replay attacks<\/a>. This validation fails when Adyen identifies that the transaction is a replay.<\/p>\n

entitySettings<\/h3>\n

Checks if the account holder is allowed to do an action, such as to change their card PIN.<\/p>\n

inputExpiryDateCheck<\/h3>\n

Checks if the expiry date from the payment request matches the expiry date on the card.<\/p>\n

maxAuthAmount<\/h3>\n

Checks if the transaction amount is less than or equal to the configured maximum authorisation amount on the balance platform.<\/p>\n

mitAllowedMerchant<\/h3>\n

Checks if there was a valid reason why the transaction skipped authentication.<\/p>\n