Check Google Pay on WooCommerce through the selected gateway’s merchant eligibility, customer requirements and documented test mode. Confirm support for the business before changing checkout settings. Then examine button visibility, payment completion and order records as separate checks, using the provider’s current instructions for the actual store and account.
“WooCommerce supports a wallet” is too broad to settle a merchant’s setup question. Identify the extension and payment provider involved, the registered business and the checkout being used. Those details establish which documentation applies and which person can confirm the account’s actual eligibility.
Is the selected gateway available to the business?
This guide uses WooPayments as a documented example. Its country guide defines the starting condition. WooPayments signup is limited to individuals or businesses based in supported countries. For a business account, WooPayments uses the business’s registered country.
Compare the real merchant details with the provider’s current country list and account requirements. The visitor’s location and the business’s registered country answer different questions. For a Zambian business, confirm the actual provider route before treating an overseas setup example as an available solution.
The WooPayments Google Pay guide explains this particular integration. Its Google Pay feature is available across WooPayments-supported countries. Read that statement together with the country guide: wallet support within a gateway does not independently establish whether a business can open that gateway account.
If the store uses a different extension, obtain that publisher’s Google Pay and testing instructions. Keep the provider name, extension version and relevant account requirements in the setup record. Ask the account owner to resolve an eligibility question before the technical team spends time diagnosing a button that the chosen arrangement cannot provide.
Why might the button be missing for a customer?
The documented customer conditions include a Google account logged in through the browser. The customer also needs a payment method added to that Google account. Begin a visibility investigation by recording the test browser and whether it meets the documented customer conditions.
WooPayments enables Google Pay and Apple Pay together. The Google Pay button can appear on checkout, cart and individual product pages. Record which locations the merchant intends to use and compare those with the actual settings. A missing product-page button and a missing checkout button need their own observations.
A theme missing the required WooCommerce hooks can prevent the button appearing. Before replacing a theme or adding another extension, establish whether the issue is confined to a particular location or product. Preserve the relevant version and settings so the maintainer can reproduce the same situation.
Follow the publisher’s other compatibility checks for the actual arrangement, including HTTPS and the configured account-creation or guest-checkout path. Keep the evidence scoped: a successful button display proves something different from a completed payment and an accurate order record.
Which checks belong in a checkout acceptance sheet?
The original sheet below separates merchant eligibility, display and transaction evidence. Complete it using provider documentation and an approved test arrangement. It is a proposed review method, not a record of payments already processed.
| Check | Evidence to collect | Question for the owner |
|---|---|---|
| Merchant eligibility | Selected provider and supported-country reference | Does this account match the business? |
| Customer conditions | Browser and appropriate wallet setup | Can this test customer use the method? |
| Button location | Intended settings and observed page | Is the expected location enabled and compatible? |
| Test mode | Provider’s visible test indication | Is this the approved non-live exercise? |
| Completion | Confirmation and related order record | Did the intended order reach its recorded state? |
| Investigation | Relevant log entry and reproducible steps | Which stage needs further diagnosis? |
Use controlled sample customer details appropriate to the testing arrangement. Agree who will inspect the resulting order and any operational notifications it produces. A checkout exercise should include its recipients and fulfilment effects so the team knows how the sample will be recognised and handled.
Keep sensitive payment and customer information out of general screenshots and shared notes. Retain only the evidence needed for the investigation in an appropriate location. The review sheet should point the authorised maintainer to the relevant record rather than circulate unnecessary account details.
How should a test purchase be verified?
After authorisation, WooPayments processes the transaction and redirects to the thank-you page. The guide says a completed test order appears in the dashboard. Verify the expected confirmation alongside the related order instead of accepting one visible screen as the entire result.
Use the provider’s test-mode instructions and confirm its test-environment indication before completing the exercise. Follow the documented route for test payment details. Record the test order identifier, intended product and observed state so the merchant can connect the front-end journey with the administrative record.
If the result differs from the expected path, record the step where it diverges. A visibility problem, an interrupted wallet interaction and an unexpected order state are separate observations. Collect the relevant error log through the documented support route, preserving the configuration that produced it.
Original product-to-order diagnostic exercise
Consider a hypothetical eligible WooPayments merchant whose Google Pay button appears on checkout but not on one product page. Prepare a test case that records the product, browser, selected display locations and theme arrangement. Start with the existing evidence rather than assuming the payment account is broken.
Check the customer conditions and compare the intended button locations with the settings. Review the product’s express-checkout compatibility and the theme’s required hooks using the publisher’s instructions. Ask the maintainer to reproduce the issue in a controlled arrangement before changing the live store.
Once the visibility question is understood, follow the approved test-mode purchase route. Inspect the confirmation and dashboard order together. Have the order owner explain how the sample would be distinguished from operational orders and which notifications or fulfilment steps require attention.
Retain the results beside the original hypothesis. If a change is proposed, identify the specific observation it addresses and repeat the relevant test under comparable conditions. This creates a useful handover for the merchant and maintainer without turning one browser observation into an unsupported claim about every customer.
Have a second authorised reviewer follow the acceptance sheet without being coached by the person who configured checkout. Ask them to identify the selected provider, explain why the test account qualifies and locate the resulting order. Any missing instruction becomes a concrete handover correction. Keep account eligibility evidence current when the business details or provider arrangement changes, and repeat the affected checks when checkout components are materially revised.
For related work, see online payments and website development. Get started with your selected gateway, business registration country and checkout requirement.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.