Building Payment Infrastructure for Low-Connectivity Environments

The Problem

Most payment infrastructure is designed for environments with reliable connectivity, predictable latency, and users familiar with digital transaction flows. When deployed in markets where these conditions do not consistently hold, systems that function perfectly in development produce an unacceptable rate of failed or ambiguous transactions in production.

Design Principles for Low-Connectivity Contexts

1. Idempotent transaction initiation

Every payment initiation request must be idempotent — if the user submits the same request twice because the first appeared to fail, the system must not double-charge. This requires generating a unique reference before calling the payment provider and checking for an existing record before creating a new one.

2. Separate initiation from verification

Payment initiation (generating a payment link) and payment verification (confirming a transaction succeeded) should be treated as separate, asynchronous operations. Never grant access based on a frontend callback alone. Always verify server-side via the payment provider's verification API.

3. Webhook as primary confirmation signal

The callback URL that users return to after payment should be treated as a user experience endpoint only — it triggers a verification call, but the authoritative confirmation is the provider webhook. Implement webhook handling with HMAC signature verification to prevent spoofing.

4. Graceful degradation for connectivity failures

Design the callback and verification flow to handle cases where the verification call cannot reach the provider. Store the reference and implement a retry mechanism. Users who paid and did not receive access should have a resolution path that does not require manual intervention.

Implementation Notes

For NGN-denominated transactions with Paystack, amounts in the API are expressed in kobo (1 NGN = 100 kobo). Ensure unit conversion happens server-side, not on the frontend. The verification endpoint should be called even after a webhook arrives — treat each as a confirmation signal rather than relying on either alone.