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.

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 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 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 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.

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	Offline enciphered 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	Offline enciphered PIN	Offline 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	Offline enciphered PIN + Signature	Signature	Offline plaintext PIN		Decline after 3 tries
mc pt bra brl	EMV chip	Online PIN	Offline enciphered PIN	Signature		Decline after 3 tries
MSR	MSR	Signature				Decline after 3 tries

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 the terminal is located in.
You can find the latest limits in your Customer Area under Point of sale > 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 can't 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 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 notice.

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

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

See also