Payment webhooks: why orders get stuck on pending

Orders get stuck on "pending" when your store never receives, or cannot process, the message from the payment gateway saying the payment succeeded. That message is called a webhook. If it is missing, blocked or rejected, the customer may have paid while the order still waits. This guide explains why orders get stuck on pending after a payment webhook goes missing, and how to set up your store so they are found and fixed quickly.

A webhook is an automatic message one system sends to another when something happens. In payments, the gateway sends your store a webhook when a payment succeeds, fails, is refunded or is disputed. If you need help with an online store or checkout, our e-commerce service page explains how we work.

What a payment webhook is

When a customer pays, two things happen in parallel. The customer's browser is usually sent back to your store's confirmation page, and the gateway sends a webhook directly to your store's server in the background.

The webhook is the reliable signal. It comes straight from the gateway, does not depend on the customer's browser, and can be verified. A typical webhook contains:

• The event type, such as payment succeeded, payment failed or refund issued.
• References, such as the gateway's payment ID and often your own order reference.
• Details, such as the amount and currency.
• A signature, a code the gateway creates with a secret key so your store can check that the message is genuine.

Your store receives the webhook at a specific address on your website, checks it, finds the matching order and updates its status. When everything works, the customer sees a confirmed order and receives their confirmation email within moments.

Why the return page is not enough

Some stores confirm the order when the customer returns to the confirmation page after paying. This seems simpler, but it is unreliable on its own.

1. Customers do not always return. They may close the browser, lose their connection or have their phone lock while the payment page is open.
2. The return can happen before the result is final. Some payment methods take longer to complete, so the customer can return before the payment is confirmed.
3. Return pages can be visited by anyone with the link. Treating a page visit as proof of payment is not secure.
4. Redirects can fail. Browser settings, extensions or network problems can interrupt the return.

The return page should show the order status. The webhook should decide it.

This applies to both hosted payment pages and embedded checkouts, compared in our guide to hosted payment pages vs embedded checkouts.

Common reasons webhooks fail

When orders stay pending, the cause is usually one of these:

1. Wrong or missing webhook address. The address set in the gateway dashboard points to an old domain, a staging site, or no address at all after a website move.
2. Wrong secret key. The store checks the signature with a different secret than the gateway uses, so every webhook is rejected. This often happens when switching from test to live keys.
3. Blocked requests. A firewall, security plugin or server rule blocks requests from the gateway, or the address requires a login.
4. Form protection. Web frameworks protect forms against forged requests. The webhook address must be excluded from that protection, because the gateway cannot send your site's form token.
5. Errors in the store's code. A plugin conflict, an update or a bug causes the webhook handler to fail, so the gateway receives an error.
6. Slow processing. If the store takes too long to respond, the gateway may treat the webhook as failed.
7. Events not enabled. The gateway dashboard may need specific event types switched on for the store to receive them.
8. Order not found. The webhook arrives but the store cannot match it to an order, for example because references were not saved.

Most gateways keep a log of webhook attempts, with the response your store gave. That log is the first place to look when orders are stuck. If the log shows no attempts at all, the problem is usually the address or event settings. If it shows attempts with errors, the problem is usually on your server, such as a blocked request, a signature check failing or a bug in the handler.

Retrying and checking payment status

Gateways usually retry failed webhooks for a period, which helps with short outages. But you should not rely only on retries.

1. Respond quickly. Your store should record the webhook and reply with a success response as soon as it is safely stored, then do slower work in the background.
2. Handle repeats safely. Gateways may send the same event more than once. Your store should recognise an event it has already processed and ignore the repeat, so an order is never confirmed or emailed twice.
3. Check status directly. Most gateways let your store look up a payment by its reference. A scheduled task can check old pending orders this way and update them.
4. Never guess. Do not mark an order as paid or failed just because time has passed. Check with the gateway first.
5. Record what happened. Log each webhook and each status check, linked to the order, so your team can see the full history.

For stores built on Laravel, a scheduled command is a simple way to run these checks. Laravel's task scheduler lets you define recurring tasks in routes/console.php:

use Illuminate\Support\Facades\Schedule;

Schedule::command('payments:check-pending')
    ->everyFifteenMinutes()
    ->withoutOverlapping();

Here, payments:check-pending stands for your own command that finds orders pending longer than expected and asks the gateway for their status. The server needs a single scheduled entry that runs Laravel's scheduler every minute, as the documentation explains.

Monitoring for orders stuck on pending payment

The goal is to find stuck orders before customers do. A few simple measures make a large difference.

1. Alert on old pending orders. Send your team an alert when an order has been pending longer than a set time for your payment methods.
2. Watch webhook errors. Check the gateway's webhook log regularly, or set up its alerts if it offers them, so a broken endpoint is noticed quickly.
3. Compare gateway and store records. Regularly match successful payments in the gateway with paid orders in your store. Any payment without a matching paid order needs attention.
4. Test after changes. After a website move, a platform update, a new security rule or a change of keys, make a test payment and confirm the order updates.
5. Give support staff visibility. Let your team see the payment status and webhook history on each order, so they can answer customers without guessing.
6. Tell customers what is happening. If an order is pending while the payment is confirmed, send a clear message rather than leaving them wondering.

If you are building payments into a Laravel application, our guide on how to integrate a payment gateway into a Laravel app shows how to verify and process webhooks safely. For the wider picture, see how payment gateways work for online stores and our guide to taking payments on a travel booking website.

Summary

• Orders stay pending when the payment webhook is missing, blocked, rejected or cannot be matched.
• The return page is unreliable; the webhook should decide the order status.
• Check the webhook address, secret key, firewall rules, form protection and event settings first.
• Respond quickly, handle repeated events safely and check pending payments directly with the gateway.
• Monitor old pending orders, webhook errors and gateway totals, and test after every change.

A few checks and alerts turn a confusing problem into a routine one. If orders in your store are getting stuck on pending, you can tell us about it here.