WooCommerce checkout errors in Google Merchant Center

WooCommerce checkout and unable to purchase errors in Google Merchant Center

A WooCommerce product can contain an accurate title, image, price, stock status and product identifier while remaining unusable for Google Merchant Center because a customer cannot complete the purchase.

The product page may load correctly and the Add to cart button may appear. However, the buying process can fail when the customer:

• Selects a variation
• Adds the product to the cart
• Changes the quantity
• Opens the cart
• Enters a billing address
• Selects a shipping destination
• Chooses a delivery method
• Enters a coupon
• Selects a payment method
• Accepts the terms
• Places the order
• Returns from the payment provider
• Waits for an order confirmation

A failure at any of these stages can make the advertised product effectively unavailable.

Google Merchant Center may describe or expose the problem through issues such as:

• Checkout incomplete
• Restricted purchase
• Unable to purchase
• Availability mismatch
• Inaccurate price
• Missing or unavailable payment methods
• Website needs improvement
• Landing-page problems
• Policy or account-level warnings
• Product disapproval
• Account suspension

The exact wording can vary according to the problem, country, Merchant Center interface and scope of the review.

The correction should therefore not begin by searching WooCommerce for one exact Google error phrase.

It should begin with a complete purchase test using the exact product, variation, price, currency, country and customer conditions represented in Merchant Center.

The objective is to prove that an ordinary customer can move from the submitted product URL to a completed WooCommerce order without hidden restrictions, broken fields, unexpected price changes or technical errors.

A successful product submission through an API does not prove that the product can be purchased.

Google independently checks the website, product information and purchasing experience.

The short answer

A reliable WooCommerce checkout investigation consists of the following steps:

1. Open the exact affected product in Merchant Center.
2. Record the Merchant offer ID and product URL.
3. Record the target country, language and currency.
4. Identify the exact WooCommerce product or variation.
5. Confirm that the product is published and publicly accessible.
6. Open the landing page while logged out.
7. Select the submitted variation.
8. Confirm the visible price and availability.
9. Add one unit to the cart.
10. Confirm that the correct product and variation enter the cart.
11. Confirm that the cart price remains unchanged.
12. Change the product quantity.
13. Remove and add the product again.
14. Proceed to checkout as a guest.
15. Enter a valid billing address.
16. Enter a valid shipping address.
17. Confirm that at least one applicable shipping method appears.
18. Confirm that the shipping cost is disclosed.
19. Confirm that at least one conventional payment method is available.
20. Complete a real or controlled test transaction.
21. Confirm that the payment result returns to WooCommerce.
22. Confirm that WooCommerce creates an order.
23. Confirm that the customer sees an order-confirmation page.
24. Confirm that an estimated delivery date or delivery information is available.
25. Repeat the test on mobile.
26. Repeat the test in a clean browser session.
27. Repeat the test for each relevant target country.
28. Review WooCommerce logs and payment-provider logs.
29. Correct the authoritative WooCommerce, theme, plugin or server source.
30. Clear applicable caches.
31. Retest the entire purchase path.
32. Update Merchant product information where necessary.
33. Request a review only when every correction is public and stable.
34. Continue monitoring checkout after updates.

Do not test only the product page.

A customer has not successfully purchased a product merely because the Add to cart button was clicked.

Understand Google’s checkout requirement

Google requires a functional purchasing process for products promoted through Shopping ads and applicable free listings.

According to Google’s checkout incomplete guidance, customers must be able to complete the full checkout process without errors or unnecessary obstacles. The guidance also requires purchase confirmation after checkout and an estimated delivery date.

Google’s Merchant Center website guidelines state that customers must be able to add products to the cart and complete checkout successfully. At least one conventional payment method should be available, such as:

• Credit card
• Debit card
• Invoicing
• Payment on delivery

The applicable payment option must genuinely work.

Displaying payment logos in the footer does not prove that those methods are available at checkout.

A WooCommerce store should also disclose the full cost and relevant purchase conditions before the transaction is completed.

These conditions can include:

• Product price
• Tax
• Shipping cost
• Additional fees
• Required minimum quantity
• Recurring payment
• Deposit
• Instalment arrangement
• Delivery restrictions
• Return conditions
• Membership requirements
• Subscription terms

A product advertised as immediately purchasable should not become a request-for-quotation form, telephone-order instruction or inaccessible payment page after the customer enters the checkout.

Separate the four types of purchase failure

WooCommerce checkout problems are easier to investigate when they are divided into four categories.

Product-level failure

The individual product cannot be purchased because of its own configuration.

Examples include:

• The product is out of stock.
• The variation is unavailable.
• The price is missing.
• The product is marked as not purchasable.
• A required add-on cannot be selected.
• A minimum quantity is not disclosed.
• The submitted variation does not exist.
• The product is hidden from the catalogue.
• The product requires membership.
• The product URL opens another variation.
• A backorder is not genuinely accepted.

Cart-level failure

The product can apparently be added, but the cart does not preserve a valid purchasable offer.

Examples include:

• The wrong variation enters the cart.
• The cart becomes empty after a redirect.
• The quantity returns to zero.
• A required product is added unexpectedly.
• A coupon is required to obtain the submitted price.
• The currency changes.
• The tax treatment changes the product price unexpectedly.
• A session or cookie problem removes the cart.
• A caching system shows another customer’s cart state.
• The product is removed because of a stock reservation conflict.

