The hardest question a procurement team asks is not "can you build it?" It is "who owns it when payments break at 2am?" For mobile money, the answer comes down to a handful of details most integrations get wrong.
Idempotent callbacks
M-Pesa callbacks can arrive more than once. If your handler is not idempotent, a single retried callback double-credits a ticket or a wallet. Every callback path must be safe to replay, key on the transaction ID, record what you have already processed, and make the second delivery a no-op.
Integer money
KES is handled as integers. Floating-point money is a reconciliation bug waiting to happen. Keep amounts as integers end-to-end and format only at the edges.
Proactive token refresh
Access tokens expire. Refreshing reactively, only after a request fails, turns a routine expiry into a failed checkout. Refresh proactively and handle the race so a token rotation never drops a payment mid-flight.
Why this is rare
Few US or global firms can take mobile-money payments correctly. Pairing a first-class Daraja rail with Stripe for international cards is a differentiated capability, proven in Tukutane and Kipaji, and it is the kind of thing that only holds up when one team owns the payment path end-to-end.
This post is part of our ongoing engineering writing. The full knowledge hub goes deeper on each layer.