What matters first: The final redirect loads order details using a key, session and endpoint. A 404, blank page, redirect loop or fatal error can occur after payment and create dangerous ambiguity.
What this symptom actually tells you
The first task is financial reconciliation; the second is repairing endpoint routing or template execution.
Capture evidence before changing anything
- Record order ID, order key, gateway transaction and redirect URL.
- Check whether the order exists and payment completed despite the page error.
- Inspect the failing endpoint status, redirect chain and PHP logs.
- Test checkout endpoints and theme overrides with cache bypassed.
Most common causes
- Endpoint rewrite failure: The order-received route does not resolve correctly.
- Lost session or key: Cookies or redirects remove access to the order context.
- Template fatal: Theme or plugin code fails while rendering confirmation.
- Cached private page: A CDN serves an invalid or another session’s response.
Safe diagnostic and repair sequence
- Reconcile payment before any retry.
- Repair endpoint rewrites, canonical redirects or the fatal error.
- Exclude confirmation and account pages from full-page caching.
- Test success, failed-payment and guest checkout paths.
How to choose between the likely causes
Do not treat Endpoint rewrite failure and Lost session or key as interchangeable. The order-received route does not resolve correctly. By contrast, cookies or redirects remove access to the order context. Use two checks to separate them: Record order ID, order key, gateway transaction and redirect URL; and check whether the order exists and payment completed despite the page error. Those observations usually show whether the next safe move is to reconcile payment before any retry or to preserve the current state and widen the investigation.
On a live store, reproduce the issue with a controlled test order and follow the same payment, stock, tax and notification path used by customers. Avoid changing several checkout components at once because that changes the application state and can obscure the original sequence of events needed to attribute the failure. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Never expose order details merely by weakening the order-key check.
How to verify the repair
- The confirmation page loads for authorised guest and account contexts.
- Payment, order, stock and email agree.
- Refreshing the page does not create another charge or order.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
The first task is financial reconciliation; the second is repairing endpoint routing or template execution.
- 1
Record order ID, order key, gateway transaction and redirect URL.
- 2
Check whether the order exists and payment completed despite the page error.
- 3
Inspect the failing endpoint status, redirect chain and PHP logs.
- 4
Test checkout endpoints and theme overrides with cache bypassed.
What must be verified
- The confirmation page loads for authorised guest and account contexts.
- Payment, order, stock and email agree.
- Refreshing the page does not create another charge or order.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
If the order confirmation page fails, has the customer's payment actually failed too?+
Not necessarily, and that ambiguity is the main risk here. The first task is financial reconciliation to check whether the order exists and payment completed despite the page error, before touching endpoint routing or template code.
Is it safe to refresh or retry checkout when the order-received page shows an error?+
Refreshing after this kind of failure risks creating another charge or order, which is exactly what the verification step checks for. Reconcile payment status first, and confirm as part of the fix that refreshing the confirmation page does not trigger a duplicate charge or order.
Could a CDN be showing me someone else's order confirmation instead of mine?+
Yes. A CDN caching a private confirmation page can serve an invalid response or another session's order details, which is why confirmation and account pages need to be excluded from full-page caching as part of the repair.
Is loosening the order-key check a reasonable way to stop confirmation pages from breaking?+
No, this is explicitly ruled out. Weakening the order-key check to expose order details more easily removes the protection that prevents one customer from viewing another customer's order, so the fix has to target endpoint rewrites, redirects or the template fatal error instead.