PesaGuard Docs
Developer documentation
Reconcile M-Pesa payments with evidence attached.
PesaGuard watches Safaricom Daraja callbacks as they arrive, matches them against your internal records, and keeps the reason behind every outcome. This documentation covers the concepts, the operations API surface and the delivery behaviour you will build against.
Getting started
Architecture in five minutes, then your first environment check.
Start →Concepts
Reconciliation, idempotency, tenants and the event pipeline.
Read →API reference
The operations API surface, errors, pagination and versioning.
Browse →Webhooks
Signed delivery, retries, dead letters and verification.
Read →Security
Tenant isolation, access control and how evidence is kept.
Read →Status
Live health of the services this documentation describes.
Open →PesaGuard reconciles M-Pesa (Safaricom Daraja) only today. Airtel Money, bank rails and point-of-sale feeds are planned — they have no adapter, tests or documentation yet, and these pages label them accordingly. See Concepts for what is live.
What the platform guarantees
- Idempotent writes. A retried callback never creates a second financial record.
- Deterministic matching. Amount, reference and timestamp tolerance decide the outcome — the same inputs produce the same result.
- Append-only evidence. Every decision keeps its reason, so review and audit read the record instead of memory.
- Enforced tenant isolation. Boundaries are enforced at the database layer, not by application convention.
Where to look first
If you are integrating the dashboard operations surface, start with the API reference and error handling. If you are wiring delivery into your own systems, read webhook delivery end to end before you write a consumer.