Just last month I had a client, a mid-sized WooCommerce store, pulling their hair out over profit reports. They were stitching together spreadsheets, custom fields, and third-party plugins just to track their Cost of Goods Sold, and it was a mess. Their checkout was clunky too, which meant friction and abandoned carts: manual address entry, slow loads, the usual.
We’ve all been there, patching core WooCommerce behavior with plugins or custom code that turns into a maintenance headache later. My first instinct, and probably what most developers would reach for, was to recommend another premium plugin or build a custom COGS solution. We’ve done it before, more times than I’d like to admit. But then I saw what was coming in WooCommerce 10.3 and told them to hold off. This release matters for developers and for merchants who want more of this built into core.
WooCommerce 10.3: practical core updates
WooCommerce 10.3 lands on October 22, 2025, and it pulls some significant features into core, which means less dependence on third-party add-ons. The headline one is Cost of Goods Sold (COGS) built into WooCommerce core. Merchants can finally see proper profit margins per product and per order without wrestling with external tools. For years we either built custom solutions or bolted on plugins that struggled to keep up with inventory changes and complex pricing. Now it ships in core, and that changes how much you can trust the reporting.
Then there’s address autocomplete for the Checkout blocks and shortcode. If you’ve ever looked at a client’s analytics and seen high checkout abandonment, slow or error-prone address entry is often part of it. This one is built into core and works best for stores on WooPayments with an active account. On the developer side, there are hooks and documentation for wiring up your own address provider, so you don’t need custom JavaScript or a heavy third-party API just to get basic autocompletion. That’s the sane way to deal with checkout friction.
// Example of a (simplified) filter for address autocomplete provider.
// In reality, this would involve a class and more complex logic.
add_filter( 'woocommerce_address_autocomplete_providers', 'my_custom_address_provider' );
function my_custom_address_provider( $providers ) {
$providers['my_provider'] = array(
'label' => 'My Custom Address Provider',
'callback' => 'My_Custom_Address_Provider::search_addresses',
);
return $providers;
}
Performance got attention too. The Product Collection Editor now makes far fewer requests for product data, so the backend loads faster and editing feels smoother. Anyone who has worked in a sluggish admin on a store with thousands of products will appreciate that. They also fixed those “ghost” changes in the editor, where you’d be left trying to work out what you supposedly edited.
The PayPal API upgrade is another backend change worth noting. Moving off the legacy PayPal Standard (WPS) to the PayPal Orders v2 API means more secure, faster transactions, and the Express Checkout buttons (PayPal, Venmo, Pay Later) should help conversion. Not flashy, but the kind of thing that shows up in revenue.
Experimental features and developer advisories
On the experimental side, the Add to Cart + Options block can now update related product blocks based on the selected variation, which makes the product page feel more responsive. There’s also the new WooCommerce MCP (Merchant Control Protocol), aimed at AI-assisted store management and development workflows. If you do much automation, it’s worth watching. The developer documentation covers it.
One heads-up for plugin authors: wc_format_decimal starts returning an empty string as of WooCommerce 10.3 and into 10.4, so if you rely on it, plan to update your code. On the brighter side, the coupon discount calculation bug that triggered unwanted recalculations when editing orders has been reverted. That one caused a lot of grief.
Why this release matters
The pattern is that WooCommerce keeps moving real business features and performance work into core. For developers that means fewer custom hacks and a more stable base to build client stores on, and more room to build the features clients actually want instead of patching missing basics. Worth doing now: test your sites against the beta releases and lean on what core already handles.
This stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want the site to work, drop my team a line. We’ve probably seen it before.
