It’s essential to validate your integration. This section explains how to test in the sandbox environment, including using stub data, simulating different scenarios, and ensuring your setup works as expected.

Sandbox setup

Before you start testing in Sandbox, please ensure you have completed the Sandbox Setup described here. This setup is a mandatory prerequisite for successful testing.

Testing authentication API

When setting up your sandbox environment, you generated and stored a sandbox refresh token. This token is used to obtain an access token, which is required to authenticate all subsequent API requests.

1. Call the Get Access Token endpoint using your sandbox refresh token.
2. Use this token in the Authorization header for all subsequent API calls.
3. The access token is valid for 6 minutes. After it expires, you must request a new access token using the refresh token.

Testing payments API

Payments can be processed using various payment methods, each with different characteristics and outcomes. To facilitate testing, the sandbox environment includes predefined scenarios that can be triggered by specifying an order amount.

These scenarios and their corresponding behaviors are described in the section below.

iDEAL

Test Scenarios

| Any other amount triggers a successful transaction.

Test example

1. Create an order announcement with amount = 100
2. Open the checkout page using the URL provided in the Create Order response.
3. Select iDEAL as the payment method
4. The transaction will automatically receive the SUCCESS status
5. The shopper is redirected back to your webshop
6. Verify that the order status is correctly retrieved and processed on your side

iDEAL snel bestellen

To test iDEAL Snel Bestellen, you can use the same scenarios as the general iDEAL scenarios. Note that additional fields are required in the Create order announcement call

Test example

1. Create an order announcement with amount = 100 and include the following fields:
   1. paymentBrand = 'IDEAL'
   2. paymentBrandForce = 'FORCE_ALWAYS'
   3. shippingCost.amount required
   4. shippingCost.currency required
   5. requiredCheckoutFields required
2. Open the checkout page using the URL provided in the Create Order response.
3. The transaction will automatically receive the status SUCCESS,
4. The shopper is redirected back to your webshop.
5. Retrieve the order status and checkout details using the Get order details endpoint
6. Process the order status and checkout details to complete the transaction flow

Credit & Debit cards

Test cards

| Note: Apple Pay and Click to Pay are currently not supported in sandbox

Test Scenarios

| Any other amount triggers a successful transaction.

Test example

1. Create an order announcement with amount = 1000
2. Open the checkout page using the URL provided in the Create Order response.
3. Select credit or debit card as the payment method
4. Enter the following details: • card details (see test cards) • Name: e.g. John Doe • Email: e.g. [email protected]
5. After clicking "Pay", the transaction receives the status SUCCESS
6. Verify that the order status is correctly retrieved and processed on your side

Card on File

Card on File is a feature within card payments. It allows shoppers to store payment details for future use. The test cards and test scenarios for credit and debit cards also apply to Card on File. Note that there are additional required fields in the Order Announcement request to enable Card on File.

Test example

1. Create an order announcement with amount = 1000 and include the following fields:
   1. EmailAddress required
   2. shopperRef required
   3. enableCardOnFile = TRUE
2. Open the checkout page using the URL provided in the Create Order response.
3. Select credit or debit card as the payment method
4. Enter the following details:
   1. card details (see test cards)
   2. Name: e.g. John Doe
   3. Email: e.g. [email protected]
   4. Opt in for 'Save this card for future purchases'
5. After clicking “Pay”, the transaction status changes to SUCCESS, and the payment details are stored against the shopperRef.
6. Verify that the order status is correctly retrieved and processed on your side
7. (Optional) Manage stored payment details using the Get Payment Details and Delete Payment Details endpoints. See the instructions in the “Shopper Scenarios” section below.

Bancontact

Test card

Test Scenarios

| Any other amount triggers a successful transaction.

Test example

1. Create an order announcement with amount = 1000
2. Open the checkout page using the URL provided in the Create Order response.
3. Select credit or debit card as the payment method
4. Enter the following details: • card details (see test cards) • Name: e.g. John Doe • Email: e.g. [email protected]
5. After clicking "Pay", the transaction receives the status SUCCESS
6. Verify that the order status is correctly retrieved and processed on your side

PayPal

| Any other amount triggers a successful transaction.

Test example

1. Create an order announcement with amount = 100
2. Open the checkout page
3. Select PayPal as the payment method
4. The transaction immediately receives the status SUCCESS
5. The shopper is redirected back to your webshop
6. Verify that the order status is correctly retrieved and processed on your side

Get order status

In the sandbox environment, transaction and order data are fully persisted, reflecting production behavior.

Test example

1. Complete an order in the sandbox with one of the scenarios described above.
2. Verify that your webhook URL receives the notification.
3. Use the token from the notification to call Get Order Status.
4. Check if the order data corresponds with the testing scenario.

Get order details

Test example

1. Complete an order and note the Order ID from the announcement.
2. Call Get order details with that ID.
3. Check if the order data corresponds with the testing scenario.

Testing refunds API

Refund scenarios are stubbed. There are static requests that will retrieve a standard stubbed response.

Get refundable details

The following transactions ID will generate the following reponse

| Any other transaction ID returns a refundable amount of €50,00.

Test example

1. Perform a Get refundable details call using the transaction ID 6b07e860-3b61-11ed-a6a1-a7d3128de7f2.
2. Verify that you receive the a reponse with refundable amount = €50.

Create refund

Use the transaction ID 6b07e860-3b61-11ed-a6a1-a7d3128de7f2 to simulate a refund with a refundable amount of €50.00.. The refund status responses are triggered based on the amount (in cents) you submit.

| Any other amount triggers a successful refund.

Test example

1. Perform a Create Refund call using the transaction ID 6b07e860-3b61-11ed-a6a1-a7d3128de7f2.
2. Set the refund amount to 100.
3. Verify that you receive the status SUCCESS.

Get refund details

Test example

1. Peform the Get refund details call by using the following data
   1. Transaction ID: 6b07e860-3b61-11ed-a6a1-a7d3128de7f2
   2. Refund ID: Take the refund ID from the Create Refund response.
2. Verify the response

Testing shopper API

During checkout, the shopper can choose to save their payment details for future use. The functionality described below allows you to manage stored card details by:

• Retrieving saved payment details
• Deleting saved payment details

For testing, you must use identifiers provided in the Create Order response, as these are stored in the sandbox environment.

Get payment details

Key Requirement: Before you can retrieve payment details, you must simulate a shopper storing a card during checkout. Refer to the “Card on File” section to mimic this process.

Test example

1. Call the Get payment details endpoint. Include:
   1. shopperRef for the shopper with stored payment details.
2. Confirm that the response contains the stored payment details (e.g., card type, masked card number, expiry date)

Delete payment details

Key Requirement: Before you can retrieve payment details, you must simulate a shopper storing a card during checkout. Refer to the “Card on File” section to mimic this process.

Test example:

1. Call the Delete payment details endpoint. Include:
   1. shopperRef for the shopper with stored payment details.
   2. The id returned from the Get Payment Details response.
2. Verify that the card is no longer available in the shopper’s stored payment details.