Versioning

We generally do not make backwards-incompatible changes to the API. If we do need to do so (e.g. due to backwards-incompatible changes in NPCI), we inform you well in advance.

The current version is v1. We maintain only one version of the API.

Backwards-compatible changes

LotusPay considers the following changes to be backwards-compatible:

• Adding new API resources.

• Adding new optional request parameters to existing API methods.

• Adding new properties to existing API responses.

• Adding new validations to existing APIs, as long as the validation is consistent with this API Reference specification.

• Changing the order of properties in existing API responses.

• Changing the length or format of object IDs or other opaque strings. This includes adding or removing fixed prefixes (such as MD on mandate IDs). You can safely assume object IDs we generate will never exceed 255 characters, but you should be able to handle IDs of up to that length. If for example you’re using MySQL, you should store IDs in a VARCHAR(255) COLLATE utf8_bin column (the COLLATE configuration ensures case-sensitivity in lookups).

• Adding new event types. Your webhook listener should gracefully handle unfamiliar events types.