Overview
The PayMaya Android SDK v2 provides specific exception types to help you handle errors gracefully. All exceptions are returned through theFailure result type in onActivityResult.
Exception Types
BadRequestException
Thrown when the server returns a 400 (Bad Request) or 401 (Unauthorized) response code. This typically indicates invalid request parameters or authentication issues.Properties
message: String- Detail message of the exceptionerror: BaseError- Detailed error object containing additional information
Error Types
Theerror property can be one of two types:
PaymentError
When It’s Thrown
- Invalid or missing required fields in the request
- Authentication failure with invalid API keys
- Malformed request data
- Unauthorized access to resources
Example Handling
HttpException
Thrown when an unknown HTTP exception occurs. This indicates an unexpected HTTP error response from the server.Properties
code: Int- HTTP response codemessage: String- HTTP response message
When It’s Thrown
- Server returns an unexpected HTTP status code (e.g., 500, 502, 503)
- Network-related errors that return HTTP error codes
- Service temporarily unavailable
- Gateway timeout or other server errors
Example Handling
InternalException
Thrown when an unexpected response from the backend is retrieved or an internal SDK error occurs.Properties
message: String- Detail message describing the errorcause: Throwable?- Optional underlying cause of the exception
When It’s Thrown
- Unexpected or malformed response from the PayMaya API
- JSON parsing errors
- Internal SDK processing errors
- Unexpected data format in the response
Example Handling
PaymentFailedException
A singleton exception thrown when a payment transaction fails. This is a simple marker exception without additional properties.Properties
None - this is an object (singleton) exception.When It’s Thrown
- Payment was declined by the payment provider
- Insufficient funds
- Card verification failed
- Payment was explicitly rejected
Example Handling
Complete Exception Handling Example
Here’s a comprehensive example that handles all exception types:Best Practices
Always handle all exception types
Always handle all exception types
Use a
when expression with an else branch to handle unexpected exception types that may be added in future SDK versions.Log exceptions for debugging
Log exceptions for debugging
Always log exception details during development to help diagnose issues. Consider using different log levels for different exception types.
Provide user-friendly messages
Provide user-friendly messages
Don’t expose technical error messages to users. Translate exception types into clear, actionable messages.
Implement retry logic for transient errors
Implement retry logic for transient errors
For
HttpException with server errors (5xx codes), consider implementing automatic retry logic with exponential backoff.Report internal exceptions
Report internal exceptions
Use an error tracking service (like Crashlytics or Sentry) to monitor
InternalException occurrences in production.Extract error details from BadRequestException
Extract error details from BadRequestException
The
BadRequestException contains detailed error information. Use the parameters field to identify which fields need correction.Error Models Reference
PaymentErrorParameter
Contains information about field-specific validation errors.PaymentErrorDetails
Contains detailed payment processing error information.See Also
Result Types
Learn about Success, Cancel, and Failure result types
Error Handling
Best practices for error handling in your app