Test authorisation using cardholder name

It is important that you ensure a complete integration into Adyen by testing result codes.

If you're not able to submit additionalData for testing, you can use the card holderName field instead.

Test payment result

Make a /payments request, providing the appropriate holderName from the list of Adyen response codes.

This example shows how to get a REFUSED payment by providing DECLINED in the holderName.

Customize scheme response and raw refusal reason

You can optionally set both the actual scheme response code and provide your own raw refusal reason. The raw refusal reason is the direct response provided from Visa or Mastercard.

Make a /payments request, and when providing card information, pass the holderName with the following data:

a holderName from the list of Adyen response codes.
a Scheme Response code and Refusal reason raw String.

For this value, use the format:

[Adyen Response code] : [Scheme Response code and Refusal reason raw String]

You may need to lower the risk score value to take into account non-alphabetic characters in the cardholder name like a colon (":"). This and other non-alphabetical characters trigger the risk check, which may cause the payment to be declined with a FRAUD reason code.

Example

The following example shows how you test a "Declined" payment result due to an "Error", using the holderName:

DECLINED : 06 : ERROR

The holderName field value cannot be longer than 80 characters max.
If you specify an incorrect CVC or an invalid expiry date, the payment fails and the operation returns a generic DECLINED refusal reason.

Test failed modifications

In rare cases, a modification might fail after we have processed the modification.

To test this scenario, make a /payments request choosing a holderName from the list below that corresponds with the type of failed modification that you want to test:

`holderName`	Outcome
capture failed	We simulate a failed capture, for more information see CAPTURE_FAILED
refund failed	We simulate a failed refund, for more information see REFUND_FAILED

After your request is authorised, you must initiate the modification that you're testing, either capture or refund. After you've done that, we will automatically simulate the failed modification.

It can take up to 24 hours before the failed modification simulation completes.