WooCommerce Checkout Optimization: Stop Losing Sales at the Last Step

Seventy percent of carts get abandoned. The comforting lie is that those customers “just weren’t ready to buy.” The uncomfortable truth is that most of them were ready, and your checkout talked them out of it.

Every WooCommerce checkout optimization article on the internet will tell you to “enable guest checkout” and “add trust badges.” That advice has been recycled for a decade and it stopped being insightful around 2018. This post is for store owners and developers who already did the obvious stuff and are still watching money leak out of the funnel. We’re going to take positions, cut fields, rip out legacy JavaScript, and measure everything.

If you run a WooCommerce store in 2026 and you are still on the shortcode checkout, the single highest-leverage change you can make is the one nobody else is telling you about. Let’s start there.

Measure first or you’re guessing

Before you change a single thing, you need a baseline. “Conversion rate went up” is worthless without knowing which step in the funnel moved. The funnel you actually care about has four stages: product view → add to cart → begin checkout → purchase. Every step is a leak.

Set up GA4 enhanced e-commerce events. WooCommerce’s Google Analytics for WooCommerce extension will get you 80% of the way, but if you want to actually trust the numbers, fire the events yourself:

// In your theme or a must-use plugin, on the checkout page
document.addEventListener( 'DOMContentLoaded', () => {
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
        event: 'begin_checkout',
        ecommerce: {
            currency: wc_checkout_params.currency || 'USD',
            value: parseFloat( document.querySelector('.wc-block-components-totals-footer-item-tax-value')?.dataset.value || 0 ),
            items: window.wcBlocksCheckoutData?.cartItems || []
        }
    });
});

The metrics that matter: cart → begin checkout rate, begin checkout → purchase rate, and average time on checkout. Any optimization worth making moves one of those. If a change improves “overall conversion” but you can’t point at which stage moved, you haven’t learned anything and the next A/B test will confuse you.

Write the baseline down. In a real file. baseline-2026-04-11.md in the project root. We’ve rescued too many CRO projects where the team “remembered” numbers that turned out to be from a different month.

Switch to the Block Checkout (yes, now)

Here is the opinion most checkout guides refuse to give you: if you are running the shortcode [woocommerce_checkout] page in 2026, switch to the Block Checkout this week.

WooCommerce has been nudging toward this since 2022 and as of WooCommerce 10.6 (March 2026) the Block Cart and Checkout are unambiguously the default and receive all new development. They are faster, cleaner, and — importantly — they are the only version that gets new payment method integrations, inline validation improvements, and block-native extensibility.

There are two objections we hear constantly. Let’s address both.

“My custom fields won’t work.” They will. The block checkout has a proper extensibility API for custom fields that is actually better than the shortcode version’s filter stack. It’s also schema-validated, which means you get client-side and server-side validation for free.

“My plugins don’t support blocks.” Check the declared compatibility in WooCommerce → Home → Extensions. By April 2026, all major payment gateways, shipping plugins, and tax extensions support the block checkout. If a critical plugin doesn’t, that is a sign the plugin is abandoned and you have a bigger problem than your checkout page.

The only legitimate reason to stay on the shortcode checkout is if you have a heavily customized checkout built around the legacy hooks (woocommerce_after_checkout_billing_form, etc.) and rebuilding on the block API is not in the budget right now. If that’s you, read the rest of this post and take what applies, but make the block migration the next quarter’s project.

Audit your fields ruthlessly

The Block Checkout ships with sensible defaults. Most stores make it worse by adding fields nobody asked for. Here is the field audit we run on every checkout optimization engagement:

Field	Keep?	Why
Email	Always	Required for order confirmation
First name	Usually	Shipping carriers want it, some don’t
Last name	Usually	Same
Company	Cut	Unless you are B2B
Address line 1	Always	Obvious
Address line 2	Keep as optional	Don’t mark required
City, State, Postcode	Always	But auto-fill from postcode where possible
Country	Always	Or restrict if single-country
Phone	Cut unless shipping requires it	This is the biggest one
“How did you hear about us?”	Cut	Put it in a post-purchase survey
Order notes	Cut from checkout, add to cart	Reduces field count

The phone field is the one we fight for most often. Marketing teams love collecting it. Customers hate giving it. Baymard research has pointed at phone fields as a top-five abandonment cause for a decade. If your shipping carrier does not literally require a phone number on the label, cut it. If it does, mark it optional and explain why right next to the field: “For delivery questions only — we won’t call you.”

In the Block Checkout, the phone field is controlled through the WooCommerce settings UI and the Store API. You can hide it entirely or make it optional:

// Remove phone field from Block Checkout via the Store API schema
add_filter( '__experimental_woocommerce_blocks_checkout_order_processed', function( $order ) {
    // Phone is controlled in WooCommerce > Settings > General > Store Address
    // But to force-remove it programmatically for the Block Checkout:
    return $order;
});

