Magento payment webhook failures: reconcile before replaying

Separate payment processing from notification delivery

A payment provider can complete an action while Magento has not yet processed the notification describing it. A webhook is an event sent from one system to another; it is not the payment itself. When the systems disagree, the first task is to establish the provider's actual outcome and the application's recorded outcome for the same transaction.

This guide concerns payment-provider notifications sent to a Magento integration. Adobe Commerce also uses the term webhooks for other extensibility features, with different behaviour. Identify the installed payment module, provider, environment and event flow before applying a troubleshooting procedure. Do not assume that every integration uses the same endpoint or order-state transitions.

Build one transaction timeline

Choose a known affected example and record the order reference, provider transaction reference, event identifier, event time and delivery attempts in authorised systems. Keep customer details and secrets out of shared incident notes. Distinguish when the payment occurred, when the notification was sent, when the endpoint responded and when Magento updated its records.

The sequence helps separate a delivery failure from a processing failure. A successful HTTP response from the endpoint may mean the event was accepted for later work, not that every downstream task completed. Conversely, an endpoint error may occur after some local work already happened. Check the integration's actual design and records rather than inferring the business result from one status code.

Check the provider and environment first

Confirm that you are looking at the intended provider account and test or live environment. Verify the registered destination against the module's supported configuration and current public domain. Migrations, restored databases or changed store URLs can leave an integration pointing at an unexpected destination. Avoid creating duplicate endpoints as a first response.

Check which event types the integration expects and whether the affected event was generated. Do not subscribe to every available event just to make delivery appear active. Extra events can add noise or unsupported processing. Use the installed module's documentation and record the configuration before making a scoped correction.

Distinguish reachability, authentication and processing

A delivery attempt can fail before it reaches Magento because of DNS, TLS, a firewall, a redirect or an unavailable route. It can reach the application but fail authentication or signature validation. It can pass validation but fail while updating the order or queueing follow-up work. Each boundary has different evidence and a different responsible component.

Inspect the provider's delivery result and correlate it with application and proxy logs. For Stripe, the official documentation requires verification against the original request body and the correct endpoint secret. Do not disable signature checks as a repair. If a proxy or application layer modifies the request, investigate that boundary while retaining verification.

Design recovery around duplicates and delayed events

Providers may retry delivery, and a manual resend can overlap with automatic attempts. Stripe documents that event order is not guaranteed and duplicate handling is necessary. A reliable integration must avoid applying the same business effect twice and must not blindly move an order backwards when an older event arrives late.

Before replaying events, establish which effects already happened and how the integration prevents duplication. Payment capture, invoice creation, stock handling, customer email and fulfilment release have different consequences. A replay that makes the dashboard green but sends duplicate fulfilment instructions is not a successful recovery. Use the provider and module's supported reconciliation process.

Protect financial and fulfilment decisions

Do not manually mark an order paid solely because a customer saw a bank notification or a webhook contains an unfamiliar status. Distinguish authorisation, capture, failure, cancellation and refund according to the provider and integration. Check amounts and currency as well as identifiers. Some payment methods complete asynchronously, so an intermediate state may be expected.

If the customer appears charged but no order is visible, use the payment-taken-but-no-order guide. If the browser showed a gateway error, use the 502/504 guide. These symptoms can overlap, but the recovery still needs a single reconciled transaction history.

Investigate background work after successful receipt

Some integrations process part of the event synchronously and defer other work. If the endpoint acknowledges receipt but the order does not reach the expected state, inspect the integration's queue, scheduled jobs and error handling where applicable. Do not assume that every payment module uses Magento consumers or cron in the same way.

Trace one event through the supported processing stages and look for a visible exception or backlog. The cron guide can help if scheduled work is implicated, but restarting unrelated workers without identifying the job can hide the original failure. Keep the event's acceptance and its final business completion as separate checkpoints.

Test a correction without creating live financial noise

Use the provider's supported test environment and the module's documented testing approach where available. Cover the normal event, an invalid signature, duplicate delivery, delayed processing and the relevant failure outcome. Verify that an acknowledged event is durably recorded or completed according to the design, and that failures remain observable rather than silently disappearing.

For a live incident, reconcile affected real records through an authorised process. Do not generate a new live charge simply to test a notification repair. Record which historical events need recovery, which have already completed and which remain uncertain. Any replay should have a bounded scope and a way to detect duplicate side effects.

Close the incident with business evidence

Check that the provider outcome, Magento order and financial documents agree, and that fulfilment has the intended status. Confirm customer notifications were appropriate and not duplicated. Document the earliest affected time and whether other transactions may need review. Fixing the newest event does not automatically repair an older backlog.

For an active payment-processing incident, use emergency support. Provide the module, provider, affected period and a redacted example; use secure access for the investigation. Once stable, integration planning can help turn the lesson into explicit retry, reconciliation and ownership requirements.

Technical references

Use the documentation that matches your installed version, payment provider and deployment.

• Stripe: receiving and handling webhook events

Continue with a related guide

• Magento checkout session expired: keep the journey intact
• Magento 502 and 504 errors: follow the failed request
• A practical Magento incident response plan

Explore the complete topic library →