Logo GenukaGenuka Pay
Guides

Error Handling

Handle validation, authentication, provider, and business-rule failures cleanly.

Introduction

Your integration should treat Genuka Pay responses as operational signals, not just HTTP transport results. A clean implementation distinguishes validation failures, business refusals, and retryable upstream issues.

Validation Errors

Reject malformed payloads early and surface user-safe messages in your product.

Business Refusals

Treat KYC, limit, or policy failures as operational decisions, not retry candidates.

Retryable Failures

Retry transient provider or infrastructure issues with idempotency and clear correlation IDs.

Typical Error Envelope

Validation or Application Error
{
  "message": "Error description",
  "errors": {
    "field": ["Error message"]
  }
}

Common HTTP Statuses

CodeMeaning
400Malformed or invalid business input
401Missing or invalid authentication
403Request blocked or not permitted
404Resource not found
422Validation failure
500Internal server error
502Upstream or provider-side failure

Common Failure Shapes

Invalid Authentication

Authentication Error
{
  "message": "No application found."
}

Validation Failure

Validation Error
{
  "message": "Validation failed",
  "errors": {
    "amount": ["The amount must be at least 100"]
  }
}

KYC or Limit Refusal

Payment or payout initiation can fail when compliance status or transaction limits prevent execution.

Treat these as business failures that may require:

  • user or merchant notification
  • account review
  • KYC completion or escalation
  • internal support follow-up
  1. always log external_id, track_id, request route, and response code together
  2. distinguish validation failures from retryable provider failures
  3. retry only when the failure is clearly transient
  4. never blindly retry KYC or limit-related refusals
  5. keep asynchronous reconciliation separate from the request-response path

Operational recommendation

Use idempotency, request correlation, and webhook reconciliation together. Error handling should not stop at the first HTTP response when the underlying operation is asynchronous.

How is this guide?