On This Page

Handle Errors

An error response notifies the user that the action relating to the request has failed. Use the

error.reason

field to determine how to handle the error. Errors such as

INVALID_PARAMETER

INVALID_REQUEST

are considered integration errors.

Error reasons and messages appear in a standard error structure, which is returned when the API request could not be handled. For programmatic actions, you should only rely on the value in the

error.reason

field. Errors include a description in the

error.message

field.You can use this field to understand the error. You can provide your own description based on the value in the

error.reason

field. In some cases, the

error.details.message

and

error.details.location

provide additional information.

Error Response Fields
Error Field	Type	Description
error.details.location	String	The value of this field uses an XPATH expression to point to the field that fails validation.
error.details.message	String	The specific error associated with the field.
error.message	String	Returned from the backend call
error.reason	String	These options can be used to override transaction options for the DPA that were configured during the DPA Registration.

This is an example error:

error {
    "message": "Input parameters validation failed.", "reason": "INVALID_PARAMETER",
        "details":
    [// Optional structure, used with input data validation error
        {// Types to specify the fields with errors "location": "creditCard",
            "message": "Should be a numeric value"
        }
    ]
}

Error Codes
Error Code	Description
AUTH_ERROR	The server understands the request, but cannot authenticate.
INVALID_PARAMETER	The value provided for one or more request parameters is considered invalid. This error is also generated in case of a missing required field. Typically, this is an integration error; whenever possible, should provide client-side validation to avoid a round trip to the server. For user errors, handle this error by prompting the user to change the value.
INVALID_REQUEST	The server could not interpret the request. Usually, these are the cases, when a data field has to be in a particular format but is not. Examples include: Base64 decoding failed The field is not in a particular format. The message field may provide additional clarification of what part or field of the request is considered incorrect. Please, refer to the API specification for the structure, format, and constraints on the API request.
NOT_FOUND	The requested resource/business entity does not exist. The resource might also be hidden for security reasons.
RATE_LIMIT_EXCEEDED	Too many requests have been sent in a given amount of time. Intended for use with rate limiting schemes. Decrease the rate of sending API requests; wait before sending the next request. Consider implementing Exponential Backoff algorithm. In this algorithm, the delay before you retry is defined as: Retry delay in milliseconds = (2 ^ n ) * 1000 + randomDelayMs , where n is your retry count, such as 0, 1, 2, 3, …, and random- DelayMs is random delay in milliseconds, such as an integer between 0 and 1,000.
REQUEST_TIMEOUT	Request timeout.
SERVER_ERROR	General server error.
SERVICE_ERROR	An error occurred on the server. Either show a generic message, or retry the same request again (it might succeed).
UNKNOWN_ERROR	Unknown error.