A PHP “Allowed memory size exhausted” fatal ends the checkout request before WooCommerce can return a valid response. Increasing the limit can restore service when the configured ceiling is genuinely too low, but an abnormal allocation loop, oversized cart or plugin query may consume any new allowance.
Check orders and the gateway before reproducing. The payment provider may have accepted a transaction even though PHP failed afterward.
Correlate the exact fatal
Record the checkout time, order ID if created, cart size, payment method and HTTP response. Find the matching PHP fatal in the hosting log.
Evidence:
allowed bytes and attempted allocation
file and line
PHP worker/request timestamp
request URI
WooCommerce/gateway referenceDo not expose customer fields, cookies or payment payloads.
Confirm the effective limit
WordPress constants, PHP configuration, hosting plans and process managers can each impose limits. Check the value seen by the web request, not only a php.ini file that may not apply.
error_log( 'Diagnostic memory limit: ' . ini_get( 'memory_limit' ) );Use temporary protected logging and remove it after diagnosis. Never output configuration publicly on checkout.
Measure peak usage safely
Reproduce in staging with equivalent PHP, plugins and a sanitised cart. Compare a simple product, the failing cart and different gateways.
Temporary instrumentation can record memory_get_peak_usage( true ) without logging order data. A sharp increase after one plugin callback is more useful than the final fatal location, which may only be where no memory remained.
Do not install a heavy profiler on production checkout without understanding its overhead.
Inspect cart and product payloads
Large variation sets, product add-ons, uploaded options and recursive bundles can create huge arrays. Custom code may load every product or order during each checkout update.
Search the call path for unbounded get_posts, WP_Query or wc_get_orders calls. Add explicit limits and query only required fields.
Avoid storing large API responses or images in WooCommerce sessions and order metadata.
Review plugins and theme hooks
Checkout recalculates several times. A callback that appends data on every update_order_review or registers itself repeatedly can grow memory.
Disable one implicated component in staging and compare peak use. Update incompatible code and remove duplicate hooks. Switching to a default theme can locate a theme layer, but the final repair should preserve required checkout design.
Never edit WooCommerce core to suppress the fatal.
Set a justified PHP limit
If normal peak use is healthy but the limit is below the stack’s documented requirement, raise it through cPanel, Plesk or the host’s supported configuration. Leave headroom for the web server and simultaneous workers.
A 512 MB limit per worker can exhaust the server when many checkouts run concurrently. Coordinate per-process memory with total RAM, worker count and traffic.
Restart or reload the appropriate PHP service only through supported hosting controls.
If OPcache is enabled, confirm deployment invalidation works. Stale bytecode can keep an old memory-heavy callback active after its source file has been corrected.
Reconcile failed attempts
List checkout requests during the incident and compare WooCommerce orders with gateway transactions. Resolve paid-but-pending, duplicate and absent orders before reopening normal traffic.
Do not change statuses in bulk to make reports look consistent. Add private notes with verified provider references.
Verify under realistic load
Complete guest and account orders with representative carts and gateways. Confirm peak memory remains below the chosen threshold, one payment occurs, stock updates and emails send.
Recurring care should alert on PHP fatals and trend checkout peak memory after releases. Capacity and efficient code both matter; one should not be used to conceal failure in the other.