09 Oct 2026

When a payment callback never arrives: a recovery checklist

A customer says they transferred NGN 25,000. Your order still says “awaiting payment”. Releasing the goods from a screenshot creates an avoidable risk; asking them to pay again can create a second payment.

Here, “callback” means the server-to-server payment notification, also called a webhook. A browser redirect is a separate signal. This guide complements our duplicate-callback guide with a recovery path for silence. The checklist is a provider-neutral design for Nigerian commerce teams, not a statement of Velvpay’s live service guarantees.

1. Keep an unresolved payment recoverable

Before presenting payment instructions, save the merchant and order identities, unique payment-attempt reference, expected NGN amount in explicitly recorded units, provider transaction ID when available, and creation time. Persist the payment state, last check, next check and retry count in your database.

A request timeout means the outcome is unknown. Keep the attempt pending until verified evidence resolves it. Restarting a worker must not lose the investigation. Show customers “We’re confirming your payment” and a support reference; do not automatically prompt another transfer.

2. Ask the provider from your server

Use the provider’s documented, authenticated status lookup with the stored reference. Keep credentials on the backend. Match the merchant scope, transaction, reference, currency and expected amount before applying a confirmed payment.

Read the transaction’s status, not merely a successful HTTP response or outer API envelope. Treat status names and transitions as provider-specific, and follow the chosen provider's documented server-side verification rules.

Never fulfil solely from a customer screenshot or client redirect. A pending result, an unavailable lookup or an unexplained mismatch should retain an unresolved or review state.

3. Retry checks without flooding the service

Run recovery in a background worker with request timeouts, capped exponential backoff and jitter: increase the delay between attempts and randomise it so many workers do not retry together. Respect the provider’s rate limits and documented retry guidance. Authentication or configuration failures need an alert, not endless retries.

Set a retry budget and an escalation threshold appropriate to your checkout. When fast checks stop, hand the case to reconciliation or manual review. Exhausting retries must not silently convert “unknown” into “failed”.

4. Diagnose delivery and apply one business outcome

Check the configured webhook URL, environment, reachability, authentication failures and response logs. Where the provider supports delivery inspection or replay, use its documented controls after fixing the cause; do not assume every provider exposes the same tools.

Send verified lookup results and authenticated callbacks through the same payment-transition logic. A callback arriving after recovery must not credit or fulfil again. Keep the database-enforced idempotency and recoverable fulfilment described in the companion guide. Do not overwrite a confirmed payment with an older pending result. Apply the provider’s permitted state transitions; handle later refunds or reversals as separate operations.

5. Reconcile late payments explicitly

Scan unresolved attempts on a schedule, including cases that exceeded the fast-retry budget. Give each exception an owner and next-review time. Retain references, observations and decisions without logging credentials.

If confirmation arrives after an order or temporary account expires, record the verified payment and review the order separately. Confirmation arriving late does not establish that the provider accepts transfers into an expired account; verify its expiry and late-transfer rules. Do not erase the payment or automatically dispatch unavailable stock. Route mismatched amounts, unknown references and genuinely separate second payments for review under your refund and fulfilment policy.

Payment confirmation also needs a separate settlement check. Reconcile settlement reports and bank credits separately; a successful transaction lookup does not prove money reached your bank account.

6. Test the whole recovery path

Before rollout, verify that:

A lost webhook is recovered through authenticated lookup.
Worker restarts preserve pending cases and retry schedules.
Rate limits and timeouts lead to controlled retries and escalation.
Concurrent lookup and late callback produce one credit and fulfilment.
An older pending observation cannot undo a confirmed payment.
Expired orders and amount mismatches reach an owned review queue.
Confirmed payments and bank settlements remain distinguishable.

For an evaluation starting point, see the Velvpay NGN Collection Starter. It illustrates fixed-amount temporary NGN accounts, reference-based lookup and webhook authentication. It is offline/mock-tested, not live-certified. Live merchant/provider configuration, delivery SLAs and production behaviour must be verified before customer use.