WooCommerce 10.9.4 fixes VAT exemption logic for block checkout, especially for logged-in users. Stores that use tax exemptions, B2B pricing, wholesale roles, or custom tax display rules should test the exact checkout path before treating the update as safe.
Use this when a WooCommerce store has checkout blocks, tax exemptions, customer roles, EU VAT logic, wholesale rules, tax-exempt accounts, or order emails that depend on the final calculated tax state.
Quick answer
WooCommerce 10.9.4 Block Checkout Regression Test should be handled with a narrow evidence-first workflow: build test users, patch staging, compare checkout totals, then verify the result before making broader changes.
What to check first
- Create a logged-in tax-exempt test customer and confirm the VAT flag is applied before payment selection.
- Run the same cart as a guest, logged-in taxable customer, and logged-in exempt customer so the expected totals are visible side by side.
- Test at least one card gateway, one express wallet, and one offsite payment method if the store uses them.
- Compare checkout total, order total, invoice total, email total, and payment gateway amount for the same order.
- Record the WooCommerce version, payment plugin versions, tax plugin versions, and block checkout status with the result.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Build test users | Create a logged-in tax-exempt test customer and confirm the VAT flag is applied before payment selection. | Logged-in tax-exempt users see the expected checkout total before payment. |
| Patch staging | Run the same cart as a guest, logged-in taxable customer, and logged-in exempt customer so the expected totals are visible side by side. | The payment gateway receives the same total WooCommerce stores on the order. |
| Compare checkout totals | Test at least one card gateway, one express wallet, and one offsite payment method if the store uses them. | Order emails and invoices show the same tax treatment as the order screen. |
| Place test orders | Compare checkout total, order total, invoice total, email total, and payment gateway amount for the same order. | The result is recorded with versions, screenshots, and test order IDs. |
Why this usually happens
- Block checkout can calculate customer state, tax display, shipping, and payment totals at different points in the request flow.
- Tax-exempt users often rely on customer meta, role logic, or a B2B plugin that does not behave the same way for guests.
- Payment plugins can receive the final amount even when the visible checkout summary is stale.
- A small WooCommerce point release can still touch a revenue-critical path when it changes checkout calculation behavior.
Field notes
- Do not approve the update from a guest checkout test only.
- Use a real staging account with the same tax-exempt role or customer meta used in production.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp option get woocommerce_db_version
wp plugin list --fields=name,version,status | grep -Ei 'woocommerce|tax|vat|b2b|wholesale|payment|stripe|paypal'
# Test guest, logged-in taxable, and logged-in exempt carts with the same product, shipping address, and payment method.
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Build test users
- Patch staging
- Compare checkout totals
- Place test orders
- Approve production
What to tell the client or owner
Tell the store owner exactly which buyer types were tested and whether checkout, gateway, order, and email totals matched.
Production verification checklist
- Logged-in tax-exempt users see the expected checkout total before payment.
- The payment gateway receives the same total WooCommerce stores on the order.
- Order emails and invoices show the same tax treatment as the order screen.
- The result is recorded with versions, screenshots, and test order IDs.
Mistakes to avoid
- Do not judge the fix by one browser or the homepage only.
- Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
- Do not add a cache, security, or tracking plugin while the original problem is still unclear.
- Do not leave test users, temporary debug logs, or broad API keys active after verification.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix WooCommerce checkout before revenue is affected.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references