Payment Gateway Downtime Monitoring: Checkout, Webhooks and Heartbeats

The most damaging e-commerce failure is the quiet one: the home page loads, the product pages load, and the "Pay" button fails. A simple "is the site up?" check reports green while revenue drops to zero. Payment gateway monitoring is about watching the path money takes, from the checkout page to the provider and back through the webhook that marks the order as paid. This guide covers what to monitor, how to do it without moving real money, and how to design alerts that someone will act on.

The payment path has four places to fail

Customer -> your checkout page -> payment provider (card form, redirect or API)
         -> provider confirms -> webhook to your server -> order marked paid

1. Your checkout page. It can error, load without the payment form, or render an error message with a 200 status.
2. Your integration with the provider. Wrong or expired API keys, a changed SDK, blocked outbound requests, TLS or PHP incompatibilities.
3. The provider itself. Incidents happen at every provider; the question is how fast you find out.
4. The return path. Webhooks that never arrive, arrive late or are rejected by your server leave orders unpaid, shipping delayed and customers anxious.

Each one needs a different kind of check.

Check 1: Monitor the checkout page, with a keyword

An HTTP monitor that only checks for status 200 is not enough, because a half-broken checkout page often still returns 200. Use a keyword check, which fetches the page and looks for specific text.

• Pick text that appears only when the checkout is healthy: the label of the pay button, the name of the payment method, or a heading from the form. Avoid text that is also in the error message.
• If you can, set a second check that alerts when an error phrase appears, such as the gateway's "unavailable" message that your store shows. Whether you can alert on "text must be absent" depends on the tool; with a presence check, choose a string that exists only in the healthy state.
• Choose a page that can be fetched without logging in. A cart page with an item in it needs a session; a checkout for a logged-out visitor with an empty cart may redirect away. Test the URL with the HTTP Status Checker and confirm what the response looks like for a fresh visitor.
• Create a dedicated hidden product or a dedicated payment-method page for testing if your platform allows, so your monitor does not depend on a promotional product being in stock.

Many hosted payment forms are loaded by JavaScript inside an iframe, so the card form will not appear in the raw HTML a monitor fetches. In that case the keyword check confirms that your checkout page and script references are present, not that the form renders. That is still valuable, but be honest about its limits, and pair it with the other checks below. A full browser-based synthetic test is a different class of tool; see synthetic vs real user monitoring.

Check 2: Watch the provider's status, and your connection to it

Most providers publish a status page, and many offer subscription alerts by email or webhook. Subscribe to them, but do not rely on them alone, since a status page can lag behind real problems and says nothing about your credentials or integration.

Add checks for the endpoints that matter to you:

• Your own API health endpoint that makes a harmless authenticated read call to the provider, for example fetching your account or a list of recent payment methods with a restricted key, and returns an error if it fails. Monitoring this endpoint verifies that keys work and outbound connections are allowed. Do not put a powerful secret key in an uptime monitor header; use a read-only or restricted key and see how to monitor API endpoints.
• TLS expiry for your own domain, because certificates expiring on the page that hosts the checkout will break payments. The SSL Checker shows the date, and monitoring can alert you ahead of it.

Check 3: Monitor the webhook endpoint

A webhook is an HTTP request from the provider to a URL on your site, for example https://example.com/wp-json/gateway/webhook or https://example.com/hooks/payments. If that URL is down, blocked by a firewall, or returns an error, payments succeed at the provider while your store never learns of it.

What to do:

1. Monitor the URL for availability. A webhook endpoint typically accepts only POST requests with a valid signature, so a plain GET may return 405 or 400. Decide what a healthy answer looks like. A monitor can be configured to treat a specific status code as acceptable; check how yours lets you set that. A GET that returns 405 consistently still proves the server, TLS and routing work. Do not remove signature verification to make monitoring easier.
2. Read the provider's delivery log. Most dashboards show each webhook attempt with the response code from your server. A rising count of 4xx or 5xx is an early warning, and many providers retry failed deliveries for a period of time, with details in their documentation. Check the current retry policy of your provider rather than assuming.
3. Check the firewall. Make sure the host firewall, WAF or CDN rule does not challenge or block the provider's requests. Provider IP ranges and user agents are published in their docs.
4. Verify signatures and handle duplicates. Retries mean your handler may see the same event twice. Make processing idempotent: store event IDs and ignore repeats.
5. Respond fast. Return a 2xx quickly and do heavy work in a queue; slow handlers can time out and trigger retries.

