Payment providers like Paystack and Stripe send webhooks to notify your server when a payment succeeds. In a replay attack, an attacker captures a legitimate webhook payload and re-sends it multiple times — tricking your app into thinking a payment happened again, potentially crediting wallets or fulfilling orders multiple times.
Think of it this way
A webhook is like a payment receipt. A replay attack is like photocopying that receipt and handing it to different cashiers at the same store, each time getting a refund or goods as if you paid again. If the cashier does not check the receipt's date and serial number, they will keep honouring it.
The attacker intercepts or records a legitimate Paystack/Stripe webhook payload (which is just a JSON HTTP POST). They then resend that exact payload — possibly days later or thousands of times — to your webhook endpoint. If your server processes webhooks without checking: (1) the cryptographic signature, (2) whether the event ID was already processed, and (3) the timestamp freshness — it will credit the payment over and over.
Scenario 1
A user makes a ₦5,000 Paystack top-up. They intercept their own webhook and replay it 20 times against your /webhook/paystack endpoint. Each replay is processed as a new payment, crediting ₦5,000 twenty times — ₦100,000 in total from a single ₦5,000 payment.
Scenario 2
An attacker replays a successful order webhook 50 times on an e-commerce platform that does not track processed event IDs, receiving 50 shipments of a product they paid for once.
Anomira monitors your webhook endpoint for the same Paystack/Stripe event ID arriving more than once, or the same payload hash being submitted within a short window, and raises an alert before duplicate processing can occur.
See this attack in your live API traffic
Anomira detects webhook replay attack automatically — no configuration needed.