Checkout-level failure

The cart works, but the customer cannot submit the order.

Examples include:

• No shipping method is available.
• No payment method is available.
• A required field cannot be completed.
• The Place order button remains disabled.
• Checkout validation rejects a valid address.
• A required checkbox is invisible.
• A JavaScript error blocks payment.
• The checkout requires an account.
• The customer is forced to join a marketing programme.
• The billing country is unnecessarily restricted.
• A business name or tax number is compulsory for individual customers.
• The checkout continually reloads.
• The payment iframe does not load.
• CAPTCHA cannot be completed.
• The session expires before submission.

Post-payment failure

The payment step appears to work, but WooCommerce does not complete the purchase correctly.

Examples include:

• The payment provider returns to a 404 page.
• WooCommerce does not create the order.
• The order remains in an invalid state.
• The customer does not see confirmation.
• The order-received page is blocked by cache or security rules.
• A webhook is rejected.
• The stock is not reduced.
• The customer is charged but receives an error.
• The estimated delivery information is absent.
• The confirmation email fails.
• A redirect sends the customer back to an empty cart.

Each category requires different evidence.

Do not reinstall a payment gateway when the real problem is a missing shipping zone, and do not change Merchant product data when the checkout session is being destroyed by page caching.

Identify the exact affected Merchant offer

Begin with the affected product in Merchant Center and record:

• Merchant Center account
• Product data source
• Offer ID
• Product title
• Product URL
• Image URL
• Target country
• Content language
• Feed label
• Marketing method
• Submitted price
• Processed price
• Currency
• Submitted availability
• Processed availability
• Issue title
• Issue description
• First detected date
• Affected destinations

Then match the Merchant offer to WooCommerce using:

• WooCommerce product ID
• Variation ID
• SKU
• GTIN where applicable
• Product slug
• Variation attributes
• Current price
• Current stock status

Do not test a parent variable product when Merchant Center identifies a specific colour and size combination.

A red size-small variation may be purchasable while the submitted blue size-large variation has no stock, no price or no shipping class.

Testing the wrong variation creates false confidence.

Test as a new customer

Open the submitted product URL in a private browser window while logged out of WordPress.

This is essential because a store administrator can receive a different experience from an ordinary customer.

Administrator sessions may:

• Bypass page cache
• Ignore maintenance restrictions
• See unpublished products
• Use stored addresses
• Retain an active cart
• Receive a preferred currency
• Skip CAPTCHA
• Use saved payment tokens
• Avoid fraud controls
• Bypass country restrictions
• Receive administrator-specific pricing
• See diagnostic notices unavailable to the public

Use a clean session without:

• A WooCommerce account
• Saved cookies
• Stored billing details
• Saved payment methods
• A previous currency choice
• Administrator privileges
• A wholesale role
• An active coupon
• A manually prepared cart

Test the path that a completely new customer receives.

Confirm that the product is genuinely purchasable

On the landing page, verify that:

• The product is published.
• The page returns a successful response.
• HTTPS works without certificate warnings.
• The URL does not redirect to an unrelated page.
• The intended product is visible.
• The intended variation can be selected.
• The product price is visible.
• The price uses the expected currency.
• The availability message is accurate.
• The Add to cart button works.
• Required options are understandable.
• Required options can be selected.
• No essential product field is hidden.
• The product is eligible for the intended shipping destination.
• The purchase does not require an undisclosed membership.
• The customer is not required to contact the merchant for a price.
• The customer is not forced to request a quotation.
• The product does not require an invitation or approval.
• The advertised product can be purchased for the submitted price.

A visible Add to cart button is not enough if pressing it produces:

• “This product cannot be purchased”
• “Please choose product options” when all options are selected
• “Out of stock”
• “Invalid value posted”
• “Product no longer available”
• A blank page
• An endless loading indicator
• A server error
• A cart that remains empty

Record the exact message, time, URL, product, variation and customer conditions.

Inspect variable products carefully

WooCommerce variations can fail before checkout even when the parent product appears healthy.

Check whether every submitted variation has:

• A valid price
• An accurate regular price
• An accurate active sale price
• A defined stock state
• A purchasable status
• Correct attributes
• A valid image where required
• An applicable shipping class
• A matching SKU
• A matching GTIN where applicable
• A usable variation URL or landing-page selection
• A product configuration that can enter the cart

Common problems include:

• The default variation is unavailable.
• The submitted variation is disabled.
• A required attribute contains no value.
• The parent is in stock but the variation is out of stock.
• The variation price is blank.
• The parent price range does not represent the selected offer.
• The selected colour adds another colour to the cart.
• A discontinued variation remains in Merchant Center.
• The product URL does not preserve the variation selection.
• A swatch plugin fails when JavaScript is delayed.
• A variation exceeds the available stock quantity.
• The theme does not enable the Add to cart button after selection.
• A custom add-on is required but not visible.

Test the exact variation twice:

1. From a completely clean landing page.
2. From the submitted URL used in Merchant Center.

The result should identify and add the same purchasable offer.

Test the WooCommerce cart

After adding the product, open the cart and verify:

