M-Pesa payments that land once, on the right invoice.

Usually because the callback URL is not publicly reachable over HTTPS, the endpoint fails or responds too slowly, or the callback reaches the server but is never matched to the order. The durable fix is to stop depending on the callback alone: store the checkout request ID when you send the prompt, query the transaction status when no callback arrives, and reconcile against the statement.

Direct integration with Safaricom's Daraja API costs less per transaction at volume and gives you full control, but you own the paperwork, the callbacks and the reconciliation. An aggregator gets you M-Pesa and cards behind one integration faster, for a fee. The right answer depends on volume, whether you need cards, and who will maintain it.

Match on the M-Pesa receipt number first, then on the account reference, then on amount, phone and time, and send anything ambiguous to a short review queue. Work from the downloaded statement rather than SMS alerts, and make sure importing an overlapping statement can never apply the same payment twice.

Usually, yes. Most broken integrations have a working payment request and a weak confirmation path. The review finds which part is failing, and most fixes are in callback handling, status checks and reconciliation rather than a rewrite.

Yes. Card checkout, bank transfers and other mobile money sit behind the same rules: verify the evidence, apply each payment once, and reconcile against what actually settled.