No momento, esta página não está disponível em português
Tools-2 icon

Testing payments and modifications

Test payments and modifications with your integration and troubleshoot issues before it goes live.

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:

Payment

Test making a payment.

After selecting the Pay button:

  1. On your client-side, if you were redirected to another page or app, get redirected to your website or app after completing the payment.
  2. 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
  1. From your server, make a test payment request with the information required for the authorisation-only flow.
  2. Get the AUTHORISATION webhook on your server.

Manual capture

Test manually capturing a full payment amount.

After making the test payment:

  1. Capture the full (100) test payment manually.
  2. 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:

  1. Capture part (less than 100) of the test payment manually.
  2. 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:

  1. Manually capture part (less than 100) of the test payment.
  2. Get the CAPTURE webhook on your server. The amount.value in the webhook is the amount you captured.
  3. Manually capture the remaining amount of the test payment.
  4. 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:

  1. Make a card payment, specifying:
    • holderName: capture failed.
  2. Get the AUTHORISATION webhook on your server.
  3. Capture this payment, using either automatic or manual capture.
  4. 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:

  1. Get the AUTHORISATION webhook on your server.
  2. Cancel the test payment.
  3. Get the CANCELLATION webhook on your server.

Full refund

Test refunding a full payment amount.

After making the test payment:

  1. Refund the full (100) test payment.
  2. Get the REFUND webhook on your server.

Partial refund

Test refunding a partial payment amount.

After making the test payment:

  1. Refund part (less than 100) of the test payment.
  2. Get the REFUND webhook on your server.

Multiple partial refund

Test refunding a partially captured payment amount.

After making the test payment:

  1. Capture part (less than 100) of the test payment manually.
  2. Get the CAPTURE webhook on your server.
  3. Refund the partially captured amount, using the PSP reference of the original test payment in the request.
  4. 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:

  1. Make a card payment, specifying:
    • holderName: refund failed.
  2. Get the AUTHORISATION webhook on your server.
  3. Refund this payment, either in your Customer Area, or with an API request.
  4. 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:

  1. Reverse the test payment, using the PSP reference of the PSP reference of the original test payment in the request.
  2. 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.

  1. Pre-authorize a payment with the amount of 100.
  2. Get the AUTHORISATION webhook on your server.

Test an authorisation adjustment where you change the authorized amount.

  1. Modify the authorization with the new amount of 175.
  2. 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
  1. Submit a payment request with one of the following card numbers.
  2. Get the response or webhook with an additionalData object (for example, "cardSchemeEnhancedDataLevel" : "L2").