• The cart contains the correct product.
• The correct variation appears.
• The correct image appears.
• The quantity is accurate.
• The unit price is accurate.
• The line total is accurate.
• The currency remains unchanged.
• Applicable tax is understandable.
• Discounts are applied only when appropriate.
• Shipping calculations are available when expected.
• The product can be removed.
• The quantity can be changed.
• The customer can return to shopping.
• The customer can proceed to checkout.
• The cart remains populated after page refresh.
• The cart remains populated after the checkout redirect.

Google specifically advises that customers should be able to edit items in the cart without being forced to restart the shopping process.

Investigate cart behaviour that:

• Prevents quantity changes
• Prevents product removal
• Adds mandatory unrelated products
• Applies hidden fees
• Changes the product price
• Removes the selected variation
• Requires an undisclosed coupon
• Empties the cart after refresh
• Redirects continuously
• Requires an account before the customer can inspect the order

The cart must represent the same offer submitted to Merchant Center.

Compare the price through every checkout stage

Google’s product data specification requires the submitted product price and currency to agree with the landing page, structured data and checkout. The product must also be purchasable online for the submitted price.

Record the product price at each stage:

1. Merchant product input
2. Processed Merchant product
3. WooCommerce product record
4. Public landing page
5. Structured Product data
6. Cart
7. Checkout
8. Payment-provider page
9. Order confirmation
10. WooCommerce order

Investigate unexpected differences involving:

• Active sale prices
• Expired sales
• Coupons
• Automatic discounts
• Quantity discounts
• Membership prices
• Role-based prices
• First-order discounts
• Tax-inclusive and tax-exclusive presentation
• Currency conversion
• Rounding
• Payment-method fees
• Required product add-ons
• Minimum order quantities
• Deposits
• Instalments
• Subscriptions
• Bundles
• Multipacks
• Shipping insurance
• Handling fees

Shipping and legitimate taxes can be added according to the applicable configuration, but the commercial conditions must be clear.

A product should not be submitted at a price that only logged-in members, selected companies or coupon holders can obtain unless the applicable Google programme and attributes support that pricing model.

The customer should not reach checkout and discover that the submitted product price is merely a deposit, monthly instalment or price for an unavailable minimum quantity.

Check stock and availability again at checkout

The product’s availability must agree across product data, landing page and checkout.

Google’s availability specification explains that customers expect the availability on the website and during checkout to match the submitted product information.

A product submitted as in_stock should not become unavailable when:

• The customer adds it to the cart.
• The shipping country is selected.
• The required variation is chosen.
• The customer proceeds to payment.
• The order quantity remains within the advertised limit.

Check WooCommerce settings for:

• Stock management
• Product stock quantity
• Variation stock
• Parent stock
• Backorders
• Hold stock duration
• Low-stock rules
• Out-of-stock visibility
• Inventory synchronisation
• Warehouse integrations
• Reserved stock
• Product bundles
• Composite products
• Pre-orders
• Country-specific inventory
• Shipping-class restrictions

A temporary race condition can also create checkout failure.

For example, a product may have one unit remaining. WooCommerce or another system can reserve that unit in an abandoned cart, causing the next customer to see an in-stock product that cannot be ordered.

Repeated availability failure should be corrected at the inventory source rather than hidden with a Merchant availability override.

Verify shipping zones and delivery methods

One of the most common WooCommerce checkout failures is:

No shipping options were found.

This usually means that the customer’s address does not match a working WooCommerce shipping zone or the product is excluded from all methods in that zone.

Review:

• WooCommerce shipping zones
• Zone order
• Country coverage
• State or province coverage
• Postcode patterns
• Shipping classes
• Product dimensions
• Product weight
• Free-shipping conditions
• Minimum order thresholds
• Table-rate rules
• Carrier API availability
• Warehouse restrictions
• Package splitting
• Hazardous-goods restrictions
• Oversized-product rules
• Remote-area restrictions
• Currency conditions
• Tax settings
• Delivery-date extensions

Test a real address for every Merchant target country.

Confirm that:

• At least one method appears.
• The method can be selected.
• The cost is visible.
• The method remains selected.
• The selected product is eligible.
• The method does not disappear after payment selection.
• The delivery estimate is reasonable.
• The checkout can continue.

Do not confuse the billing country with the shipping destination.

Google’s checkout incomplete guidance specifically warns against restricting the billing address to certain countries merely because shipping is limited to selected destinations.

The store can define where it ships, but its address and checkout logic should not create unrelated obstacles for customers who can otherwise buy for an eligible destination.

If the store targets one country, test several valid addresses within that country, including:

• Major city
• Smaller city
• Different state or province
• Standard postcode
• Remote but supported postcode

A test performed only with the store owner’s own address is not sufficient.

Verify payment methods

At least one conventional payment method should be genuinely available and operational during checkout.

Review:

• Payment gateway enabled status
• Supported currency
• Supported billing country
• Supported shipping country
• Minimum and maximum transaction amount
• Test or live mode
• API credentials
• Webhook configuration
• Callback URLs
• SSL certificate
• Required PHP extensions
• Gateway plugin version
• WooCommerce compatibility
• Theme compatibility
• Fraud rules
• Three-D Secure behaviour
• Popup blockers
• Embedded payment fields
• Saved-card requirements
• Bank-transfer instructions
• Cash-on-delivery restrictions

A payment method can appear in WooCommerce settings but disappear during checkout because:

