Breaking change policy

This policy outlines Paymentology’s expectations for clients using our (Banking.Live) platform and is intended to set expectations for our clients when changes or updates are being made to our platform APIs, reports and data interfaces.

As Paymentology continues to evolve by introducing new product features and capabilities on our platform, our goal is to minimise material disruption that these changes may have on our clients.

Occasionally, a change may require action from clients to prevent disruption or adverse effects to our platform or services.

The purpose of this policy is to outline which platform changes or updates constitute a breaking change, and which ones do not.

Breaking changes

Breaking changes encompass updates or upgrades to Paymentology’s platform that may include code modifications or alterations that require clients to adapt to in order to avoid potential material disruption or an adverse effect on the platform or services.

🗒️
Paymentology will communicate breaking changes to clients prior to deployment, unless emergency or unplanned maintenance and/or suspension of the use of the platform or services is necessary to prevent or mitigate potential threats to the integrity or performance of the platform or the services.

Non-exhaustive examples of breaking changes

Introduction of a new mandatory request/response header.
Changes to agreed-upon details of a file exchanges (e.g., file name patterns, field widths, field data types, ordering of fields, format changes, adding/removing fields in fixed width files).
Making a previously optional input field a mandatory field.
Removal of a previously mandatory field or data element in an existing response returned from Paymentology.
Removal of a previously mandatory field or data element in an existing request sent by Paymentology that does not change the meaning of existing fields, with the exception of those within FAST messages removed by the card scheme/network.
Requiring a new input field.
Updates to existing required product configuration parameters.

Non-breaking changes

Non-breaking changes constitute updates or upgrades to Paymentology’s platform that are not expected to materially disrupt or have an adverse effect on our platform or services. Clients can adapt to these changes at their own discretion. These changes can be handled by clients without notice from Paymentology.

Non-exhaustive examples of non-breaking changes

Addition of a new, optional field to a request that does not change the behaviour of existing fields.
Introduction of a new response code for new functionality that does not impact existing response codes.
Addition of a new field or data element to an existing response sent by or returned from Paymentology that does not change the meaning of existing fields.
Adding an optional request/response header.
Adding a new endpoint, API resource or method.
Adding a new column to a report.
Adding a new value/enum to existing data elements in request and/or response messages sent by Paymentology.
Alterations to the user interface that do not affect the underlying functionalities, such as changing colours, fonts, or layout elements in a way that does not alter user interactions.
Changing the values of data elements in FAST messages that originate from card scheme/network changes.
Changing the order of properties in existing API responses (REST ONLY).
Removal of an optional request/response header or field.
Update to a parameter/field description.
Update to an existing field or data element in an existing response returned from Paymentology.

Sunsetting and versioning

Sunsetting involves intentionally phasing out or discontinuing a product, service, feature, application or platform version.

Paymentology follows a versioning policy allowing for the maintenance of a limited number of versions behind the most recent version published by Paymentology, with older versions eventually removed and discontinued.

A maximum of two versions of our Platform behind the most recent version published (based on minor version number) may be maintained at any given time.
Enhancements will only be made on the most recent version.
Older versions more than two versions behind the most recent version published by Paymentology may be removed and discontinued.

Version numbering

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version as needed.
MINOR version released every six months and consolidating all PATCH version changes released in those six months.
PATCH version when changes are introduced within the six-month lifespan of the MINOR version.