Green Adyen point-of-sale test card

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

Card applications

Use the table below to see which application on the test card corresponds with the scenario you want to test, and which card details to use in your test requests.

Application	Payment method	Locale	Issuing country	Currency	Expiration date	Cardholder	PIN	PAN	AID
mc en gbr gbp	Mastercard	English	UK	GBP	02/28	AD YEN-UK	1234	5413 3300 8909 9999	A0000000041010
mc en usa usd	Mastercard	English	US	USD	12/29	AD YEN-US	1234	5100 0600 0000 0002	A0000000041010
ms nl nld eur	Maestro	Dutch	NL	EUR	03/30	AD YEN-NL	1234	6000 0707 3616 9237 003	A0000000043060
mc en aus aud	Mastercard	English	AU	AUD	12/29	AD YEN-AU	1234	5520 3300 0000 0001	A0000000041010
mc cn chn cny	Mastercard	Chinese	CN	CNY	12/29	AD YEN-CN	123456	6243 0300 0000 0001	A0000000041010
mc pt bra brl	Mastercard	Portuguese	BR	BRL	12/29	AD YEN-BR	1234	2308 8800 0000 0000	A0000000041010
MSR					03/30	MSR AD YEN-VISA		4151 5000 0000 0008

Testing CVMs

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

This is the CVM list for the test card:

Amount threshold

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

CVM 1 and CMV 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-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.

This table shows the amount thresholds and the CVM types for each application:

Application	Interface	CVM 1 amount >200.00	CVM 2 amount >100.00	CVM 3	Contactless/NFC above CVM limit	Offline within set limits
mc en gbr gbp	EMV chip + Contactless	Online PIN	Enciphered Offline PIN	Signature	Online PIN	Decline after 3 tries
mc en usa usd	EMV chip	Signature	Online PIN	No CVM		Decline after 3 tries
ms nl nld eur	EMV chip	Online PIN	Enciphered Offline PIN	Plaintext PIN		Always decline
mc en aus aud	EMV chip	Online PIN	Plaintext PIN	Signature		Decline after 3 tries
mc cn chn cny	EMV chip	Enciphered offline PIN + Signature	Signature	Plaintext PIN		Decline after 3 tries
mc pt bra brl	EMV chip	Online PIN	Enciphered Offline PIN	Signature		Decline after 3 tries
MSR	MSR	Signature				Decline after 3 tries

If you are testing a contactless transaction, you will be asked to enter a PIN when the transaction amount is above the NFC CVM limit specific for the country the terminal is located in.

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 transactions within the configured offline limits are accepted until the counter is exceeded. The first thee offline transactions for the test card application are accepted and the fourth is declined. To reset the offline counter for a particular test card application, you need to do an online contact (EMV chip) transaction with that application. This also applies to application mc en gbr gbp. This application shares the offline counter with the contactless application, but contactless transactions can't reset the counter.

Simulating declined payments

In general, test payments generate the result Approved. To simulate declined payments, you can 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 don't 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 notification.

If nevertheless you want receive the raw response, you can:

• Set up standard notifications with the additional setting Add Raw Acquirer Result enabled.
• For a Terminal API integration: Configure receiving raw responses.

See also