Checkout Not Working — Store Payment Failure Triage
Customers reach the last step and the payment fails, or the checkout loops, or orders vanish after paying. This is revenue-critical triage in a strict order — because on a store, the checkout is the most expensive page in the business.
Checkout failure is measured in money per hour, which changes how it is triaged. The order matters, and the first check costs nothing: the payment gateway's own status page. Stripe, PayPal and the rest have outages like everyone else, and a meaningful share of "our checkout is broken" panics dissolve there — the honest first move is ruling out the provider before debugging your code. When the gateway is healthy, the layer-hunt begins, and it runs in evidence order, not guess order.
On WooCommerce the failure layers stack: the gateway plugin and its keys (rotated, expired, test-mode-left-on), conflicts with another plugin — classically one just updated, which links to the broken-update pattern — theme or JavaScript errors at exactly the last step, certificate problems that make gateways refuse the connection, and the sneaky one: webhook or secret mismatches that let customers pay but leave orders stranded as "pending payment" forever. Each layer has its own test, and the triage order exists so the cheap tests run first.
Shopify's shape differs, and the honest boundary matters: the core checkout is Shopify's platform — most injuries live in your layer, which is apps and theme. App conflicts (each installed app adds scripts and logic), theme customizations that break checkout extensibility, payment-provider authentication, and rate or API limits. What is genuinely platform-side gets named as such rather than billed as fixable — the Shopify page covers that boundary in calm times.
The method end to end: reproduce in test mode, capture the console and network evidence, isolate by disabling layers in the safe order, fix at the owning layer, then verify with a real (small) transaction — payment captured, order recorded, confirmation email delivered, refunds working. The stalled orders from the broken window get reconciled too, because they are real customers with real money. Cross-links for the calm aftermath: WooCommerce, ecommerce development. One senior developer, async-first, IST timezone; first response inside one business day — and checkout work jumps the queue because the meter is running. The goal of the first hour is simple: fixed, or safely contained while the fix is built. You are never left staring.
While you wait — the first 15 minutes
- Check the payment gateway's status page first — Stripe, PayPal, Razorpay incidents are common, public, and free to rule out
- Capture the exact failure: which step, what the error says, a screenshot — the last screen a customer sees is the trailhead
- Note when it last worked and what changed since: updates, new apps or plugins, theme edits, certificate renewals
- Run one test-transaction if test/sandbox mode exists — evidence without spending a customer's money
- Do not install a second payment gateway on top while the first is failing — double-charge risk and two mysteries instead of one
- Check for stranded orders in the admin — "pending payment" entries are real customers whose money may have moved
- Gather admin, gateway dashboard and hosting access, then send the failure notes — the exact error text is the fastest evidence there is
These steps make every later fix cheaper. Do them in order, note what you changed, and include the notes in the brief.
What the engagement covers
Scope, stated plainly.
- Layer-by-layer triage in the safe order: gateway status, configuration and keys, plugin/app conflicts, theme and JavaScript, certificates
- Webhook and secret-key reconciliation — the fix for orders that stall as pending after successful payment
- Test-mode reproduction and a verified live transaction: paid, recorded, confirmed by email, refundable
- Conflict isolation done reversibly, so the hunt does not create a second outage
- Reconciliation of orders stranded during the broken window, with customer-facing wording if apologies are owed
- A prevention note: checkout gets tested after every change that touches it — discovered-broken is the failure mode this kills
Honest limits
What to do instead.
A one-person senior practice is the right tool for a lot of emergencies and the wrong one for a few. The wrong ones, honestly:
- Chargebacks and payment disputes with customers or the gateway — that is process and paperwork, not code
- PCI compliance certification — guidance pointers yes, the audit and its paperwork are a separate discipline
- A 24/7 on-call promise — one senior, async-first, first response inside one business day, urgent-slotted
- Gateway account approvals and underwriting — the provider's process, on the provider's clock
- Conversion-rate improvement — this page fixes function, not persuasion; a working checkout and a high-converting one are different projects
After the emergency: stop the next one.
Every rescue ends with the same question — why was this able to happen? The maintenance retainer exists to make the answer boring: updates applied, backups tested, monitoring in place.
Questions
Asked in emergencies.
Usually yes — this is the webhook story. The payment captured at the gateway, but the notification back to the store failed (wrong secret, blocked URL, plugin conflict), so the order stalled as "pending payment". Reconciling means matching gateway transactions to the stalled records and completing them properly. It is tedious, exacting work, and it is part of the triage — those are real customers, not error noise.
Rarely the right first move. Gateway failures trace to configuration, keys, webhooks or conflicts more often than to the gateway itself — switching mid-emergency adds a new integration to a burning stack. The triage finds the failing layer first; if the gateway is genuinely the problem, the switch is then a scoped project, planned — not a panic install at 2pm on a trading day.
Every major gateway has a test/sandbox mode with dummy card numbers, and it exists for exactly this. Test mode reproduces the checkout path end to end without moving money, which is how triage gathers evidence safely. The final verification after the fix is the one place a small real transaction is worth its few cents of gateway fee — it proves the full pipeline including the parts test mode can stub.
Because the store never received the webhook — the gateway's callback confirming the money moved. The customer paid and left; the order record waits for a confirmation that never arrived. Causes: rotated webhook secrets, URL changes after a migration, or a plugin conflict swallowing the call. It is revenue-critical precisely because the money moved while the store is blind — and it is fixed by reconciling the past and re-verifying the callback path.
Other rescue work
WordPress Emergency Support
Your WordPress site is down, broken, or erroring and it cannot wait for the normal queue. Urgent work is slotted ahead of it — with an honest first response and realistic expectations.
WordPress Hacked Recovery
A hacked site is an incident, not a scramble. Recovery follows a standard sequence — isolate, backup, clean, patch, harden, rescan, monitor — with timelines scoped for realism, not false promises.
Website Takeover — When Your Developer Disappears
Your developer vanished, or the relationship ended badly, and you are locked out of your own website. This rescue recovers access, audits what you actually own, and takes the site back — properly.
WordPress White Screen of Death — Diagnosis and Rescue
The page is blank, the admin may be gone with it, and nothing tells you why. The white screen is almost never mysterious — it is a PHP fatal error hiding in plain sight, and it has a specific, findable cause.
"Error Establishing a Database Connection" — Rescue
That single error line means WordPress reached your server but could not open its database — a dead end with roughly four known doors. Finding which door is the whole job, and each has a different fix.
WordPress Emails Not Sending or Landing in Spam
Contact forms that never arrive, order confirmations in the spam folder, password resets that vanish. WordPress mail failure is an infrastructure problem wearing a plugin costume — and the fix lives at the email layer, not in the form.