• The currency is unsupported.
• The customer’s country is unsupported.
• The order total is below or above the gateway limit.
• The product category is excluded.
• The shipping method is incompatible.
• A payment plugin encounters a JavaScript error.
• The store is still in test mode.
• The payment account is restricted.
• API credentials are invalid.
• The checkout page uses an incompatible template.
• A cache serves an incomplete payment form.
• A security system blocks the provider’s scripts.

Complete a controlled transaction rather than stopping when the payment option becomes visible.

The method must accept the order and return a valid result.

Do not require unnecessary customer information

A checkout form should request information needed to:

• Process payment
• Deliver the order
• Calculate applicable tax
• Prevent legitimate fraud
• Meet applicable legal requirements
• Communicate order status

Investigate unnecessary mandatory fields such as:

• Company name for all customers
• Business tax number for every customer
• Business registration number
• Marketing consent
• Newsletter subscription
• Social-media profile
• Unrelated demographic information
• A second telephone number
• Account approval
• Sales-representative code
• Referral information
• An invitation number

Google identifies business-only purchasing and compulsory business information as possible causes of a restricted purchase issue.

Products presented to ordinary consumers should be purchasable by individuals unless the applicable Google programme and store model clearly support another arrangement.

Do not make promotional enrolment a required intermediate checkout step.

Allow guest checkout where appropriate

A forced account-registration system creates additional failure points.

The customer may be required to:

• Create an account
• Verify an email address
• Wait for approval
• Sign in
• Accept unrelated membership terms
• Join a loyalty programme
• Provide business credentials

Google’s checkout guidance requires a straightforward purchase path without unnecessary obstacles.

Review WooCommerce account settings and test whether a new customer can complete the purchase without a pre-existing account.

If account creation is genuinely required for the product or service, verify that the store’s model and the applicable Google programme permit that requirement. Do not assume that every membership-dependent item is suitable for standard Shopping listings.

Test every required checkout field

A field can look valid but still prevent order submission.

For each required field:

1. Enter a valid value.
2. Move to the next field.
3. Confirm that the value remains.
4. Submit the checkout.
5. Confirm that validation accepts it.
6. Correct the value and resubmit if an error is shown.

Check:

• First name
• Last name
• Company name
• Country
• Street address
• Apartment field
• City
• State or province
• Postcode
• Telephone
• Email
• Tax number
• Order notes
• Terms acceptance
• Privacy acceptance
• Age confirmation
• Delivery date
• Pickup location

Common failures include:

• A state field with no available values
• A postcode format that rejects valid addresses
• A telephone mask incompatible with international numbers
• A hidden field that remains required
• Duplicate email fields
• A checkbox hidden behind a sticky element
• An autofill value not recognised by JavaScript
• A translated field name that breaks validation
• An optional field incorrectly marked as required
• A required field removed by the theme but retained by server validation

Test manual entry and browser autofill.

Mobile autofill can behave differently from desktop entry.

Inspect the Place order button

The final order button can fail because of:

• JavaScript errors
• Missing checkout fragments
• An unresolved AJAX request
• A payment token error
• A hidden required checkbox
• A theme overlay
• A cookie-consent layer
• A CAPTCHA layer
• A disabled payment iframe
• An incompatible checkout block
• A stale nonce
• A cached checkout page
• A firewall challenge
• Duplicate script loading
• JavaScript optimisation
• Delayed script execution

Open the browser developer console and network panel during a controlled test.

Look for:

• Failed checkout requests
• HTTP 403 responses
• HTTP 404 responses
• HTTP 429 responses
• HTTP 500 responses
• AJAX failures
• REST API failures
• Content Security Policy errors
• Mixed-content warnings
• Cross-origin errors
• JavaScript exceptions
• Blocked payment-provider scripts
• Invalid nonce messages
• Repeated redirects

Record the failed request and server response before changing plugins.

The visible button is often only the final point at which an earlier configuration problem becomes apparent.

Review WooCommerce checkout blocks and classic checkout

WooCommerce stores can use:

• Checkout Block
• Classic checkout shortcode
• Theme-provided checkout templates
• Page-builder checkout templates
• Custom checkout plugins
• One-page checkout
• Express checkout
• Funnel or order-bump checkout systems

A plugin can support the classic checkout while failing with Checkout Block, or support Checkout Block while relying on outdated theme templates elsewhere.

Verify:

• Which checkout system is active
• Whether the assigned checkout page contains the correct block or shortcode
• Whether WooCommerce recognises the page
• Whether the theme overrides WooCommerce templates
• Whether overridden templates are outdated
• Whether payment extensions support the active checkout system
• Whether custom field extensions support the active checkout system
• Whether checkout endpoints work
• Whether translated endpoint slugs conflict
• Whether page-builder conditions select the correct template

Do not change the checkout architecture on the live store without a controlled test.

Use a staging environment and reproduce the complete order process before publishing the change.

Check WooCommerce pages and endpoints

WooCommerce should have valid assigned pages for:

• Cart
• Checkout
• My account
• Terms and conditions where used

Review checkout endpoints such as:

• Order pay
• Order received
• Add payment method
• Delete payment method
• Set default payment method

Problems can occur when:

