Safer callbacks
Use idempotency, transaction verification and durable event history.
Payments
WaterPesa for payment & fintech partners
A normalized water-payment and reconciliation layer with idempotent callbacks, unmatched-payment queues, reversals, settlements and audit-ready allocation history.
M-PESAAirtel MoneyReconciliationAPI
Answer first
What this means in practice
WaterPesa answer
WaterPesa treats payment-provider events as evidence, not final accounting truth. A provider transaction is normalized, verified and then allocated to one or more water accounts or bills through explicit reconciliation.
Outcomes
Why this matters
Fewer lost payments
Unknown references become unmatched-payment work, not silent write-offs.
Cleaner settlement
Separate customer-payment matching from merchant settlement reconciliation.
Capabilities
What the workflow includes
Payment adapters
Normalize rail-specific callbacks, status queries, reversals and receipts.
Allocation model
Attach normalized payment value to explicit bills/accounts through auditable allocation records.
Fraud controls
Preserve duplicate, reversal and verification evidence for review.
Developer sandbox
Expose documented demo payloads and idempotent webhook behavior for partner integration.
“For every cubic metre entering the system: where did it go, what happened commercially, what action was taken, and what measurable result followed?”WaterPesa product invariant · derived from the connected Notion product specification
FAQ
Questions this page should answer
Does a payment callback mark a bill paid immediately?
Not automatically. The event should be verified, normalized and allocated to the correct account/bill before final accounting state changes.
Who should own the settlement account?
The target model keeps the utility or provider as merchant owner unless a future legal and commercial arrangement explicitly changes that.
How are reversals handled?
With compensating events and allocation updates, not by deleting the original transaction.
Keep exploring