Check 4: A heartbeat for payment events

Availability checks tell you the endpoint can answer. They do not tell you that events are actually flowing. A heartbeat monitor solves the opposite problem: it alerts you when something that should happen regularly stops happening.

The pattern:

1. Create a heartbeat monitor with cron monitoring and copy the ping URL it gives you.
2. In your webhook handler, after you have successfully processed a payment event, send a request to that URL.
3. Set the expected interval to the longest quiet period that is normal for your store. A shop that takes an order every few minutes in the daytime can use a short window; a low-volume shop should use a longer one, or only enable the monitor during opening hours via a maintenance window, so nighttime silence does not page anyone.
4. If no ping arrives within the window, you get an alert: either payments stopped, or the webhook stopped reaching your handler.

A sketch in PHP, placed after the order has been marked paid:

// after the payment event is verified and the order updated
@file_get_contents('https://<your-heartbeat-url>', false, stream_context_create([
    'http' => ['method' => 'GET', 'timeout' => 3],
]));

Keep the timeout short and ignore failures, so a monitoring hiccup can never break order processing. For storefronts without custom code, run a scheduled script that queries recent paid orders and pings the heartbeat only if at least one exists in the last window, for example with a cron job:

*/15 * * * * /usr/local/bin/check-recent-orders.sh && curl -fsS -m 5 https://<your-heartbeat-url> > /dev/null

where the script exits non-zero when no recent paid order exists. See cron job heartbeat monitoring for the general approach.

A second heartbeat is useful for the opposite failure: orders stuck in "pending payment" or "authorized" for too long. A small job that counts them and only pings when the count is below a threshold catches reconciliation problems early.

Alert design

• Route payment alerts to a different channel than informational ones, and to a person who can act. Use email plus a chat or webhook integration.
• Confirm before paging. A single failed check can be a network blip. Use failure confirmation as discussed in reduce false alerts.
• Check frequently enough. A 5-minute interval means you learn of a total failure within roughly that window plus confirmation. See how often should you monitor a website.
• Write the response in advance. For "checkout down", the runbook might be: confirm on a test device, check provider status, check recent deploys, switch to a backup payment method if you have one, pause ad campaigns, update the status page.
• Have a fallback method. If you take cards and a wallet or bank-transfer option, a second path keeps some revenue flowing when one fails.

Cost of getting it wrong

A payment failure that goes unnoticed for hours costs the lost orders plus ad spend and support time. To put numbers on it, use how to calculate ecommerce downtime cost. For WooCommerce-specific failures, see WooCommerce checkout errors troubleshooting, and before big sales use the Black Friday readiness checklist.

Next steps

• Create keyword checks for your checkout with the uptime monitor.
• Add a payment-event heartbeat using cron monitoring.
• Verify the status and headers of your webhook URL with the HTTP Status Checker.
• Publish incident updates with a status page.
• Read how to monitor API endpoints.

FAQ

Can I monitor a payment gateway without making a real payment?

Yes. Monitor your checkout page, your webhook endpoint and an authenticated read-only provider call, and use the provider's test mode for any synthetic purchase. Never automate real charges.

Why does my checkout monitor pass when payments fail?

A status check only proves the page returned 200. A hosted card form loaded by JavaScript or a failing provider call can break payments without changing the HTML status. Use keyword checks, webhook monitoring and a heartbeat on payment events.

How does a heartbeat help with webhooks?

Your handler pings a unique URL each time it processes a payment. If pings stop for longer than your expected window, you are alerted that payment events are no longer arriving or being handled.

What should I do if the provider is down?

Check their status page, tell customers through your own status page or a site banner, offer an alternative payment method if you have one, and pause paid traffic if checkout cannot complete.

How often should I check my checkout page?

Often enough that an outage is found within minutes. A 5-minute interval with failure confirmation is a reasonable baseline, and you can add temporary extra checks during sales.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.