• The checkout page was deleted.
• The cart and checkout use the same page incorrectly.
• A page is private or draft.
• A caching plugin excludes one endpoint but not another.
• A translation plugin creates conflicting slugs.
• Rewrite rules are outdated.
• The order-received endpoint returns 404.
• The payment provider callback returns to the wrong language or domain.
• HTTP redirects to HTTPS incorrectly.
• www and non-www versions create session loss.
• The store URL and WordPress URL use different hosts.

Confirm that the full path remains on the verified and claimed Merchant website domain.

Investigate cache and session failures

Cart and checkout pages are dynamic and customer-specific.

They should not be served as ordinary public cached pages.

Exclude applicable WooCommerce paths and cookies from:

• WordPress page cache
• Server cache
• Reverse-proxy cache
• CDN cache
• Edge cache
• HTML optimisation
• Static-page generation

Check whether the caching system understands:

• WooCommerce cart cookies
• Customer session cookies
• Add-to-cart requests
• Cart fragments
• Checkout endpoints
• Order-pay endpoints
• Order-received endpoints

Typical cache symptoms include:

• An empty cart after adding a product
• Another cart appearing briefly
• A cart total that does not update
• A stale shipping method
• A missing payment method
• An expired checkout nonce
• A confirmation page that shows an error
• A repeated order-submission request

Clearing the cache once is not a durable repair.

Configure the caching rules so dynamic commerce pages remain correct for every new session.

Check security and bot-protection systems

A firewall or anti-bot service can allow normal product-page access while blocking checkout operations.

Review:

• Web application firewall
• CDN bot protection
• Rate limits
• WordPress security plugins
• Country blocks
• IP reputation rules
• CAPTCHA
• JavaScript challenges
• Cookie challenges
• REST API restrictions
• AJAX restrictions
• Payment-provider callback allowlists
• Google crawler access
• Hosting security rules

Test whether checkout requests receive:

• 403 Forbidden
• 429 Too Many Requests
• Challenge pages
• CAPTCHA pages
• JavaScript verification pages
• Redirects to login
• Region-block messages

Do not disable all security controls permanently.

Identify the exact rule blocking legitimate purchase requests and correct it without exposing sensitive checkout operations.

Google also advises merchants using checkout or cart URL features to allow Google Storebot access. Access problems can prevent Google from validating those URLs.

Test location-dependent behaviour

A store may behave differently according to:

• IP address
• Browser language
• Cookie
• Device
• Currency selection
• Billing country
• Shipping country
• Customer role
• Warehouse
• Tax location

Google’s restricted purchase guidance identifies IP address, region and device limitations as possible causes of purchase restrictions.

For each relevant Merchant target:

• Use a clean browser session.
• Open the submitted URL.
• Confirm the expected language.
• Confirm the expected currency.
• Add the product to the cart.
• Enter a valid destination.
• Confirm available shipping.
• Confirm available payment.
• Complete the order.

Do not assume that a test from the store’s office represents the experience of customers in every target country.

A CDN, currency plugin or payment gateway can change the result by location.

Test mobile checkout separately

Mobile checkout can fail even when desktop checkout works.

Check:

• Product variation selectors
• Add to cart button
• Cart drawer
• Quantity controls
• Address autocomplete
• Country and state selectors
• Payment iframe
• Terms checkbox
• CAPTCHA
• Cookie banner
• Sticky navigation
• Place order button
• Bank authentication redirect
• Order confirmation

Common mobile problems include:

• The keyboard covering the payment button
• A sticky footer covering required fields
• The country selector not opening
• A payment iframe exceeding the screen width
• A CAPTCHA that cannot be completed
• An off-canvas cart that does not preserve the session
• A button requiring hover
• A modal that cannot be closed
• An address field that loses its value
• A browser returning from payment without restoring the order session

Test at least one Android and one iOS browser where practical.

Do not rely only on a responsive desktop preview.

Confirm the order after payment

A complete checkout should end with clear confirmation.

Verify that:

• WooCommerce created one order.
• The order contains the correct product.
• The correct variation appears.
• The quantity is correct.
• The product price is correct.
• Shipping is correct.
• Tax is correct.
• The total matches the payment.
• The payment status is recorded.
• The customer sees an order number.
• The customer sees confirmation.
• Delivery information or an estimated delivery date is available.
• The customer receives the applicable confirmation communication.
• Stock changes correctly.
• The cart is cleared only after successful submission.
• Refreshing the page does not create another order.

Google’s checkout incomplete guidance states that customers should receive confirmation of the purchase and an estimated delivery date after completing checkout.

An order-confirmation email is valuable, but it does not replace a functional confirmation page.

The customer should not see a generic error after being charged.

Review WooCommerce and gateway logs

WooCommerce provides logging facilities that can help identify checkout problems.

Review applicable logs for:

• Fatal errors
• Payment-gateway requests
• Payment-gateway responses
• Webhook failures
• Action Scheduler failures
• REST API errors
• Stock-reduction errors
• Tax-service failures
• Shipping-service failures
• Email failures
• Plugin exceptions

Correlate logs using:

• Test time
• Order ID
• Transaction ID
• Customer session
• Product ID
• Variation ID
• Gateway response code

Do not publish full logs or send them to unrelated parties without review.

Logs can contain:

• Customer names
• Addresses
• Email addresses
• Telephone numbers
• Tokens
• Internal paths
• Transaction information
• Security details

Mask sensitive information before using logs for support.