// The cleanest approach for Block Checkout in 2026:
// Go to WooCommerce > Settings > Accounts & Privacy
// Or use the checkout block settings directly in the editor
// to set the phone field to "Hidden"

// For the classic shortcode checkout (if you haven't migrated yet):
add_filter( 'woocommerce_checkout_fields', function( $fields ) {
    unset( $fields['billing']['billing_phone'] );
    return $fields;
});

For adding a custom field in the block checkout (say, a gift message), use the register_endpoint_data API — not the old woocommerce_checkout_fields filter, which only half-works:

use Automattic\WooCommerce\StoreApi\Schemas\V1\CheckoutSchema;

add_action( 'woocommerce_init', function() {
    woocommerce_store_api_register_endpoint_data([
        'endpoint'        => CheckoutSchema::IDENTIFIER,
        'namespace'       => 'my-store',
        'schema_callback' => fn() => [
            'gift_message' => [
                'description' => 'Optional gift message',
                'type'        => 'string',
                'readonly'    => false,
            ],
        ],
        'schema_type'     => ARRAY_A,
    ]);
});

This registers the field schema-first. The React block that renders the input is a separate step in the src/ of your block plugin, but the data layer above is what makes the field survive validation and end up on the order.

Payment methods that actually matter in 2026

Every checkout guide says “offer more payment methods.” That is too vague to act on. Here is the ordered list that actually matters for a general-purpose WooCommerce store selling physical goods in North America and Europe:

1. Apple Pay and Google Pay via Stripe Payment Request Button — this is the single biggest mobile conversion lever in 2026. One tap, no form, biometric auth.

2. Credit card via Stripe or a local equivalent — the fallback. Embedded, not redirected.

3. PayPal — still carries weight with 35+ demographics. The express button at the top of the cart is worth the real estate.

4. Shop Pay or Klarna / Afterpay — only if your AOV is above about $75 and your demographic tilts younger.

That’s the list. Stop there. We have watched stores add eight payment methods in the name of “choice” and their conversion rate drop because the selection itself became a decision point. Hick’s Law is real. Three to four methods, ordered by share of checkouts, with the top one pre-selected.

Enable the Stripe Payment Request Button on the cart page as well as the checkout. Mobile users who tap it on the cart never see the checkout form at all. That is the fastest path from add-to-cart to purchase and it routinely doubles mobile conversion for stores that were previously Stripe-only.

Kill cart fragments if you’re still on the shortcode

If you did not switch to the Block Cart yet, you are almost certainly getting hammered by wc-cart-fragments.js. This is the script that keeps the mini-cart icon in your header in sync. It fires an AJAX request on every page load to refresh the cart. On a product-heavy site it is the number one cause of a bad INP score and a suspiciously high TTFB on the homepage.

Kill it. Here’s the right way:

add_action( 'wp_enqueue_scripts', function() {
    if ( is_cart() || is_checkout() || is_account_page() ) {
        return;
    }
    wp_dequeue_script( 'wc-cart-fragments' );
}, 11 );

Only dequeue it off the cart/checkout/account pages. The mini-cart will still work via the page-cache-friendly approach: read the cart count from a cookie. If you absolutely need live cart state in the header on every page, use the Block Cart and its wc/store/cart data store, which is event-driven and doesn’t poll.

On one client store, dequeuing cart fragments dropped median homepage INP from 480ms to 180ms and improved LCP by 600ms. The checkout conversion did not change directly — but the upstream funnel (product page → cart) improved by 6.2%, which is a bigger win than anything you’ll do on the checkout page itself.

Address autocomplete: not worth it for most stores

Checkout optimization blogs love to recommend Google Places or Loqate address autocomplete. Here is the unpopular opinion: for most small-to-medium WooCommerce stores, it’s not worth the cost or the complexity.

Google Places charges per session and the meter adds up fast. Loqate is more accurate but the integration is more involved. Both add a JavaScript dependency that can slow the checkout if the provider has a bad day.

The real ROI on address autocomplete shows up on two specific store profiles:

• Stores where more than 20% of orders have address errors (common for furniture, appliances, anything that gets returned due to bad addresses)
• Stores with very high AOV where even a small abandonment drop pays for the API costs

If you’re a $50 AOV apparel store with a 0.5% address error rate, autocomplete is a distraction. Spend that effort on reducing the field count and pre-filling what you can from browser autofill.

Speaking of browser autofill: it works properly when your input fields use the correct autocomplete HTML attributes. Check that every field in your checkout has one — autocomplete=”email”, “given-name”, “postal-code”, etc. The Block Checkout does this by default. The shortcode checkout often doesn’t if it’s been customized.

Mobile checkout: native keyboards and one-thumb ergonomics

