Blue-green Adyen point-of-sale test card

When making test payments with this card:

• To test a specific application on the test card, use the corresponding currency in your payment request.
• To test different CVMs, use different combinations of transaction amount and currency.
• To test declined payments, use the last three digits of the transaction amount.

You can view the details of test payments in your test Customer Area under Transactions > Payments.

The test card simulates Mastercard and Maestro payment methods. To verify that your POS app and terminal are communicating as expected and to test your reconciliation, no other card payment methods are needed. But as an alternative, you can order test card packs from B2PS.

Card applications

Use the table below to see which application on the test card corresponds with the scenario you want to test.

To try a particular application, use the corresponding currency in your payment request. You can also select an application on the terminal: when the terminal shows Present card, insert the card and select the application on the display.

Testing CVMs

When you make payments with the test card, a CVM is triggered based on the test card's CVM list, test card application, amount, and currency.

This is the CVM list for the test card:

Amount threshold

• See the table below. To trigger a particular CVM with a dynamic currency conversion (DCC) transaction, make sure the amount is above the threshold after the conversion.

CVM 1 and CVM 2:

• CVM code: if this CVM is unsuccessful, try the next CVM.
• CVM type: depends on the test card application. See table below.
• CVM condition: the CVM type applies if the transaction is in the currency of the test card application and the amount is above the threshold.

CVM 3

• CVM code: if this CVM is unsuccessful, fail the cardholder verification.
• CVM type: depends on the test card application. See table below.
• CVM condition: the CVM type always applies.

The next table shows the CVM types for each application. Note that to trigger CVM 1 and 2 the amount must be above the threshold and in the currency of the application.

For online PIN, with the card inserted in the card reader, the test system will accept any PIN code you enter.

For offline PIN, with the card inserted in the card reader, the transaction will be declined if you enter an invalid PIN.

If you are testing a contactless transaction, you will be asked to enter a PIN when the transaction amount is above the contactless reader limit specific for the country/region the terminal is located in.
You can find the latest limits in your Customer Area under In-person payments > Terminal settings > Payment features > Limits > Contactless CVM limit.

Testing offline transactions

To test offline EMV transactions:

1. Contact our Support Team and ask them to configure the chip floor limit, offline swipe limit, and offline refund limit to the values you want.
2. Force an internet connection failure, for example by unplugging the Ethernet cable.
3. Do your test transactions. The test card enforces the offline limits configured in your test Customer Area.

Each application on the test card has its own counter for offline EMV transactions. Offline EMV transactions within the configured offline limits are accepted until the counter is exceeded. The first three offline transactions for the test card application are accepted and the fourth is declined. To reset the offline counter for a test card application, you need to do an online EMV chip transaction (inserting the card) with that application. This also applies to the application mc en gbr gbp. This application shares the offline counter with the contactless application, but contactless transactions cannot reset the counter.

Simulating declined payments

In general, test payments generate the result Approved. To simulate declined payments, you need to change the last three digits of the RequestedAmount that you specify in the payment request.

For example, to test how your integration responds when the issuer suspects fraud, specify an amount with 151 as the last three digits, such as 101.51 or 21.51.

The following table shows:

• The last three digits of the amount to specify for simulating a specific response.
• The Result, ErrorCondition,AdditionalResponse.refusalReason, and AdditionalResponse.message from the Terminal API response.

Raw responses

In our back end, we receive the payment response from card schemes and issuers. In case of a declined payment, we map the raw response to a combination of ErrorCondition, refusalReason, and message and return this in the Terminal API response.

Raw responses provide additional information, but you do not need to test them because you should not code against them. If you base your failure-handling logic on raw responses, that might break your integration because acquirers and issuers sometimes change their raw responses without notice.

If you still want to receive the raw response, you can:

• Set up standard webhooks with the additional setting Add Raw Acquirer Result enabled.
• For a Terminal API integration, configure receiving raw responses.

See also