Distinguish ordinary checkout from Google’s checkout-link feature

Google’s optional checkout-link feature is different from the basic requirement that the store have a working checkout.

Ordinary Merchant listings usually direct customers to the product landing page. Customers then add the product to the cart and complete the WooCommerce checkout.

Google also offers an optional feature that can direct eligible shoppers to a cart or checkout URL. Google’s checkout-link documentation explains that an account-level URL template or product-level checkout_link_template can be used in supported configurations.

Do not add a checkout-link template merely to fix an ordinary checkout incomplete issue.

First ensure that the standard WooCommerce purchasing process works.

If the optional checkout-link feature is used, confirm that:

• The feature is available for the applicable country and destination.
• Only one supported opt-in method is used.
• The URL supports the required GET operation.
• The customer is not required to sign in.
• The correct product is added.
• The correct variation is added.
• The correct quantity is added.
• The URL uses the verified store domain.
• Product-level URLs are unique where required.
• The price and currency remain correct.
• The product is available.
• The customer can complete payment.
• Google Storebot can access the page.
• Required product disclosures remain available.

A direct checkout URL that adds the parent product instead of the submitted variation can create a new purchasing error.

Correct the authoritative source

Make the correction where the failure originates.

Examples include:

• Add the missing variation price in WooCommerce.
• Correct the product’s stock status.
• Create a shipping zone for the target country.
• Correct an invalid postcode rule.
• Enable a supported payment method.
• Replace expired payment credentials.
• Repair the payment callback URL.
• Make company fields optional for individual customers.
• Enable appropriate guest checkout.
• Remove a required newsletter step.
• Correct the cart and checkout page assignments.
• Update an incompatible checkout template.
• Repair a JavaScript conflict.
• Exclude cart and checkout from cache.
• Adjust a firewall rule blocking checkout requests.
• Correct multicurrency behaviour.
• Remove an undisclosed minimum-order restriction.
• Correct the selected variation URL.
• Repair the order-received endpoint.

Do not make only a cosmetic change to hide the error message.

The underlying purchase must work.

Retest after the correction

After applying a correction:

1. Clear applicable WordPress caches.
2. Clear server caches.
3. Clear CDN caches.
4. Clear WooCommerce transients where relevant.
5. Open a new private browser session.
6. Open the submitted product URL.
7. Select the exact variation.
8. Add it to the cart.
9. Confirm the cart.
10. Enter a new customer’s details.
11. Select shipping.
12. Select payment.
13. Place the order.
14. Confirm the payment result.
15. Confirm the WooCommerce order.
16. Confirm the order-received page.
17. Confirm the delivery information.
18. Repeat on mobile.
19. Repeat for other relevant target countries.
20. Repeat without administrator access.

A correction is not complete until the public purchase flow works from beginning to end.

Update Merchant Center after checkout is repaired

A checkout correction may not require changing product data when the original offer information remains accurate.

However, update the Merchant product if the investigation also changed:

• Product URL
• Price
• Sale price
• Currency
• Availability
• Variation identity
• Offer ID
• Shipping information
• Product condition

After the update:

• Record the submission time.
• Record the operation result.
• Allow Google to process the product.
• Inspect the processed product.
• Review item-level issues.
• Review country status.
• Review marketing-method status.
• Confirm that the old product source cannot restore inaccurate information.

A successful API operation does not prove that Google has rechecked the checkout.

It proves only that the applicable product-data request was accepted.

Request a review only after the store is ready

If Merchant Center provides a review or appeal option, use it only after:

• The product is publicly purchasable.
• The entire checkout works.
• All required fields accept valid information.
• Shipping works for the target market.
• At least one payment method works.
• The order-confirmation page works.
• Delivery information is available.
• Mobile checkout works.
• Location restrictions have been reviewed.
• Caches expose the corrected version.
• Security systems do not block legitimate customers.
• Business and individual customers are treated appropriately.
• Every affected product type has been tested.
• The correction is stable.

Google states that review availability and limits can vary according to the issue. Repeated premature requests can consume available review opportunities without correcting the underlying problem.

Do not request a review after changing only one button label or completing one administrator test.

What PW Merchant API can support

PW Merchant API supports an API-oriented connection between WooCommerce product information and Google Merchant Center.

Depending on the installed version, configuration and connected account, it can help merchants:

• Review WooCommerce products.
• Work with simple products and variations.
• Identify applicable product-data problems.
• Prepare supported product attributes.
• Submit supported product updates.
• Synchronise applicable price and stock changes.
• Record operation results.
• Display supported Merchant product issues.
• Compare applicable WooCommerce and Merchant information.
• Identify products that require further investigation.
• Maintain controlled product offer identities.

These functions can help identify whether the Merchant offer represents the correct WooCommerce product, variation, price, stock state and landing-page URL.

PW Merchant API cannot independently:

• Complete a customer’s WooCommerce order.
• Configure every payment gateway.
• Create missing shipping zones.
• Correct an unsupported payment account.
• Repair every checkout theme.
• Override a third-party checkout plugin.
• Remove every firewall challenge.
• Correct an inaccessible bank page.
• Guarantee that a payment provider accepts a transaction.
• Decide legal checkout requirements for every country.
• Correct inaccurate public store policies.
• Guarantee Google’s recrawl time.
• Guarantee account approval.
• Guarantee product visibility.
• Guarantee Shopping impressions, clicks or sales.
• Override Google’s product or website policies.
• Replace complete customer checkout testing.

