Test your Integration

To ensure the integration with the Transaction Gateway Unit (TGU) is functioning correctly, we have prepared a set of certification test cases. These tests will ensure that the data you send matches our expected results, giving you confidence in the accuracy and reliability of the integration.

Gateway fallback test

The Multicore will route payments to the best available TGU, as some circumstances that we are not able to route our you like to route yourselves.

Requirement	Description
Manual fallbacks	Confiirm that you have an simple option to select the gateway.. That is predefined on connect.pay.nl
Multicore	Check a Card Not Present Payment via connect.pay.nl, the best option to process payments, using the AMS-IX as peering server.
Rerouted Multicore	Check a Card Not Present Payment via connect.premium-pay.nl (this is behind a cloudflare server and thus not using the AMS-IX as peering provider. This might be helpful when the AMX-IX has issues.
Selected - CORE	Test a payment on payments.nl or achterelkebetaling.nl (direct Google Cores) in case of full outage of our MAIN core processing engines.
Selected - CORE	Test a Buy Now Pay Later for all you BNPL providers on a fallback core

Instore POS test

The Multicore will route your terminal payments to the right Core. If the GMS is up, you can switch the core in the terminal. If it's not available and there is a mayor outage on the multicore, you might need to switch it manual to a fallback core

Requirement	Description
Knowledge	Check if the users of the Terminal know the procedure how to switch a termnial to another CORE
Manual fallbacks	Switch the terminal from instore.pay.nl to instore.payments.nl while the GMS is available. Start a payment via connect.pay.nl and perform a test payment.
GMS down	Switch the terminal to the instore gateway on a direct fallback (payments.nl) and switch the TGU to payments.nl as well and perform a test payment.

Data integrity test

To successfully pass each test case, specific fields in the API need to contain predefined values. By validating these fields against the expected values, we can confirm that the integration is functioning correctly and providing the desired outcomes.

In our sandbox screen, you will find a sidebar that provides detailed information about each field in the test cases. Each field's status is indicated by one of the following four states:

None: This field is not included in the specific test case.
Missing: This field is required by the test case but is missing from your input.
Mismatch: This field is present in your input, but its content does not match the expected value.
Passed: This field matches the expected value specified by the test case.

The test cases

We determine the specific test case to use, based on the value provided in the amount.value field of the API. To start testing your integration simply set the integration.test property to true in the API.

Payment Status Test

Requirement	Description
VERIFY	A payment in VERIFY must: lower your stock, and the Payer must see a message that the order is received. Do not show that the payment is succesful
VERIFY-DECLINE	Send an email that the payment was declined and that if the user was debitted, the user receives there funds back within 48 hours. Revert the Stock
VERIFY-APPROVE	Check if the order is marked as: 'Ready for shipment' or that the services will be provided.

You're Ready to GO!

Once all the test cases pass successfully, you can have full confidence that your integration with the TGU is functioning as expected. The passing of these test cases indicates that your integration is correctly sending the data according to the platform's requirements and that our platform is handling them as you should expect. This provides assurance that your integration is reliable and ready for production use.