← Back to Blog

WooCommerce 10.9 Defers Draft Orders — Your begin_checkout Event May Go Silent

WooCommerce 10.9, released June 23, 2026, defers Store API draft order creation to near place-order time. Stores that tied begin_checkout events or abandoned-cart tracking to draft order creation now fire late or not at all. The average WooCommerce cart abandonment rate runs 70–75%, and stores that can’t detect when checkout starts can’t measure the gap. Server-side event pipelines that fire on cart and checkout actions independently of order state remain unaffected.

What Changed in WooCommerce 10.9’s Checkout Flow

WooCommerce 10.9 moves draft order creation from checkout entry to near place-order time, cutting orphaned database rows but silently shifting when downstream systems see the first order signal.

Before 10.9, the Store API created a persisted draft order the moment a shopper entered the checkout page. That row served a dual purpose: it reserved the cart contents in the database, and it gave every plugin, webhook, and tracking script a durable object to hook into. WooCommerce 10.9 removes that early persistence — the Store API no longer creates a draft order during fresh-session GET and PATCH requests.

The stated goal is performance. Fewer orphaned draft rows means less database churn during high-traffic periods. WooCommerce’s own release notes describe the change as reducing unnecessary order state and avoiding repeat database work. The 10.9 release credits 464 pull requests from 65 contributors, with the checkout-flow changes among the headline items.

The practical effect is a timing shift. Draft order creation now happens closer to the moment a shopper clicks “Place Order.” Anything that depended on that row existing earlier — a webhook listening for draft order creation, a plugin counting draft rows as checkout entries, a tracking integration using the order ID as a session identifier — now operates on a different timeline. The order row that many systems treated as the “checkout started” signal simply isn’t there when they expect it.

WooCommerce shipped a hotfix (10.9.1) within 24 hours of the June 23 release, confirming that the scope of changes caught some integrations off guard. The hotfix is a useful signal: when a release needs a same-day patch, it means production stores hit problems the beta period didn’t surface.

You may be interested in: WooCommerce 10.9 Just Handed AI Agents a Direct Line to Your Orders

Why the Draft Order Mattered to Tracking

The draft order wasn’t just database plumbing — it was the only reliable signal many tracking systems had that a checkout session had begun.

GA4’s recommended ecommerce event flow expects a begin_checkout event to fire when a shopper starts the checkout process. That event is the denominator in every checkout completion calculation. Without it, you can see purchases, but you can’t see the funnel that produced them. No begin_checkout data means no abandonment picture — you lose the ability to measure the gap between shoppers who started and shoppers who finished.

WooCommerce 10.9 defers Store API draft order creation from checkout entry to near place-order time, eliminating the database row that many tracking integrations used as a begin_checkout signal.

Many WooCommerce tracking plugins fired begin_checkout by hooking into the draft order creation event. The logic was straightforward: when WooCommerce creates an order with draft status, the shopper is in checkout. That hook provided a server-side, reliable trigger that didn’t depend on JavaScript executing in the browser.

Abandoned-cart plugins followed the same pattern. They watched for draft orders, captured the associated email address (if entered), and started a countdown timer. If the order never moved to processing or completed status, the plugin marked it as abandoned and triggered a recovery email sequence. With 10.9, the draft order that powered this sequence may not exist until the shopper is moments from completing — by which point the abandonment window has already passed.

The Abandonment Numbers That Disappear Without begin_checkout

The scale of checkout abandonment in WooCommerce makes the begin_checkout event not a nice-to-have — it’s the only way to quantify what you’re losing.

The average WooCommerce cart abandonment rate runs between 70% and 75%, according to industry data compiled by WPBeginner and confirmed by the Baymard Institute’s meta-analysis of 50 independent studies, which places the cross-industry average at 70.22%. That means roughly seven out of ten shoppers who add something to a cart leave without buying — and the begin_checkout event is the dividing line between “browsed and left” and “entered checkout and abandoned.”

The average WooCommerce cart abandonment rate runs between 70% and 75%, and stores that lose the begin_checkout event lose their only way to measure the size of that gap.

MetricValueSource
WooCommerce cart abandonment rate70–75%WPBeginner (2026)
Cross-industry average (50 studies)70.22%Baymard Institute (2026)
Placed-cart abandonment (6,000+ stores)21%Metorik (2026)
Average abandoned cart value$141Metorik (2026)
Average completed cart value$117Metorik (2026)
Recovery rate via automated emails3.6%Metorik (2026)
Average recovered cart value$174Metorik (2026)

Metorik’s 2026 analysis across 6,000+ WooCommerce stores found that abandoned carts averaged $141, compared to $117 for completed carts — abandoned shoppers had larger baskets. The 3.6% of carts recovered through automated emails averaged $174 per cart, making each recovered session worth nearly 50% more than a typical completed order. None of those recovery flows work if the system can’t identify that checkout started in the first place.

Which Tracking Setups Break and Which Survive

The impact depends entirely on how your tracking integration determines that checkout has started — some methods survived the 10.9 change, others went silent.

Setups that break include any integration that hooks into draft order creation to fire begin_checkout, abandoned-cart plugins that monitor the orders table for new draft-status rows, and custom webhooks configured to trigger on order.created with draft status. These all relied on the same underlying mechanism: the draft order existing at checkout entry. That row now appears much later in the flow.

Setups that survive include JavaScript-based begin_checkout triggers that fire on checkout page load (these never depended on the draft order), server-side event pipelines that observe checkout page entry and cart contents directly, and any tracking that fires based on the shopper’s action rather than WooCommerce’s internal order state. The distinction is between watching what the shopper does versus watching what the database does.