WooCommerce remains responsible for the store, cart, checkout, order and payment experience.

PW Merchant API supports applicable WooCommerce product communication. Google independently evaluates the website, product data and purchasing process.

Common WooCommerce checkout correction mistakes

Testing only while logged in

An administrator can bypass caches, restrictions and customer-specific failures.

Stopping after Add to cart

The cart, shipping, payment or order-confirmation stages can still fail.

Testing the wrong variation

Another size or colour may be purchasable while the submitted variation is unavailable.

Using the store owner’s saved address

A stored address does not reveal problems affecting new customers or other supported regions.

Testing only one payment method visually

A displayed payment option may still fail when the order is submitted.

Testing only desktop

Mobile fields, overlays and payment frames can behave differently.

Disabling security completely

This can expose the checkout without identifying the specific blocking rule.

Clearing the cache only once

Dynamic cart and checkout pages require correct permanent cache exclusions.

Changing only Merchant Center

Product-data edits cannot repair a broken WooCommerce checkout.

Adding another payment logo

A footer logo does not activate or validate the corresponding payment method.

Requiring a quotation

Standard Shopping products should provide a genuine online purchasing path rather than only a quotation request.

Requiring business information from every customer

This can create a restricted purchase problem when individuals should also be allowed to buy.

Requesting a review too early

Google may still encounter the same public failure.

Assuming an accepted API operation proves checkout health

Merchant product submission and customer order completion are separate processes.

Frequently asked questions

What does “Unable to purchase” mean in Google Merchant Center?

It generally indicates that Google or a customer cannot complete the expected purchase for the listed product. The exact cause can involve the product page, variation, cart, checkout, shipping, payment, location restriction or confirmation stage.

Is “Unable to purchase” always the exact Merchant Center issue name?

No. Related problems can appear as checkout incomplete, restricted purchase, price or availability inconsistencies, website issues, product disapprovals or account-level warnings.

Why can I purchase the product while Google reports a checkout problem?

You may be logged in as an administrator, using a saved address, bypassing cache, using another location or testing a different variation. Repeat the purchase in a clean logged-out session.

Does the Add to cart button prove that checkout works?

No. The cart can lose the product, shipping may be unavailable, payment may fail or the order-confirmation page may not work.

Does WooCommerce need guest checkout?

A straightforward purchase path is important. If customers must create and verify an account or wait for approval, the process can become an obstacle. Review whether account creation is genuinely necessary and compatible with the listed product.

Can I advertise products available only by quotation?

Google’s checkout incomplete guidance states that websites offering only a quotation request are not supported for the ordinary online purchasing requirement. Customers must be able to purchase the listed product online using an applicable payment method.

Can a bank transfer count as a payment method?

Google identifies invoicing and payment on delivery among examples of conventional methods. The method must be genuine, available during checkout and supported by clear instructions and order confirmation.

Why does WooCommerce say no shipping methods are available?

The address may not match a shipping zone, the product may use an incompatible shipping class, a carrier service may be unavailable or a conditional rule may exclude the order.

Can I restrict shipping to selected countries?

A store can define supported delivery destinations. However, checkout logic, billing-address restrictions and Merchant targeting must remain coherent. Test valid addresses in every advertised country.

Why does the payment method disappear after entering an address?

The gateway may restrict countries, currencies, order amounts, products or shipping methods. Check the gateway’s conditions and logs.

Does the checkout price have to match Merchant Center?

The product price and currency should agree with the submitted data, landing page, structured data and checkout. Legitimate disclosed shipping and applicable tax treatment should also be consistent.

Can a coupon be required to obtain the submitted price?

Do not submit a generally unavailable coupon-dependent price as the ordinary product price. Use the applicable Google promotion or pricing attributes when supported.

Why does the cart become empty?

Common causes include cache errors, cookie problems, domain changes, HTTPS redirects, session failures, CDN behaviour and custom cart scripts.

Should cart and checkout pages be cached?

They are customer-specific dynamic pages and normally require appropriate cache exclusions. The exact configuration depends on the cache, server and CDN systems.

Can CAPTCHA cause a Merchant checkout problem?

Yes. A broken, inaccessible or repeatedly triggered CAPTCHA can prevent legitimate customers or automated validation from reaching checkout.

Does PW Merchant API repair payment gateways?

No. It can support product communication and applicable Merchant issue visibility. Payment, shipping, cart and checkout failures must be corrected in the responsible WooCommerce or third-party component.

Do I need to request a review after every checkout correction?

Not always. Follow the action provided for the exact Merchant issue. If a review is available, request it only after the complete public checkout has been corrected and tested.

Will a successful review guarantee permanent approval?

No. The store must continue providing an accurate and functional purchasing experience. Future checkout, product, policy or account problems can create new issues.

Final checkout checklist

Before considering the WooCommerce purchase problem resolved, confirm that:

