Africa Payment Reconciliation Lab

What this system solves

ReconLab demonstrates what happens after a payment provider reports a transaction. It receives signed events, prevents duplicates, compares provider records with an internal ledger, identifies missing or incorrect entries, and gives operators a controlled recovery path.

Fintech engineering teams, payment operations teams, backend recruiters and businesses integrating multiple payment providers.

My role

I designed and built the reconciliation model, event-validation flow, exception states, recovery actions, audit trail and browser-based demonstration.

Capabilities demonstrated

• HMAC-signed webhook validation
• Idempotency and duplicate-event prevention
• Provider transaction and internal-ledger matching
• Missing-ledger, amount-mismatch and duplicate-webhook scenarios
• Exception review and controlled recovery
• Provider-health and audit visibility

System flow

Important decisions

A payment-provider timeout is not treated as proof that an operation failed. Stable idempotency keys make retries safe, while reconciliation separates provider evidence from the platform’s internal ledger instead of assuming they always agree.

Beyond the happy path

The system models duplicates, delayed records, mismatched amounts and missing ledger entries as expected operational states. Failed cases remain visible until they are reviewed or recovered.

Testing and evidence

The repository includes 12 automated tests covering reconciliation and failure-handling behavior. All figures shown in the demonstration are synthetic test-environment values.

Current limitations

Production extension path

A production version would add authenticated provider adapters, persistent database migrations, encrypted secret management, queue workers, reconciliation schedules, monitoring and role-based operational access.

Tools and concepts