Custom checkout implementations using the shortcode-based checkout (rather than the block-based checkout) were already operating without draft orders in many configurations. If your store uses the classic shortcode checkout, you may not notice any difference — but you should verify, because the Store API changes affect any integration that touches the /wc/store/v1/checkout endpoint.

The risk is highest for stores that assumed the draft order was a stable, permanent part of the checkout lifecycle. WooCommerce’s documentation never guaranteed that draft orders would be created at any specific point in the flow. The 10.9 change is technically a performance optimization, not a breaking change — but for integrations that built on an undocumented assumption, the distinction is academic.

Why Server-Side Event Pipelines Stay Resilient

Server-side tracking that fires on shopper actions rather than database state doesn’t care when WooCommerce creates the draft order — because it never depended on the draft order.

A server-side event pipeline observes the HTTP request when a shopper enters the checkout page. It reads the cart contents from the session or cart object. It fires begin_checkout at that moment, with the full item list, cart value, and session context. None of this requires a draft order row to exist. The pipeline responds to the shopper’s action, not to WooCommerce’s internal state machine.

Server-side event pipelines that fire begin_checkout based on cart and checkout page actions, rather than order-row creation, remain unaffected by the 10.9 change.

This is the architectural difference that separates resilient tracking from fragile tracking. A pipeline tightly coupled to WooCommerce’s internal order lifecycle breaks every time WooCommerce changes that lifecycle — and WooCommerce has been changing it steadily across 10.7, 10.8, and now 10.9. Query reduction work in 10.7 dropped HPOS order queries from 271 to 132. The 10.8 release rejected REST API PUTs for non-order types. Each change was a performance improvement that shifted assumptions integrations had built on.

You may be interested in: Your ‘First-Party’ Cookies Still Die in 7 Days — Why Only a True First-Party Server Survives

Translation: if your tracking breaks every time WooCommerce ships a performance update, your tracking is coupled to the wrong layer. The checkout flow will keep changing. The cart-plus-page-action layer is far more stable, because it reflects what the shopper actually did — and that doesn’t change with database optimizations.

What to Do Before and After the Update

Testing on staging before updating is the minimum — but even after updating, a structured verification catches problems before they compound into weeks of missing data.

Before updating, run a test purchase on a staging copy of your store running 10.9. Enter checkout, fill in your shipping and payment details, but do not complete the order. Then check three things: did begin_checkout appear in your GA4 real-time events? Did your abandoned-cart plugin capture the session? Did any order-created webhooks fire? If any of these are missing, your tracking depended on the draft order that 10.9 now defers.

After updating, monitor your begin_checkout event count in GA4 for the first 48 hours. A sudden drop compared to the same period the previous week is the clearest signal that your tracking lost the checkout entry trigger. Check your abandoned-cart plugin’s dashboard — a drop in captured sessions means the plugin was monitoring draft order creation rather than checkout page activity.

For stores already on 10.9 that didn’t test first, the data loss may already be accumulating. Begin_checkout events that don’t fire don’t show up as errors — they show up as a lower abandonment rate, which looks like good news until you realize you simply stopped measuring the funnel. Compare your begin_checkout-to-purchase ratio against the previous month. If the ratio improved sharply without any checkout changes, the improvement is measurement loss, not conversion improvement.

Transmute Engine™ fires begin_checkout on checkout page entry using the cart session, independent of WooCommerce’s order state. Stores running Transmute Engine saw no change in begin_checkout volume after the 10.9 update.

Key Takeaways

  • Draft orders now appear later: WooCommerce 10.9 defers draft order creation from checkout entry to near place-order time, cutting orphaned rows but shifting when integrations see the first order signal.
  • begin_checkout may go silent: Tracking that hooked into draft order creation to fire begin_checkout now fires late or not at all — and without begin_checkout, abandonment measurement breaks.
  • Abandoned-cart plugins are affected: Plugins that watched the orders table for new draft-status rows to start recovery sequences may miss sessions entirely under 10.9.
  • Server-side pipelines are resilient: Event pipelines that fire on checkout page actions rather than order state remain unaffected because they never depended on the draft order.
  • Test on staging first: Run a non-completing checkout test on a 10.9 staging site and verify begin_checkout fires in GA4 and your abandoned-cart plugin captures the session.
Did WooCommerce 10.9 remove draft orders entirely?

No. WooCommerce 10.9 defers draft order creation from checkout page entry to closer to place-order time. Draft orders still exist — they just appear later in the checkout flow. The change reduces orphaned draft rows from shoppers who never complete a purchase.

Will my begin_checkout event still fire after updating to WooCommerce 10.9?

It depends on how your tracking fires it. If your tracking relies on the draft order row being created when a shopper enters checkout, it may fire late or not at all. If your tracking fires begin_checkout based on checkout page load or cart actions independently of order state, it remains unaffected.

How do I test whether my abandoned-cart tracking still works after the 10.9 update?

Run a test purchase on a staging copy of your store. Enter checkout, fill in details, but do not complete the order. Check whether your abandoned-cart plugin captured the session and whether begin_checkout appeared in your analytics. If either is missing, your tracking depended on the draft order that 10.9 now defers.

Does server-side tracking avoid this WooCommerce 10.9 issue?

Server-side event pipelines that fire on explicit cart and checkout actions rather than watching for order-row creation are unaffected. A server-side pipeline can observe checkout page entry, cart contents, and form interactions directly without waiting for WooCommerce to persist a draft order.

References

If your begin_checkout event went quiet after the 10.9 update, talk to Seresa about how a server-side pipeline keeps your checkout funnel visible regardless of what WooCommerce changes next.