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.