Skip to main content

Overview

After sending a top-up request, poll the status endpoint until the transaction reaches a final state. The API typically processes requests in 5-30 seconds, going through PENDING → HANDLING → FULFILLED/REFUNDED states.
Critical: Properly handle all status values, especially UNKNOWN_ERROR. Never refund immediately on unknown status!

Check by Reference API

GET /v3/mobile/check-ref/:ref - Track using your reference

Check by ID API

GET /v3/mobile/check-id/:id - Track using topup ID

Status Values

Understanding each status is critical for proper handling:
See Check by ID API Reference for detailed status descriptions and use cases.

Basic Polling Implementation

Handling Different Status States

Background Status Polling

For better performance, poll status in background jobs:

Scheduled Recheck for UNKNOWN_ERROR

Set up daily cronjob to recheck uncertain orders:

Optimized Polling Strategy

Use intelligent polling intervals:

Best Practices

Wait for status to resolve to FULFILLED or REFUNDED within 24 hours before processing refunds.
Poll status asynchronously to avoid blocking user requests and improve performance.
Set maximum polling attempts (typically 60 = 5 minutes) and reschedule checks if needed.
Store status in your database to minimize API calls. Only query API when status is not final.
Always show the refund_message to users as-is. It’s in Arabic and explains the issue clearly.
When suggested_offers is present, show these alternatives to improve conversion.

Next Steps

Polling Strategies

Learn advanced polling optimization techniques

Webhooks

Set up real-time status notifications instead of polling

List Top-Ups API

View all your top-up transactions

Error Handling

Complete error handling reference