It is important to test that your integration can handle payments and payment modifications. This page describes how to test:
- Payments in general and payments with encrypted card details, third-party authentication data, or Level 2/3 data.
- Modifications like manual, partial, and failed captures; full, partial, and failed refunds; reversals; and authorization adjustments.
We recommend that you:
- Use our test card numbers for different brands and use test credentials for other payment methods that support it.
- Start each test with a test payment with the amount of 100.
- Test each modification below to make sure your integration can handle different payment scenarios:
Payment
Test making a payment.
After selecting the Pay button:
- On your client-side, if you were redirected to another page or app, get redirected to your website or app after completing the payment.
- Get the AUTHORISATION webhook on your server.
Payment with encrypted card details
If your client-side integration is not complete yet, you can test your server with encrypted card details in your API request.
Add the prefix test_
to the test card credentials.
For example, to use the Mastercard test card with the number 5555555555554444, use the following in your API request:
Payment with third-party authentication data
If you use a third-party 3D Secure provider to get authentication data and use Adyen to authorise payments, you can test the authorisation-only flow using the following payment details:
Card number | Expiry date | Security code (CVC/CVV/CID) |
---|---|---|
4917 6100 0000 0000 | 03/2030 | 737 |
- From your server, make a test payment request with the information required for the authorisation-only flow.
- Get the AUTHORISATION webhook on your server.
Manual capture
Test manually capturing a full payment amount.
After making the test payment:
- Capture the full (100) test payment manually.
- Get the CAPTURE webhook on your server.
Partial manual capture
Test manually capturing a partial payment amount. In a partial manual capture, you manually capture less than the full payment amount.
After making the test payment:
- Capture part (less than 100) of the test payment manually.
- Get the CAPTURE webhook on your server.
The remaining amount of the payment is automatically cancelled.
Multiple partial manual capture
Test manually capturing multiple partial payment amounts. In multiple partial manual captures, you manually capture less than the full payment amount. Then, you manually capture another amount, until you have captured the full payment amount.
You must contact our Support Team to enable this.
After making the test payment:
- Manually capture part (less than 100) of the test payment.
- Get the CAPTURE webhook on your server. The
amount.value
in the webhook is the amount you captured. - Manually capture the remaining amount of the test payment.
- Get the CAPTURE webhook on your server.
Failed capture
Rarely, a capture can fail even after you receive a successful CAPTURE webhook. To test a failed capture scenario:
- Make a card payment, specifying:
holderName
: capture failed.
- Get the AUTHORISATION webhook on your server.
- Capture this payment, using either automatic or manual capture.
- Get the CAPTURE_FAILED webhook on your server.
It can take up to 24 hours for the failed modification simulation to finish.
Cancel
Test canceling an authorized payment. You can only cancel a payment if it is set for delayed automatic capture or manual capture.
After making the test payment:
- Get the AUTHORISATION webhook on your server.
- Cancel the test payment.
- Get the CANCELLATION webhook on your server.
Full refund
Test refunding a full payment amount.
After making the test payment:
- Refund the full (100) test payment.
- Get the REFUND webhook on your server.
Partial refund
Test refunding a partial payment amount.
After making the test payment:
- Refund part (less than 100) of the test payment.
- Get the REFUND webhook on your server.
Multiple partial refund
Test refunding a partially captured payment amount.
After making the test payment:
- Capture part (less than 100) of the test payment manually.
- Get the CAPTURE webhook on your server.
- Refund the partially captured amount, using the PSP reference of the original test payment in the request.
- Get the REFUND webhook on your server.
Failed refund
Rarely, a refund can fail even after you receive a successful REFUND webhook. To test a failed refund scenario:
- Make a card payment, specifying:
holderName
: refund failed.
- Get the AUTHORISATION webhook on your server.
- Refund this payment, either in your Customer Area, or with an API request.
- Get the REFUND_FAILED webhook on your server.
It can take up to 24 hours for the failed modification simulation to finish.
Reversal
Test reversing a payment amount to return funds to a shopper.
After making the test payment:
- Reverse the test payment, using the PSP reference of the PSP reference of the original test payment in the request.
- Get the CANCEL_OR_REFUND webhook on your server.
Pre-authorization and adjustment
Test pre-authorization of a payment amount. This is only available for cards and Klarna.
- Pre-authorize a payment with the amount of 100.
- Get the AUTHORISATION webhook on your server.
Test an authorisation adjustment where you change the authorized amount.
- Modify the authorization with the new amount of 175.
- Get the ADJUST_AUTHORISATION webhook on your server.
Payment with Level 2/3 data
Test payments that that include Level 2 or Level 3 data.
You must contact our Support Team to enable the setting to include enhanced scheme data in your Customer Area.
Use the following test card numbers. Each card number corresponds to a different response:
Card number | Expiry Date | CVC | Response |
---|---|---|---|
4444 3333 2222 1111 | 03/2030 | 737 | VGIS |
2222 4107 4036 0010 | 03/2030 | 737 | L2 |
5555 5555 5555 4444 | 03/2030 | 737 | L3 |
- Submit a payment request with one of the following card numbers.
- Get the response or webhook with an
additionalData
object (for example,"cardSchemeEnhancedDataLevel" : "L2"
).