More than 60% of WooCommerce checkouts in 2026 happen on mobile. If you are developing your checkout on a desktop browser and only QA-ing on mobile at the end, you are optimizing the wrong surface.

Three specific mobile wins that nobody writes about:

Use the right inputmode attribute. inputmode=”numeric” on postcode, inputmode=”email” on the email field, inputmode=”tel” on phone (if you kept it). This changes which keyboard the OS pops up. A numeric keyboard for postcode saves a real half-second of fumbling per field.

Make the submit button reachable with one thumb. The “Place Order” button should be in the bottom 40% of the viewport on mobile. If your checkout has the button below a long summary that requires scrolling, flip the order on mobile with a CSS media query. People checkout with one hand on a phone. Design for the thumb arc.

Disable auto-zoom on focus. iOS zooms in when an input has a font-size under 16px. That zoom is disruptive and hard to undo. Force inputs to 16px minimum:

@media (max-width: 768px) {
    .wc-block-components-text-input input,
    .wc-block-components-select select {
        font-size: 16px !important;
    }
}

Small, unsexy, and measurable in bounce rate.

Performance: INP is the new FID and the checkout is where it matters most

Core Web Vitals have been using INP (Interaction to Next Paint) as the interactivity metric since March 2024. INP measures how long your page takes to respond to every interaction — not just the first one. The checkout page, which is an interaction gauntlet, is where INP scores go to die.

The big INP killers on a typical WooCommerce checkout:

• Chained AJAX requests that re-render the whole form on every field change
• Legacy jQuery cart fragments doing their thing
• Over-eager shipping method recalculation on every keystroke in the zip field
• Third-party tag managers firing synchronous scripts

Our rule: the checkout page should have zero third-party scripts that aren’t directly required for the payment flow. No heatmaps, no chat widgets, no marketing pixels on the is_checkout() view. Move your tag manager to only fire on page types that are not the checkout, or gate the heavy scripts behind a user interaction.

Measure INP specifically on the checkout with PageSpeed Insights field data, not a lab test. Lab INP is misleading because lab tests don’t interact with the form. A p75 INP under 200ms is the target. Between 200ms and 500ms is “needs improvement.” Above 500ms and you are losing customers who think the page is broken.

What not to do (common bad advice)

Every time we audit a checkout we remove somebody’s favorite “optimization.” These are the ones to ignore.

Don’t add a progress bar to a single-page checkout. It implies more steps. The block checkout is already a single page; don’t fake progress through a linear form.

Don’t show “only 2 left in stock!” on the checkout page itself. Social proof belongs on the product page. On the checkout, it’s pressure, and pressure backfires when a customer has already committed to buying.

Don’t hide the coupon field. Some CRO blogs suggest hiding it to prevent “discount hunting” — the idea being customers will leave to look for codes. In practice, hiding it frustrates customers who have a code from your email list. Keep it collapsed under a link, not hidden entirely.

Don’t force account creation after purchase. “Guest checkout + create password at the end” is fine. Forcing it before payment is a conversion killer — Baymard has shown this kills 24% of intended purchases.

Don’t remove the shipping method step if you have complex shipping. Every blog says “reduce steps.” But if your shipping rates vary wildly (calculated, table-rate, multiple carriers), showing them upfront builds trust. Surprises at the end cause abandonment.

The three numbers that prove it worked

After you change anything, wait two weeks of comparable traffic. Then pull three numbers and compare to your baseline:

1. Begin checkout → Purchase rate. This is the number you are optimizing. If this didn’t move, your change didn’t work regardless of what your gut says.

2. Time from begin checkout → purchase. Faster is better up to a point. If this dropped by 20% and conversion held flat, you removed friction — that shows up later as repeat-purchase lift.

3. Checkout page p75 INP. If performance regressed, anything you gained in clarity is getting cancelled out for slow-device users.

Any change that moves all three in the right direction is a keeper. Any change that doesn’t move number one is a failed experiment — roll it back, even if the team liked it.

The short version

Switch to the Block Checkout. Cut the phone field and anything else you don’t ship with. Put Apple Pay and Google Pay at the top. Kill cart fragments if you’re still on the shortcode. Fix the mobile font-size that triggers iOS zoom. Remove every third-party script from the checkout page. Measure begin-checkout-to-purchase rate, not “overall conversion.” Roll back anything that doesn’t move it.

If rebuilding your checkout to the block API while keeping your custom logic intact sounds like a four-week engagement you don’t have time for, that’s exactly the work we do. Need something custom built for your WooCommerce store? Our WooCommerce Development & Customization service covers everything from custom product types to complex checkout flows — including block checkout migrations and conversion audits.

For related reading, see our guides on scaling WooCommerce to 10,000+ products and passing Google’s INP metric on WordPress.