API principles

Versioning

The version of the API is specified in the resource path of each endpoint.

For instance, in the URL https://uat.banking.live:55555/ppws/api/pws/v2/pws_create_account/, v2 denotes the API version is 2.

Paymentology increases the version number with each release that includes changes incompatible with previous versions. Minor updates and bug fixes are usually rolled out without changing the version number. It's important to ensure that your application can handle API revisions smoothly by accommodating additional, unspecified resource fields in the response and varying response sizes.

🗒️

You can read more about versioning in our Breaking change policy located here.

Headers

To interact with Banking.Live API's, ensure that your API requests include the correct headers.

We utilize a StaticX-API-Key Header mechanism. To learn what this is and how to use it, please refer to the reference guide located here.

Errors

Our error codes guide located here, provides a complete reference to the error codes and descriptions that could be returned. You can utilize this information to troubleshoot and enhance your exception-handling capabilities.

API changes

Our approach to communicating critical changes, version control and breaking change policy can be found here

In this guide we provide you with examples of what Paymentology defines as a Breaking or Non-Breaking Change.

API security

A list of the security measures in place for Banking.Live API's is available for you to view on our API security page located here.

You can also reference our PaySecure API and Static API headers guides for further information on our API security protocols.