Search

Are you looking for test card numbers?

Would you like to contact support?

Issuin icon

Payment validation types

Validations that Adyen performs before authorising or refusing a payment.

When we receive a payment request, we run validations to decide whether to authorise or refuse the payment. For example, we evaluate relayed authorisation and transaction rules, and validate if the transaction complies with scheme rules. However not all failed validations cause a refusal. Some validations are used only to provide information about the transaction.

If you want to find out why a payment was refused, then it's useful to check the validation results. These results provide information about which validations failed. You can find the validation results in:

On this page you'll find more details about validation types and which scenarios might cause validations to fail.

Validation types

AccountLookup

Checks if the balance platform resources (such as account holder and balance account) exist and are active.

AVS_Address

AVS stands for Address Verification Service. 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.

AVS_PostalCode

AVS stands for Address Verification Service. 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.

BalanceCheck

Checks if the balance account has sufficient available balance to fund the payment amount.

CAVV

CAVV stands for Cardholder Authentication Verification Value, which card schemes send if a payment goes through 3D Secure authentication. When a payment goes through 3D Secure, Adyen checks if the authentication was successful before authorising the payment.

CVC1

CVC1 (Card Verification Code 1) 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.

CVC2

CVC2 (Card Verification Code 2) 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.

CVC3

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

InputExpiryDateCheck

Checks if the expiry date from the payment request matches the expiry date on the card.

MaxAuthAmount

Checks if the transaction amount is less than or equal to the configured maximum authorisation amount on the balance platform.

PartialApproval

This validation is used only for transactions where the acquirer supports partial authorisations, and only from certain MCCs such as automatic fuel dispensers and electronic cash registers. This validation checks if the transaction amount depletes the card's balance and requires another payment method to complete the transaction. The result is always valid, because this validation is only performed when the transaction meets the conditions.

PartyScreening

Checks if the processing merchant is in any sanction list.

PaymentInstrumentExpirationCheck

Checks if the card is not expired at the time of the transaction.

PIN

Checks the PIN in ATM and point-of-sale transactions.

RelayedAuthorisation

Only applies if you have enabled relayed authorisation. This validation fails if you refuse a payment. If Adyen does not receive a response after 1500 milliseconds, the relayed authorisation stand-in processing check is triggered.

In some scenarios, Adyen may decide that a relayed authorisation validation is not applicable to a payment. For example, if a payment already failed a transaction rule, this validation will no longer be applicable.

RelayedAuthorisationSTIP

This is the relayed authorisation stand-in processing, triggered when Adyen does not receive a response within 1500 milliseconds. The validation result is set to valid or invalid based on your default fallback setting.

Screening

Checks if the transaction complies with Adyen-wide screening rules such as rules from card schemes.

TransactionRules

Validates the payment against transaction rules.

If this validation fails, you can find out more information about which transaction rule failed from:

TransactionValidation

Checks if the transaction contains unsupported data.

VelocityLimitExceeded

Checks if the transaction violates velocity limits set by schemes.

Validation results

You can find the result for each validation type in the balancePlatform.payment.created webhook, in the validationResults array.

Result Description
valid The transaction passed the validation.
invalid The transaction did not pass the validation.
notValidated The validation was not performed because some services were unreachable or Adyen did not have the information needed to perform the check.
notApplicable Adyen 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.