Payment providers send asynchronous events that update order status, refunds and subscriptions. During compromise or maintenance, webhooks may be redirected, rejected, queued or replayed. Processing them blindly can duplicate side effects or mark orders incorrectly.
Preserve provider evidence and rebuild a trustworthy endpoint before replay.
Pause unsafe processing
Disable the compromised webhook endpoint or switch it to a controlled maintenance response through the provider/hosting layer. Keep provider events retained where the service supports retries.
Do not return fake success if WordPress did not safely process the event; that may stop provider retries and hide missing updates. Avoid returning verbose PHP errors.
Record pause time and affected event types.
Preserve configuration and events
Capture webhook endpoint, ID, enabled events, signing-secret metadata, creation/change time and recent delivery IDs/status. Do not copy signing secrets or full payloads into ordinary tickets.
Store representative payloads only through the provider’s secure incident process and minimise customer data.
Snapshot WooCommerce orders, notes and scheduled actions.
Verify provider ownership
Review payment-account administrators, sessions, API keys, payout settings and webhook audit history. Revoke unknown access and enable MFA.
Confirm the official endpoint and account/environment—test and live credentials must not be mixed. Use named accounts rather than shared logins.
Coordinate rotations with the payment owner.
Build a clean endpoint
Restore the gateway/plugin from a trusted maintained package in the clean WooCommerce environment. Configure canonical HTTPS URL, valid TLS and no page cache/challenge on the webhook route.
Restrict the endpoint according to provider guidance without relying solely on static IPs that may change. Keep WordPress/PHP errors private.
Do not copy a compromised plugin or wp-config.php.
Rotate webhook secrets
Issue a new signing secret or webhook endpoint through the provider, update the clean site securely, then revoke the old secret after validation.
Verify signatures using the provider’s official library/plugin and raw request body, including timestamp/replay protections where supported.
Never disable verification to make delayed events pass.
Inspect queued and failed deliveries
List provider event/delivery IDs, creation time, attempts and response codes. Compare with WooCommerce order notes and payment transaction IDs.
Some events can arrive out of order. Use provider object state and gateway logic rather than applying status in arrival order manually.
Do not bulk replay until idempotency is confirmed.
Check endpoint caches and security layers
Ensure CDN/page cache never stores webhook responses. Review Cloudflare/WAF/ModSecurity events for the exact route and provider attempts.
Create only a narrow rule for documented provider behaviour; do not allow every POST or bypass signature verification. Confirm the origin receives the raw body unchanged.
Monitor response time so the provider does not retry after WordPress already applied the event.
Test idempotency
In sandbox, deliver the same event twice and confirm WooCommerce records one financial/order effect. Test retries after a timeout and events for payment success, failure/refund as required.
Extensions for subscriptions or bookings may trigger additional scheduled actions. Verify them separately.
Record synthetic order/event IDs and remove test data.
Reconcile live orders
For the incident window, match provider transactions/events with WooCommerce orders, amounts, currency, refunds and fulfilment. Identify events acknowledged but not applied and orders changed without provider evidence.
Replay one controlled live event only through the provider’s official tool after approval. Monitor downstream email/stock/accounting effects.
Keep an audit mapping and protect customer data.
Verify ongoing delivery
Confirm new webhook events receive expected 2xx only after processing, order notes/status match provider state and failed queues clear without duplicates.
Monitor latency, signature failures and endpoint changes. Keep alert destinations separate from the compromised store.
Request urgent payment-webhook recovery when live transactions and order states diverge. Share event/transaction/order IDs securely—never secrets, full payloads, card data or customer exports.