No momento, esta página não está disponível em português
Developer-resource icon

Testing result codes

Test getting result codes with your integration and troubleshoot issues before it goes live.

Test how your integration handles responses from the plataforma de pagamentos da Adyen by getting specific result codes.

Choose the endpoint that your integration uses to make payment requests:

Step 1: Make a test payment request

Make a /sessions request including a value from the the list of testing request values in either:

  • paymentMethod.holderName
  • additionalData.RequestedTestAcquirerResponseCode

For example, to test getting resultCode: Refused with refusalReason: ExpiredCard, make either request:

Step 2: Get the result code in the response

The response includes the refusal reason:

Values for testing refusal reasons

It is important that you make sure your integration is complete by testing result codes. To test result codes, do either of the following in your /payments request:

  • Include the RequestedTestAcquirerResponseCode from the list of refusal reasons below in the additionalData field.
    For example, to test the refusalReason Expired Card, include in your /payments request:

  • Include the appropriate holderName from the list of refusal reasons below.
    For example, to test a scenario where the shopper has insufficient funds, make a /payments request with NOT_ENOUGH_BALANCE as the holderName:

    "amount": {
      "currency": "USD",
      "value": 1000
    "reference": "Your order number",
    "paymentMethod": {
      "type": "scheme",
      "number": "4111111111111111",
      "expiryMonth": "10",
      "expiryYear": "2020",
      "holderName": "NOT_ENOUGH_BALANCE",
      "cvc": "737"
    "returnUrl": "",
    "merchantAccount": "YOUR_MERCHANT_ACCOUNT"

Some card-related payment methods, for example Alipay, will redirect you to a simulator where you can select the payment result. In this case, the value provided as the cardholder name will be ignored.

RequestedTestAcquirerResponseCode holderName refusalReason resultCode
0 UNKNOWN Unknown Error
1 APPROVED - Authorised
2 DECLINED Refused Refused
3 REFERRAL Referral Refused
4 ERROR Acquirer Error Error
5 BLOCK_CARD Blocked Card Refused
6 CARD_EXPIRED Expired Card Refused
7 INVALID_AMOUNT Invalid Amount Refused
8 INVALID_CARD_NUMBER Invalid Card Number Refused
9 ISSUER_UNAVAILABLE Issuer Unavailable Refused
10 NOT_SUPPORTED Not supported Refused
11 NOT_3D_AUTHENTICATED 3D Not Authenticated Refused
12 NOT_ENOUGH_BALANCE Not enough balance Refused
13 PENDING - Received
14 ACQUIRER_FRAUD Acquirer Fraud Refused
15 CANCELLED Cancelled Refused
16 SHOPPER_CANCELLED Shopper Cancelled Refused
17 INVALID_PIN Invalid Pin Refused
18 PIN_TRIES_EXCEEDED Pin tries exceeded Refused
19 PIN_VALIDATION_NOT_POSSIBLE Pin validation not possible Refused
20 FRAUD FRAUD Refused
21 NOT_SUBMITTED Not Submitted Refused
23 TRANSACTION_NOT_PERMITTED Transaction Not Permitted Refused
24 CVC_DECLINED CVC Declined Refused
25 RESTRICTED_CARD Restricted Card Refused
26 REVOCATION_OF_AUTH Revocation Of Auth Refused
27 DECLINED_NON_GENERIC Declined Non Generic Refused
28 WITHDRAWAL_AMOUNT_EXCEEDED Withdrawal amount exceeded Refused
29 WITHDRAWAL_COUNT_EXCEEDED Withdrawal count exceeded Refused
31 ISSUER_SUSPECTED_FRAUD Issuer Suspected Fraud Refused
32 AVS_DECLINED AVS Declined Refused
33 PIN_REQUIRED Card requires online pin Refused
34 NO_CHECKING_ACCOUNT_AVAILABLE_ON_CARD No checking account available on Card Refused
35 NO_SAVINGS_ACCOUNT_AVAILABLE_ON_CARD No savings account available on Card Refused
36 MOBILE_PIN_REQUIRED Mobile PIN required Refused
37 CONTACTLESS_FALLBACK Contactless fallback Refused
38 AUTHENTICATION_REQUIRED Authentication required Refused
39 RREQ_NOT_RECEIVED RReq not received from DS Refused

Testing failed modifications

Rarely, a modification can fail after we process it. To test a failed modification scenario:

  1. Include one of the following holderName values in your test payment request:

    holderName Outcome
    capture failed We simulate a failed capture, and you get a CAPTURE_FAILED webhook on your server.
    refund failed We simulate a failed refund, and you get a REFUND_FAILED webhook on your server.

    For example, for a failed refund for a payment using the /sessions endpoint:

  2. After you get a successful AUTHORISATION webhook for the test payment on your server, make either a capture or refund modification.

    For example, make a /payments/{paymentPspReference}/refunds for the original test payment with pspReference:QBQQ9DLNRHHKGK38:

It can take up to 24 hours for the failed modification simulation to finish.

  1. Get the webhook for the modification failure on your server.

    For example, get the REFUND_FAILED webhook:

Customizing 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:

For this value, use the following 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.


For example, to test a "Declined" payment result due to an "Error", use the holderName: DECLINED : 06 : ERROR. The maximum length is 80 characters.

If you specify an incorrect CVC or an invalid expiry date, the payment fails, and the response includes refusalReason: DECLINED.