Payment Account Tokenization

All PAT APIs use URL based versioning and each endpoint is prefixed with "/vX" where X represents a numeric version number.

All PATAPI's use URL based versioning and each endpoint is prefixed with "/vX" where X represents a numeric version number, such as:

New versions of API functions can be introduced with new product releases. PAT supports the two latest versions.

Only two API endpoint versions are supported in a product release. The previous version minus one (if one exists) will be deprecated in the next minor release when a new version is introduced in a release.

Example: Current API endpoint versions are v2 and v3. V2 is deprecated when v4 is added.

The deprecated version will be supported for one minor release before it becomes unavailable.

A new version may apply to a single API resource or the entire API.

The API specifications document all supported versions.

The list of changes displayed below can be applied to an API and are considered non-breaking, so no new version is introduced.

The list of changes displayed below can be applied to an API and are considered non-breaking, so no new version is introduced. The API developer should handle these changes in their implementation.

• Adding a new API resource.
• Adding a new, optional, request parameter to an existing API resource.
• Adding a new enum value in the request or response.
• Relaxing constraints on an existing request parameter.
• Adding a new response parameter.
• Changing the order of parameters in the response.
• Changing the format of opaque string identifiers.

• Ignore any unknown fields or enum values received as part of API responses.
• New optional parameters may be added to existing APIs and constraints relaxed on existing request parameters at any time.

API changes that will likely break the implementation require the introduction of a new API endpoint version.

API changes that will likely break the implementation require the introduction of a new API endpoint version. The API developer needs to implement these changes in one of their API endpoint versions before the deprecation of the supported API endpoint versions.

The following changes are considered breaking changes:

• Introducing new required parameters in the request.
• Removing required fields in the response, including error responses.
• Changing the format of required parameters in the response.
• Format change of existing optional parameters in the response
• Redesigning an API.
• Making changes in business logic.
• Making authentication/authorization changes that break functionality. However, changes to allow JWS/JWE algorithms, which are configured via the UI, do not warrant a new version.
• Changing the HTTP method for an existing endpoint.

The API developer should implement these changes in the latest supported API endpoint version.