A normal retail cart works, but a wholesale or repeat-order customer adds dozens of lines and receives a timeout, blank page or memory error. WooCommerce recalculates prices, taxes, shipping, discounts and extension rules across the cart; poorly scaling logic can repeat work for every item.
Preserve the failing cart in a safe test environment and find which calculation grows disproportionately.
Establish the failure threshold
Create an authorised test customer and add products in controlled increments: 10, 25, 50 and the approximate failing count. Use non-sensitive products and a payment sandbox.
Record response time and memory for cart display, quantity update, shipping recalculation and checkout submission. The number of distinct lines may matter more than total quantity.
Do not ask a real customer to keep retrying. Repeated submissions can create duplicate orders or reserve stock.
Capture the actual server error
Match the test timestamp to PHP, web server and WooCommerce logs. Look for memory exhaustion, maximum execution time, gateway timeout or a fatal error in an extension.
Enable debug logging without displaying errors to visitors. Remove diagnostic instrumentation after evidence is collected.
Raising memory_limit may move the threshold but can exhaust the hosting account when several customers check out concurrently.
Profile cart and totals hooks
Use application tracing or a staging profiler to identify callbacks inside totals, fees, shipping and price modification. Custom code may query the database or call an API once per cart line.
A common scaling mistake is fetching the same settings inside a loop. Load stable configuration once per request and reuse it. Cache product data only with correct invalidation.
Do not remove a fee, tax or pricing hook until its business purpose and legal/accounting effect are understood.
Inspect shipping package creation
Shipping extensions may create packages, request live rates or compare rules for every product. Test a cart with shippable items, virtual items and multiple shipping classes separately.
Review provider timeouts and logs. Where supported, cache a rate response only for the precise destination, package and validity window.
Never reuse a shipping quote across materially different carts to save time.
Check discounts and dynamic pricing
Rules that compare every line with every other line can grow rapidly. Temporarily disable one pricing extension in staging and repeat the same cart.
Simplify overlapping rules or precompute eligible groups where the extension supports it. Confirm the final totals remain identical for boundary cases.
Coupon validation, subscriptions, deposits and add-ons can contribute additional passes. Change one owner at a time.
Review session and request size
A large cart creates more session data and may produce large AJAX or Store API responses. Inspect response bytes, object-cache values and database session rows without logging customer contents.
Do not store verbose custom product objects in cart item data when a stable identifier can be used. Custom development should persist only what is needed to reconstruct price and fulfilment safely.
Check reverse-proxy and PHP request timeouts, but repair excessive work before extending them.
Test two large carts concurrently in staging. A repair that works for one request by consuming nearly all available memory can still fail during a real wholesale peak.
Verify large and ordinary carts
After the smallest repair, repeat increasing cart sizes and compare time/memory curves. Complete sandbox checkout and confirm totals, stock, tax, shipping, emails and order lines.
Retest an ordinary one-item purchase. An optimisation for bulk carts must not slow the common path.
Request urgent assessment when memory errors affect wholesale orders, totals differ after retries or one extension dominates the trace. Share the controlled item count, timestamps and sanitised error, then arrange secure access.