Skip to main content

Error Codes and Handling

This guide provides comprehensive information about error handling in the Orsunpay API, including error codes, retry strategies, and best practices.

Error Response Format

All API errors follow a consistent format:

HTTP Status Codes

StatusNameDescriptionWhen to Retry
400Bad RequestInvalid request parameters❌ Never
401UnauthorizedInvalid or missing API key❌ Never
403ForbiddenInsufficient permissions❌ Never
404Not FoundResource doesn’t exist❌ Never
409ConflictResource conflict (e.g., duplicate)❌ Never
422Unprocessable EntityValid request, business rule violation❌ Never
429Too Many RequestsRate limit exceeded✅ After delay
500Internal Server ErrorServer error✅ With backoff
502Bad GatewayUpstream service error✅ With backoff
503Service UnavailableService temporarily down✅ With backoff
504Gateway TimeoutRequest timeout✅ With backoff

Authentication Errors

authentication_required

invalid_api_key

insufficient_permissions

Validation Errors

invalid_request

invalid_parameter_value

parameter_out_of_range

Resource Errors

resource_not_found

resource_already_exists

Business Logic Errors

transaction_not_capturable

insufficient_balance

payment_method_not_supported

Rate Limiting Errors

rate_limit_exceeded

Provider Errors

provider_error

provider_unavailable

Idempotency Errors

idempotency_conflict

Retry Strategies

Exponential Backoff

Rate Limit Handling

Circuit Breaker Pattern

Error Handling Best Practices

1. Implement Proper Error Handling

2. Log Errors Appropriately

3. Graceful Degradation

4. User-Friendly Error Messages

Monitoring and Alerting

Error Rate Monitoring

Set up alerts for:
  • Error rate > 5% over 5 minutes
  • Specific error codes (authentication, provider errors)
  • Rate limiting events
  • Circuit breaker state changes

Key Metrics

  • Error Rate: Percentage of requests resulting in errors
  • Error Distribution: Breakdown by error code and HTTP status
  • Recovery Time: Time to recover from errors
  • Retry Success Rate: Success rate of retry attempts
Always implement proper error handling and never expose sensitive information in error messages or logs.
Use idempotency keys for all state-changing operations to prevent duplicate processing in retry scenarios.