Checkout depends on services you do not control
Payment and shipping modules do their real work by calling someone else's API in the middle of checkout. When that external service is slow, rate-limited, or down, the failure lands on your store, not theirs.
Because it depends on the provider's health, the failure is intermittent. It passes every test on a good day and breaks during the traffic spike when the provider is also under load.
This article covers why these errors come and go, the failure patterns that hurt checkout most, and where to find the orders they leave stranded.
Why these errors are intermittent by nature
A payment authorization or a shipping rate request is a live call to an external system during the customer's checkout. Its success depends on the network, the provider's uptime, and whatever rate limits that provider enforces.
None of those are under your control, and all of them vary by the minute. That is why the same checkout works a hundred times and fails on the hundred-and-first, with no code change in between.
Chasing these as if they were deterministic bugs wastes time. They are reliability problems at a boundary, and they need to be diagnosed as such.
The failure patterns that hurt checkout
A few specific patterns account for most payment and shipping incidents:
- A gateway timeout during authorize or capture, which leaves the order failed or hung at the payment step.
- A shipping rate API timeout, which shows the customer no rates and stops them from proceeding.
- Provider rate limiting during a traffic spike, which fails exactly when the most customers are checking out.
- A credentials mismatch, where a store is quietly pointed at sandbox instead of production keys.
Each of these is invisible on a calm day. They surface together under the conditions that matter most to revenue.
The missing timeout that ties up workers
The most damaging pattern is a payment or shipping call with no request timeout configured. When the provider hangs, the call waits, and the PHP worker handling it stays occupied for the entire hang.
This is how a slow provider becomes a site-wide slowdown rather than a single failed checkout. A sane timeout turns a hung request into a quick, contained error the customer can retry, and frees the worker for the next request.
Orders that get stuck, and where to see them
When these integrations fail partway, they leave orders in limbo. The states to watch are pending_payment and payment_review, where orders sit when authorization started but never cleanly finished.
A growing pile of orders in those states is a direct signal of payment integration trouble. The sales_order_status_history table and the payment transaction records show where in the flow each one stalled.
Webhook and callback failures make this worse, because an order can stay in pending_payment after the customer was actually charged. Those need reconciling against the provider, not just cancelling.
Diagnosing and containing it
Start in exception.log and the module's own log, filtering for gateway errors and timeouts. Correlate the timestamps against the provider's status history, because a cluster of failures at one time usually matches an incident on their side.
Then check the configured timeouts and retry behavior for each integration. A missing timeout, an overly aggressive retry, or stale credentials explains a large share of what looks like random checkout failure.
Containment is about graceful degradation: fail fast, show the customer a clear message, and let them retry, rather than hanging or losing the order silently.
Reconciling the orders left behind
Stuck orders are not just a monitoring signal, they are money that needs resolving. An order in pending_payment after the customer was charged has to be reconciled against the provider, not simply cancelled.
Build the habit of checking those states regularly, especially after any provider incident. Matching each stranded order against the gateway's own records tells you which were charged, which failed cleanly, and which need manual completion.
Left alone, these turn into customer-service problems and chargebacks. Caught early, they are a short reconciliation task instead.
Protect the path that makes money
Checkout is the one flow where an intermittent error costs revenue directly. Payment and shipping modules are where that risk concentrates, because they hand control to a third party at the worst possible moment.
The stores that hold up best treat these integrations as unreliable by default, and design checkout to fail gracefully when a provider does. That assumption is what separates a contained error from a lost sale.
Knowing which integrations lack timeouts, which leave orders stranded, and how they behave under load is what keeps a provider's bad hour from becoming your lost sales. That is exactly the kind of checkout risk a structured review is built to surface.