Online Payments or Payment Webhooks Stopped Working: What to Check Before You Lose More Orders

When online payments stop working, first work out which of two failures you have: customers cannot pay at all, or customers pay successfully but your site never marks the order as paid. The first is a problem between your checkout and the payment provider; the second is almost always a failed webhook, the message the provider sends back to your site after a payment. Both can be narrowed down from the provider's dashboard in about 10 minutes without changing any settings.

This guide is for an owner whose developer is not available right now. It uses Stripe and PayPal as examples because their behavior is publicly documented. The fix itself is developer work, the kind covered by our e-commerce development and customization service, but the checks below let you hand over a clear picture instead of "payments are broken".

What does it usually mean when online payments stop working?

It usually means one of two separate links has broken: the link from your checkout to the provider, or the link from the provider back to your site.

Failure 1: customers cannot pay at all

The checkout shows an error, spins forever, or refuses every card. Stripe lists three reasons a payment can fail: the customer's bank declines it, fraud tooling blocks it, or your site sends an invalid request. One declined card is normal. Every customer failing at once points to your site, your account, or the provider.

Failure 2: customers pay, but orders are not marked paid

The money shows in the provider's dashboard and the customer has a receipt, but your order list says "pending" and no confirmation email goes out. The payment worked. The notification back to your site did not.

What is a payment webhook, and what happens when one fails?

A webhook is an automatic message a payment provider sends to a specific address on your website when something happens, such as a payment succeeding. PayPal describes webhooks as HTTPS posts from PayPal to an endpoint on your server. Your site must reply with a success code (an HTTP status in the 200 range) to confirm receipt.

If it does not, the provider tries again. As of October 6, 2026, Stripe's webhook documentation says it retries live deliveries for up to three days with increasing gaps between attempts, and PayPal's says it reattempts delivery up to 25 times over the course of 3 days. If the site is fixed inside that window, pending messages can still arrive.

Stripe also counts a redirect, an SSL/TLS certificate problem, or a slow response as a failed delivery. So a certificate that lapsed overnight, or a change that redirects your address to a new domain, can stop orders being marked paid while the checkout still takes money.

What can I safely check in about 10 minutes?

You can safely read status pages, dashboards, emails and error messages, as long as you change nothing. Work through these in order and write down what you see.

1. Capture the error. Open your checkout in a private browser window and note the exact error text, the time, and any certificate warning in the address bar. Take a screenshot. Do not make repeated real payments to test.
2. Check the provider's status page. Stripe publishes status.stripe.com and PayPal publishes paypal-status.com. An open incident means the problem may not be yours to fix.
3. Look at recent payments in the provider dashboard. Note any failed or declined payments and the reason shown. If there are no attempts at all while customers report errors, your site is probably not reaching the provider; Stripe notes that invalid requests typically do not appear as payments in the Dashboard.
4. Look at webhook deliveries. In Stripe, open Workbench, choose your endpoint under Webhooks, and open the Event deliveries tab, which marks each event Delivered, Pending or Failed with its HTTP status code. PayPal has a Webhook Events dashboard in its developer area. Note the first failure time and the error shown.
5. Read account notices. Check the dashboard home page and the account owner's inbox, including spam, for a verification request or a restricted payouts notice. Reach the dashboard by typing its address yourself, not through an email link.
6. Check what expired. In your hosting or domain control panel, look at the SSL certificate expiry date and for overdue bills. On the provider's API keys page, look for a key marked expired or recently rotated. Stripe states that a request made with an expired key returns an authentication error.
7. Ask what changed. A plugin or theme update, a new domain, a hosting move or a new security plugin in the last few days is very often the cause.

What should I not do?

Do not change anything in the provider's developer settings, because the most tempting fixes can turn a partial outage into a total one.

• Do not regenerate, rotate or expire API keys. Stripe's documentation says rotating a key revokes it and that code using an expired key can no longer make API calls. A live secret key you create is shown only once, and the new one must then be installed in your site's configuration.
• Do not switch between live and test (sandbox) mode. In test mode your checkout cannot accept real cards.
• Do not delete, recreate or roll the secret of a webhook endpoint. Each endpoint has its own signing secret that your site checks; a new one will not match until the site is updated.
• Do not ask customers to pay again before checking the provider dashboard. If the first payment succeeded, you will be issuing refunds.
• Do not bulk-update plugins or restore a backup. A restore can erase orders taken since the backup.

What should I do about orders that were paid but not marked paid?

Treat the provider's dashboard as the record of who has paid and reconcile it against your order list by hand until the fix is in. Match each successful payment to an order by amount, time and customer email, fulfill the ones that were paid, and confirm with those customers.

Keep a list of every order you handled manually. Once the webhook is repaired, held messages may be delivered or resent, and your developer needs that list so nothing is fulfilled or emailed twice.

When should I call a developer, and what should I send them?

Call a developer as soon as the status page is clear and the failure continues, because every remaining cause sits in your site's code, server or configuration. Replacing a key, renewing a certificate, correcting the webhook address, reading server logs and resending missed events are all developer tasks. Send:

• Which failure you have: cannot pay, or paid but not marked paid.
• When it started, and the last order that worked normally.
• The exact error text and screenshots from the checkout.
• From the webhook deliveries page: the endpoint address, first failed time, and status code or error.
• Any notice or email from the provider, forwarded in full.
• What changed recently, and your list of manually handled orders.

Give access by inviting the developer as a team member in the provider dashboard and hosting account. Do not send API keys or passwords by email or chat.

How do I stop it happening again?

Most payment outages are prevented by monitoring and clear ownership rather than new code. Ask your developer for an alert when webhook deliveries start failing, and a daily reconciliation that compares the provider's successful payments with your paid orders. Set calendar reminders for anything that expires: SSL certificates, domains, hosting plans and keys with a scheduled rotation. Make sure provider notices go to a mailbox more than one person reads, and that two people can sign in to the provider account.

Test a real checkout after every site update. Checks like these belong in a maintenance agreement; our guide to software maintenance and support explains what one should cover.

Quick answers

Why are customers paying but my orders still show as unpaid?

The payment succeeded at the provider, but the webhook that tells your website about it is failing. Check the webhook deliveries page in your Stripe or PayPal dashboard for failed events and the error shown, then pass that to a developer.

How long do Stripe and PayPal keep retrying a failed webhook?

As of October 6, 2026, Stripe's documentation says it retries live webhook deliveries for up to three days with exponential backoff. PayPal's documentation says it reattempts delivery up to 25 times over the course of 3 days.

Should I regenerate my API keys if payments stop working?

No. Rotating or expiring a key stops your website from talking to the payment provider until the new key is installed in the site's configuration, which can turn a partial problem into a complete outage. Leave key changes to a developer.

Can an expired SSL certificate stop payment webhooks?

Yes. Stripe's documentation lists a TLS error as a webhook delivery failure, so it cannot deliver events to a site whose certificate is invalid. Customers may still be charged while your site never hears about it.

How do I know if the problem is the payment provider and not my website?

Check the provider's official status page, such as status.stripe.com or paypal-status.com, for an open incident. If the status page is clear and the failures continue, the cause is most likely in your own site, account or configuration.

Conclusion

A payment outage is far easier to fix once you know whether customers cannot pay or whether payments are going through and your site is not hearing about them. Read the status page, the payments list, the webhook deliveries and your account notices, write down what you find, and leave keys, modes and endpoints alone.

If you have no developer available, you can contact Entrant Technologies with the details listed above and we will take a look.