Glossary

An API, or application programming interface, allows applications to connect and communicate with one another and request that another application perform a certain task. The API defines how developers of one application submit requests to another application to perform tasks (e.g. request information on a transaction) and the format of responses (e.g. the transaction data). This allows the developers of one system (e.g. a webshop) to communicate with another system (e.g. IXOPAY) in order to request and process data. A payment API is an API that handles payment-related requests and data. Whenever the application accesses the functionality of the API, the application is said to call the API.

There are many different payment APIs provided by different providers (e.g. Stripe, Google Pay, PayPal, open banking, IXOPAY), which all use their own unique format. In order to communicate with the payment provider via the API, developers need to code their application to adhere to the API’s specification, which determines how to build and use the connection between the systems. IXOPAY offers a single API that can be used to process transactions via hundreds of different payment providers.

While payment APIs are not standardized, the UK opted to roll out a single, standardized open banking API. This was not the case in the EU, where there are many disparate solutions. However, this may change in the future, as the EU has acknowledged that a patchwork of incompatible solutions is not ideal. As integrating each API requires a certain amount of development work, increasing the amount of APIs increases the cost, effort and complexity of development.

Using an API avoids having to reinvent the wheel. Without a payments API, merchants would need to write their own code to handle those aspects that are otherwise handled by a third-party, e.g. to process transactions. 

A platform like IXOPAY offers far more than just the ability to process payments - transactions can be analyzed, reports can be generated and risk management functionality is included in the platform. Furthermore, changes over time can mean an API needs updating (e.g. to reflect updated security protocols). If only the API needs to be updated, developers of other applications can continue using the same processes as before, and only the underlying API code that handles these requests needs to be updated.

To use these features, a merchant simply needs to call the API to process a transaction and IXOPAY handles all other aspects. As long as the transaction has been processed by IXOPAY, it is stored in the system and can be analyzed or included in reports. This makes the process of handling payments much simpler than if each merchant needed to implement all this additional functionality themselves, rather than simply submitting a transaction request for processing.

IXOPAY provides a number of APIs for different purposes. IXOPAY’s Transaction API is used to submit transactions for processing, handle responses form service providers and allows users to query the transaction database. The Push API allows transactions that are not processed directly by IXOPAY (e..g. transactions performed via POS terminals) to be stored in IXOPAY, allowing these transactions to be analyzed in IXOPAY, included in reports etc.

Other APIs are available to handle disputes, reconciliation, settlements as well as set up and on board merchants, among others.