We provide a basic testing system to simulate transaction scenarios and functionalities. You can use this system to ensure your test integration is working as expected, before you switch to an integration that can make live transactions.
You need to :
- Test the happy flow.
- Test non-happy flows such as time-outs and connection problems, verifying the transaction status.
- Simulate various acquirer responses to test your handling of declined transactions.
- Test different Cardholder Verification Methods (CVM).
We strongly recommend you also test your live integration.
Testing credit and debit cards
To test card payments on your test terminal, you need to have a test card. With this, you can make dummy payments that do not result in actual credits or debits to a live bank account.
You can view the details and the result of test payments in your test Customer Area under Transactions > Payments.
Adyen test card
You can order a free Adyen test card from your test Customer Area as an accessory for your terminal.
The Adyen test card has several "applications" programmed onto it that each simulate a card with a specific brand, language, country, currency, and Cardholder Verification Method (CVM). Using the Adyen test card, you can:
- Test different card brands.
- Test different CVMs.
- Test declined payments.
- Simulate the terminal UI in a different language.
B2 test card sets
Apart from the test card provided by Adyen, you can also buy an Adyen test card set from B2. Such a set includes several cards, each with a unique brand, language, country, and currency. These cards work in our test environment, and are primarily intended to test if your integration supports various card brands.
Which test card are you using?
Select your test card below to learn how to use it.
Test cards from providers other than Adyen or B2 may not be compatible with our test terminals.
Testing gift cards
In general, gift card providers have a test environment and physical test gift cards for end-to-end test transactions. However, it takes time and effort to set up the correct testing details and credentials. Also, these test environments are not always online. For those reasons, we provide a testing system that lets you simulate gift card transactions.
When simulating transactions:
- Use a specific gift card number depending on your gift card provider.
- Use a
RequestedAmountwith 100 as the last three digits, such as 1.00 or 11.00. This will result in an Authorised transaction.
You can test other scenarios in your live environment using real gift card details and small amounts.
Gift card numbers
To simulate gift card transactions, use the following gift card numbers.
|Type||Number||Security code||Expiry month and year|
|Givex gift card||6036280000000000000||ANY||12 2222|
|Generic gift card||6364530000000000||ANY||12 2222|
|SVS gift card||6006490000000000||ANY||12 2222|
|Fiserv (formerly ValueLink) gift card||777718270854480||ANY||12 2222|
If the simulator asks for a Fiserv (formerly ValueLink) promo code, enter any value.
To test the balance check, make a test payment amount higher than EUR 50.
Testing QR code wallets
To test QR code payments, you can:
- Make test payments using our simulator.
- Perform live, in-app tests.
For this, you need to get the QR code wallet app, set it up with a credit or debit card, and do live penny tests (payments for a minimal amount).
We provide a simulator that lets you try out QR code payments in the various flows.
If you are testing QR code payments initiated by the terminal or initiated by the cash register, our simulator shows a QR code on the terminal and automatically approves the transaction after 15 seconds.
- Shopper-presented flow
If you are testing QR code payments initiated by a barcode scanner, our simulator immediately approves the transaction when you scan the barcode.
To make test payments, you do not need to use an actual payment method QR code (for example, an Alipay QR code). Any barcode or QR code can be used, but we highly recommend testing your integration using a barcode or QR code that uses the same specifications as the payment method:
- Alipay wallet ID: string of 16-24 digits, starting with 25, 26, 27, 28, 29 or 30
- WeChat Pay wallet ID: 18 digits, starting with 10, 11, 12, 13, 14 or 15
By changing the value of the transaction, you can test other payment scenarios, such as abandoned or refused transactions.
Nearly all test QR code payments will result in the transaction being Approved. To simulate different scenarios, change the last three digits of the
RequestedAmount that you specify in the payment request.
For example, to test how your integration responds to an abandoned transaction, specify a
RequestedAmount with 504 as the last three digits, such as 105.04 or 25.04.
|Amount (last three digits)||Description||Transaction result|
Simulates an approved transaction.
The payment is immediately approved.
A QR code appears on the terminal, and the payment is approved after 15 seconds.
In the shopper-presented (barcode initiated) flow, simulates a scenario where the shopper needs to authenticate the transaction using their app.
You need to scan the shopper's barcode with your terminal. The payment is approved after 15 seconds.
Simulates an abandoned transaction.
The payment will be refused due to an issuer time-out.
In the shopper-presented flow, simulates a refused transaction.
A QR code appears on the terminal, and the payment is refused after 15 seconds.