Integration Testing

APIs allow software systems to interact with each other over the Internet through a series of calls. For this purpose, an API integration must be implemented. As part of this process, it is important to verify on the side of the integrated system (for example, POS) that the API documentation of the target system (for example, the gateway) was interpreted and implemented in the code of integration correctly. Verification procedures include testing typical scenarios of API performance. In the case of payment processing integration, it’s important to verify not only the cases of approval, but also the situations of transaction error or decline.
For this purpose, there is a logic of response emulation in the gateway called proxy emulator. The specific API response is triggered by the values of one or several parameters submitted in the request. Typically, it´s a transaction amount. Test amount ranges and the specific response codes that they trigger are described in the corresponding documentation section present in all API modules specifications for which emulation logic is available: realtime, batch, terminal.


The proxy emulator is available for all basic types of integrations.

Table 1. Types of integrations and corresponding proxy profile types.

{class=newtable
!style="font-weight:bold"|Integration Type
!style="font-weight:bold"|Profile Type
|-
|direct debit processing
|ach/proxy
|-
|cards batch processing
|cards-batch/proxy
|-
|cards realtime processing
|cards-realtime/proxy
|-
|tokenization
|tokenization/proxy
|}
One or several of these profiles should be configured before testing based on the integrator’s needs.
Tokenization profile is required to test any type of processing integration (direct debit, cards realtime, cards batch) in addition to the processing profile.