• The correct Merchant account was opened.
• The exact issue was recorded.
• The affected destination was recorded.
• The offer ID was recorded.
• The WooCommerce product ID was recorded.
• The variation ID was recorded where applicable.
• The SKU was checked.
• The GTIN was checked where applicable.
• The target country was recorded.
• The content language was recorded.
• The currency was recorded.
• The feed label was recorded.
• The marketing method was recorded.
• The active product data source was identified.
• The exact submitted URL was opened.
• The page worked while logged out.
• HTTPS worked.
• Redirects remained on the correct domain.
• The intended product appeared.
• The intended variation was selectable.
• The intended variation was purchasable.
• The product price was visible.
• The product currency was visible.
• The product availability was accurate.
• Required product options were usable.
• The Add to cart button worked.
• The cart contained the correct product.
• The cart contained the correct variation.
• The cart quantity was correct.
• The cart price was correct.
• The cart currency was correct.
• The cart could be edited.
• The product could be removed.
• The product could be added again.
• The cart survived a page refresh.
• The cart survived the checkout redirect.
• The checkout page was correctly assigned.
• The active checkout system was identified.
• Checkout templates were current.
• Guest checkout was tested.
• Account creation requirements were reviewed.
• Business-only restrictions were reviewed.
• Company fields were reviewed.
• Tax-number requirements were reviewed.
• Marketing enrolment was optional.
• Every required field was visible.
• Every required field accepted valid data.
• Country selection worked.
• State or province selection worked.
• Postcode validation worked.
• Telephone validation worked.
• Email validation worked.
• Address autofill was tested.
• Billing-address rules were reviewed.
• Shipping-address rules were reviewed.
• Shipping zones were reviewed.
• Shipping classes were reviewed.
• At least one shipping method appeared.
• Shipping cost was disclosed.
• Delivery restrictions were disclosed.
• Delivery information was available.
• At least one conventional payment method appeared.
• The payment method supported the currency.
• The payment method supported the country.
• The payment method supported the order amount.
• Payment credentials were valid.
• Live and test modes were not confused.
• Payment-provider scripts loaded.
• Three-D Secure was tested where applicable.
• The Place order button worked.
• Terms acceptance worked.
• Privacy acceptance worked.
• CAPTCHA worked.
• Cookie consent did not block payment.
• Checkout AJAX requests succeeded.
• REST requests succeeded.
• No relevant 403 response occurred.
• No relevant 404 response occurred.
• No relevant 429 response occurred.
• No relevant 500 response occurred.
• No JavaScript error blocked checkout.
• No firewall challenge blocked checkout.
• No region block prevented a valid purchase.
• No device restriction prevented a valid purchase.
• Cart pages were excluded from inappropriate caching.
• Checkout pages were excluded from inappropriate caching.
• Order-pay pages were excluded from inappropriate caching.
• Order-received pages were excluded from inappropriate caching.
• WooCommerce sessions persisted.
• The payment provider accepted the controlled transaction.
• The payment provider returned to the correct URL.
• WooCommerce created one order.
• The order contained the correct product.
• The order contained the correct variation.
• The order total was correct.
• Tax was correct.
• Shipping was correct.
• The payment status was correct.
• Stock changed correctly.
• The customer saw confirmation.
• The order number was visible.
• Delivery information was available.
• The order-confirmation communication worked.
• Refreshing did not create a duplicate order.
• WooCommerce logs were reviewed.
• Payment logs were reviewed.
• Shipping-service logs were reviewed.
• Fatal-error logs were reviewed.
• Sensitive log information was protected.
• The test was repeated in a clean session.
• The test was repeated on mobile.
• The test was repeated for relevant target countries.
• The test was repeated for simple products.
• The test was repeated for variable products.
• The test was repeated for sale products.
• The test was repeated for low-stock products.
• The test was repeated without a coupon.
• The test was repeated without a customer account.
• Product price matched Merchant data.
• Product currency matched Merchant data.
• Product availability matched Merchant data.
• Checkout price matched the landing page.
• Checkout currency matched the landing page.
• Applicable product updates were submitted.
• Product-operation results were recorded.
• Rejected operations were investigated.
• The processed Merchant product was inspected.
• Item-level issues were reviewed.
• Country status was reviewed.
• Marketing-method status was reviewed.
• Every correction was publicly accessible.
• Applicable caches exposed the corrected checkout.
• The repair remained stable over time.
• A review was requested only when the site was ready.
• No approval or performance guarantee was claimed.

A WooCommerce checkout investigation should begin with the exact affected Merchant offer and end with a completed customer order.

The product must not only exist in WooCommerce or appear in Merchant Center. An ordinary customer must be able to open the submitted URL, select the correct variation, add it to the cart, enter valid details, choose shipping, use an available payment method and receive clear order confirmation.

The price, currency and availability should remain consistent throughout that journey.

Shipping zones, payment gateways, checkout fields, customer sessions, caching, security rules, mobile layout and payment callbacks can each break the purchasing process even when the product page looks correct.

Testing while logged in as an administrator or stopping after Add to cart cannot prove that checkout works.

After correcting the authoritative source, the merchant should clear applicable caches and repeat the complete purchase in a clean session, on mobile and for every relevant target market.

PW Merchant API can support controlled WooCommerce product communication, variation identity, operation results and applicable Merchant issue visibility. It cannot complete the customer’s order, repair every payment or shipping extension, or guarantee Google approval.

A stable WooCommerce checkout creates a consistent path from Google’s product listing to a real, confirmed purchase.

That complete purchasing path is essential for customers, WooCommerce order management and reliable Google Merchant Center participation.