Overview
Proper error handling is crucial for building robust applications with the Mangopay API. The PHP SDK provides comprehensive exception handling to help you manage errors gracefully.Exception Types
The SDK uses two main exception classes:ResponseException
API-related errors with HTTP status codes and error details
Exception
General SDK errors (configuration, validation, etc.)
ResponseException
Thrown when the API returns an error response:Exception
General exception for SDK-level errors:HTTP Status Codes
The SDK maps HTTP status codes to meaningful error messages:| Code | Message | Description |
|---|---|---|
| 200 | OK | Request succeeded |
| 204 | No Content | Request succeeded with no response body |
| 206 | Partial Content | Partial response returned |
| 400 | Bad request | Invalid request parameters |
| 401 | Unauthorized | Authentication failed or SCA required |
| 403 | Prohibition to use the method | Access forbidden |
| 404 | Not found | Resource doesn’t exist |
| 405 | Method not allowed | HTTP method not supported |
| 413 | Request entity too large | Request body too large |
| 422 | Unprocessable entity | Validation error |
| 500 | Internal server error | Server-side error |
| 501 | Not implemented | Endpoint not implemented |
Basic Error Handling
Catching ResponseException
Catching General Exception
Error Details Object
When aResponseException occurs, you can get detailed error information:
Common Error Scenarios
Validation Errors (400)
Authentication Errors (401)
Strong Customer Authentication (401)
SCA challenges return a 401 with redirect information:Resource Not Found (404)
Validation Errors (422)
Server Errors (500)
Transaction-Specific Errors
Transactions can fail after creation. Always check the status:Error Logging
Implement comprehensive error logging:Rate Limiting
Handle rate limit responses:Idempotency for Error Recovery
Use idempotency keys to safely retry failed requests:Best Practices
Always catch specific exceptions first
Always catch specific exceptions first
Catch
ResponseException before generic Exception to handle API errors differently from SDK errors.Check transaction status after creation
Check transaction status after creation
Even if no exception is thrown, transactions can have a FAILED status. Always verify.
Log all errors with context
Log all errors with context
Include relevant context (user IDs, transaction IDs, amounts) in error logs for debugging.
Handle SCA redirects gracefully
Handle SCA redirects gracefully
When SCA is required, preserve user context and provide a smooth redirect experience.
Implement retry logic for transient errors
Implement retry logic for transient errors
Server errors (5xx) and network issues may be temporary. Implement exponential backoff.
Use idempotency keys
Use idempotency keys
Always use idempotency keys for create operations to prevent duplicate transactions during retries.
Provide user-friendly error messages
Provide user-friendly error messages
Translate technical error messages into language your users can understand.
Monitor error rates
Monitor error rates
Track error patterns to identify issues with your integration or API usage.
User-Friendly Error Messages
Create a helper to translate API errors:Next Steps
Authentication
Learn about API authentication
Payment Flows
Understand payment operations