We test all our processor integrations as good as possible. However it is a good practice to test all the concrete setup by yourself. Especially to find issues which are located between our API and your application.

This documentation covers different strategies to realize a testing. Depending on the business case one or the other strategy fits the best. Eventually also a mixing of those strategies is feasible.

The easiest approach is to separate the testing environment entirely from the production environment. As such we allow to configure different spaces. Those spaces are completely isolated. The advantage is that the data is never mixed and hence the production system is not messed with test data.

However this implies that all settings and configurations need to be copied from one environment to the other.

Another approach is to switch to the test mode whenever necessary. This allows a fast and flexible way to test. However the production data gets polluted with test data and the live users may see the test environment.

A space can contain for the same processor multiple configurations. The conditional testing uses this feature by configuring a test processor and a live processor. By adding a condition on the connectors linked with the test processor those connectors can be filtered. As an example the condition can filter on the amount or country. When a test transaction should be conducted the data provided from the other application is modified to fit with the condition configured on the test connector.

This approach allows to test connectors and processors within the live environment without letting the user see those connectors. This approach allows also to share certain configurations (e.g. resources). However the processor and connector configurations need to be maintained twice.