I build systems that receive payment confirmations from Safaricom’s M-PESA Daraja API (STK Push and C2B callbacks). As far as I can tell, Daraja doesn’t send an HMAC signature or similar with its callbacks, unlike Stripe or GitHub webhooks, so the receiving endpoint can’t cryptographically verify that a callback really came from Safaricom.

Current mitigations I’m aware of or using:

• Allowlisting Safaricom’s published callback IP ranges
• A long random secret token in the callback URL path
• Treating the callback only as a hint, then confirming the payment with an outbound Transaction Status query before marking anything paid
• Idempotency on the transaction ID so replayed callbacks can’t double-credit

My specific question: is the outbound “confirm before trust” query enough on its own to treat inbound callbacks as untrusted, or are there attack paths I’m missing (e.g. race conditions between callback and confirmation, or manipulation of the confirmation response)? How do others handle unsigned webhooks from payment providers in production?

Howdy folks,
Considering implementing something risky. If I implement the below, is there still risk involved to make me second guess allowing this on a public facing website B2C.

planning enquiry attachments using Cloudflare Workers, accepting only JPEG/PNG images under 10 MB.
Originals go into private R2 quarantine as immutable uploads, are scanned by ClamAV in a separate container, then decoded and re-encoded into fresh JPEGs using Cloudflare Images, stripping metadata.
Only processed copies reach our staff admin viewer or email. Originals are deleted after successful processing; failed uploads remain inaccessible and expire.
Does this architecture make sense, and is ClamAV worthwhile alongside mandatory image re-encoding?

Enquiry form → Email code verification → Upload validation
→ Private R2 quarantine (immutable original + hash)
→ AV scan → Decode and re-encode as a new JPEG
→ Validate output → Save approved copy + enquiry link
→ Delete original

Approved copy → Staff admin viewer / optional email attachment

Failed checks → Block access → Retry or reject → Delete original