Android SDK - Error Handling Guidelines

This topic provides a comprehensive list of error codes exposed in the Paydiant Android SDK and their respective descriptions so that reference application developers can properly handle each error instance.

Internal Error Reference

Internal errors are returned to the app when the SDK itself detects an error and refuses the call before even directing it to the mobile gateway. Internal errors are represented by any code numbered 1000 or higher. Internal error codes are universal across all modules are not context sensitive.

Server Error Reference Pre-SDK 5.4

Server errors occur during processing of the request withing the Paydiant platform. The mobile gateway then returns applicable error information to the SDK to be returned to the app in the callback method.

Server error codes are context sensitive within individual modules, so their meaning can vary depending on the module. For example, a 404 error in the payment module means a payment account cannot be found, while the same 404 error code in the transaction module means the transaction cannot be found.

The following sections provide definitions for server error codes within each module. Because server error codes are context sensitive, the same code may have different definitions across each module.

Authentication module

Customer module

Device info management module

The Device Info Management methods use a generic exception populated with a specific eventCode to identify the method during which the error occurred. Error code definitions for this module vary by event, so developers should handle these errors individually for each specific event.

GCM utility module

The GCM Utility methods use a generic exception populated with a specific eventCode to identify the method during which the error occurred. Error code definitions for this module vary by event, so developers should handle these errors individually for each specific event.

Transaction module

Transaction flow management

The Transaction Flow Management methods use a generic exception populated with a specific eventCode to identify the method during which the error occurred. The error code definitions for these methods vary depending on the event, executing rule and method response parameters. Developers should take care to handle these errors relevant to each specific context.

Payment account management module

The Payment Account Management module uses a generic exception populated with a specific eventCode to identify the method during which the error occurred. Error code definitions vary depending on event, so developers should handle errors relevant to each specific context.

Gift account management module

The Gift Account Manager uses a generic exception populated with a specific eventCode to identify the method during which the error occurred. Error code definitions vary depending on event, so developers should handle errors relevant to each specific context.

Receipt management module

The Receipt Management module uses a generic exception populated with a specific eventCode to identify the call during which the error occurred. Error code definitions vary by event, so developers should handle errors relevant to each specific context.

Refund module

Offers module

The Offers module uses a generic exception populated with a specific eventCode to identify the processing event during which the error occurred. Error code context varies by event, so handle errors relevant to each specific context.

Loyalty management module

The Loyalty Management module uses a generic exception populated with a specific eventCode to identify the method during which the error occurred. Error code definitions vary depending on event, so developers should handle errors relevant to each specific context.

User registration module

The User Registration module populates the generic exception with a specific eventCode to identify the origin of the error. Error definitions vary by event, so handle errors relevant to each specific context.

Secure cloud integration utility

Paydiant’s Secure Cloud integration utility uses a generic exception populated with a specific eventCode to identify the method during which the error occurred. Error code definitions vary depending on event, so developers should handle errors relevant to each specific context.

Bluetooth Light Energy (BLE) management module

Paydiant’s BLE Management module uses a generic exception populated with a specific eventCode to identify the method during which the error occurred. Error code definitions vary depending on event, so developers should handle errors relevant to each specific context.

Online ordering integration utility

Paydiant’s Online Ordering integration utility uses a generic exception populated with a specific eventCode to identify the method during which the error occurred. Error code definitions vary depending on event, so developers should handle errors relevant to each specific context.

Server maintenance mode

When the server is in maintenance mode, all server calls will throw PaydiantServerMaintenanceModeException. This exception object will be populated with the status code 203, along with a status message describing the reasons for which the sever is in maintenance mode.

Payment status code reference

The following codes represent the payment status codes defined by Paydiant for use within its platform. These values may be returned to the app within the paymentStatusCode attribute of each transactionFlow.transactionDetail.paymentResult instance. Most often, the failure codes in this list will not be returned to the app, since the SDK’s server response codes are returned for general success and failure responses.

Payment status

Payment input failures

Issuer-related status

Merchant-related Status

Server Error Reference SDK 5.4 and Later

For all methods exposed in Android SDK 5.4 or later, the SDK does not re-purpose the HTTP codes sent by the mobile gateway based on the context. Rather, the PaydiantError class passes the unchanged HTTP code, along with a context-specific description and an instance of the new ErrorInformation class, which contains the Paydiant-generated errorCode and errorDescription to represent the event status, plus an external error code passed by a third-party entity through the connector framework.

The following XML sample depicts the general structure of the server error object.

< PaydiantException > < statusCode > 400 < \statusCode > < statusMessage > BAD_REQUEST< \statusMessage > < description > "Account already exists."< \description > rawErrorDescription > < \rawErrorDescription > < errorInformation > < ErrorInformation > < errorCode > 798 < \errorCode > < errorDescription > DUPLICATES_NOT_ALLOWED < \errorDescription > < externalErrorDescription > Array of ExternalErrorInformation < \externalErrorInformation > < \ErrorInformation > < \errorInformation > < \PaydiantException >

ErrorInformation values

The ErrorInformation instance is populated with errorCode and errorDescription values defined in the Mobile Gateway. The following tables define each possible value within the code ranges that have been designated for specific operation types.

Settlement statuses (200 - 209)

Authorization statuses (210 - 219)

Scheduled processing statuses (220 - 229)

Refund statuses (230 - 239)

General payment processing ptatuses (240 - 249)

Payment processing input statuses (250 - 299)

Non-transaction processing statuses (340 - 349)

Non-transaction processing input statuses (350 - 369)

Balance inquiry statuses (370 - 379)

Verification statuses (380 - 389)

Loyalty account statuses (400 - 409)

Issuer-related statuses (500 - 549)

Merchant-related statuses (550 - 599)

Full reversal statuses (600 - 619)

Void statuses (620 - 639)

Loyalty transaction statuses (700 - 749)

Load account statuses (750 - 759)

Provisioning statuses (760 - 769)

Identity provider ptatuses (780 - 789)

Variable-step payment account enrollment statuses (790 - 809)