WooCommerce payment methods not showing does not always mean the payment plugin is broken. The provider can be enabled in WordPress while the checkout cannot display it, the customer’s cart does not qualify, or the provider account cannot accept that payment.
First, establish whether all payment options are missing or only one. Then check four layers in order: provider configuration, checkout compatibility, customer eligibility, and the browser request. This avoids replacing a working checkout to solve a country rule, or changing API credentials when a script never loaded.
This guide covers missing payment options before a customer pays. If money has already left the customer’s account, use the separate WooCommerce pending payment after the customer paid guide. Do not ask that customer to pay again while you investigate.
Which payment option is actually missing?
Open the public checkout in a fresh browser session. Use a product that is in stock and a destination your business normally serves. Complete the required address fields, let totals finish updating, and record the exact message. Stop before placing an order.
A private window helps compare sessions, but it is not a universal payment test. A wallet may depend on a supported device, browser, and an existing wallet setup. Test a wallet on an eligible device as well as checking ordinary card entry.
| What the shopper sees | First branch to investigate | What not to assume |
|---|---|---|
| No payment methods at all | Enabled providers, account readiness, then compatibility with the actual checkout | That a new payment plugin is required |
| Cards appear, but one local method is absent | That method’s country, currency, amount, and product conditions | That the entire checkout is broken |
| Card entry works, but a wallet button is absent | Express-payment requirements, device eligibility, and enabled display locations | That private browsing proves the wallet is unavailable to everyone |
| The payment section spins or stays blank | The failed script or background request and its error | That repeatedly clearing caches identifies the cause |
| A method disappears after an address or cart change | The rule affected by that specific change | That an intentional restriction should be removed |
This is a triage map, not a diagnosis. Save the comparison that points to a branch before editing settings. If the cart itself loses products, investigate the empty WooCommerce cart first.
Layer 1: enabled does not always mean ready to accept payments
In WooCommerce > Settings > Payments, identify the exact provider and open its settings. Confirm that it is enabled and that account setup is complete. The plugin being active on the Plugins screen is a different state from its payment option being enabled. WooCommerce’s payment settings documentation explains the provider controls.
Next, check the provider connection and account status. For the official Stripe extension, the Stripe settings guide separates payment enablement, test mode, and account connection. Restrictions on payments or payouts need the provider’s explanation; they are not evidence that a WordPress theme needs replacing.
Keep production and sandbox details separate. Do not switch a live store into test mode while customers are checking out, and do not copy production secrets into an unprotected test site. Inspect the existing state first. A provider-account restriction belongs with the account owner and provider support; a site developer cannot remove a verification requirement through code.
Layer 2: does the gateway support your actual checkout?
Find the page assigned as checkout, then inspect how that page is built. A WooCommerce Checkout block, a classic shortcode checkout, and a page-builder checkout are not interchangeable integrations. Record the gateway name and version alongside the checkout type.
WooCommerce explicitly documents that an incompatible gateway may not appear in the Checkout block. If all active gateways are incompatible, customers can see a no-payment-methods message. Check the extension’s current compatibility information and the official Cart and Checkout guidance.
Do not replace the live checkout merely because a tutorial says to paste a shortcode. That can also change required fields, shipping presentation, terms, tracking, and extension behavior. A layout switch is a diagnostic comparison to perform on a protected staging copy, with the original page preserved.
If the method appears on one checkout type but not the other, you have narrowed the problem. You have not yet proven the alternative can process the store’s subscriptions, bookings, shipping rules, or other special cases. Ask the gateway or checkout developer to confirm support for that combination before making it permanent.
Layer 3: is the payment method eligible for this customer?
Some missing methods are behaving as configured. Compare the billing destination, shipping destination, currency, cart value, product type, and customer role. Change one input at a time in a safe test session, using destinations and rules your store actually supports.
For example, WooCommerce’s Conditional Payment Methods documentation describes visibility rules based on addresses and subtotal. Other extensions can impose different restrictions. Check the installed extension’s rules rather than assuming every store has the same control panel.
The right outcome may be to keep the restriction and explain the available alternative. Do not invent an address, broaden supported countries, or remove a payment limit to force a button to appear. Those decisions can affect fulfillment and the business’s payment arrangements.
When only Apple Pay, Google Pay, or another express option is missing
Treat express payments separately from ordinary card entry. The official Stripe extension has its own express-checkout requirements, including HTTPS, payment-domain setup where required, display locations, and product compatibility. Its documentation also describes situations where virtual products and address-dependent tax settings hide express buttons.
A missing express button alone is not a reason to change tax settings or paste a filter that forces display. Confirm the relevant product and address behavior with the payment integration owner. Keep a supported standard payment route available where the store’s configuration allows it.
Use a controlled comparison, not a list of random fixes
The following is a hypothetical diagnostic worksheet, not a Webless client result or a claim that every gateway behaves this way. Its purpose is to separate competing explanations with the smallest useful comparison.
| Keep these fixed | Change one thing | What a different result suggests |
|---|---|---|
| Product, supported destination, currency, provider settings | Block versus classic checkout on staging | Checkout integration or rendering deserves investigation before account credentials |
| Checkout type, provider, product, currency | One supported customer destination | A country or address-dependent condition may explain availability |
| Checkout, destination, provider, currency | One ordinary product versus the affected product type | Product support or a cart-specific rule is a stronger lead |
| Cart, destination, checkout URL | Browser session or a supported wallet device | Session, device eligibility, or browser loading may explain the difference |
Imagine card payment is absent on a staging block checkout but appears on the classic checkout with the same cart and provider settings. Reconnecting the provider would not be the first justified change: the comparison points toward the checkout integration. If it disappears on both only when the destination changes, inspect eligibility instead.
Neither result proves a completed payment works. The comparison only identifies where to investigate next. Keep a record of the expected method, actual result, changed input, time, and next owner. If several inputs changed together, repeat the comparison before drawing a conclusion.
Layer 4: did the payment interface finish loading?
If the method should be available but the section stays empty or spins, inspect the browser console and failed network requests. Record the first relevant error and the request’s status. A checkout page returning HTTP 200 does not prove its payment scripts or background requests succeeded.
The WooCommerce payment troubleshooting guide identifies theme and plugin conflicts as possible causes of missing options and blocked responses. Run conflict isolation on staging. Disabling every plugin on production can disrupt taxes, shipping, stock, and other business rules while customers are buying.
For the official Stripe extension, its missing-methods guide also covers outdated checkout templates, HTTPS, logs, and the extension’s own payment-method cache. That last cache is distinct from a page cache: follow the extension’s documented refresh route before deleting database entries.
When a request fails, match its time to the appropriate gateway, application, hosting, or firewall log. Keep security protection in place while reviewing a confirmed false positive. Redact customer data, cookies, tokens, and credentials before sharing evidence. After investigation, return temporary diagnostic logging to its agreed setting and retention policy.
What counts as a verified repair?
Seeing the button return is the first check, not the final acceptance test. Agree a controlled test plan with the store owner. Use the provider’s documented sandbox process on staging for payment attempts, and obtain explicit authorization for any real transaction or refund.
- The originally affected cart can see its intended payment option.
- A comparison cart still receives the correct options and restrictions.
- Desktop and a real mobile purchase path remain usable.
- Approved testing confirms the expected payment and order state, not just a success message.
- Required fields, order emails, stock behavior, and relevant integrations still work.
- The repair has a recorded cause, exact change, and rollback route.
The WooCommerce checkout testing checklist covers the wider acceptance process. Do not restore an old database over new customer orders as a quick rollback. If the change involves live transaction data, ask the responsible developer to plan a data-aware recovery.
When to bring in professional help
Contact the payment provider when account restrictions or onboarding requirements are the blocker. Contact the gateway developer when a documented compatibility claim does not match a controlled test. Bring in a WordPress specialist when the fault crosses the checkout builder, custom code, optimization tools, hosting, and payment integration.
Before asking Webless for help, collect the checkout URL, gateway and version, checkout type, affected product, supported destination, first failure time, and recent changes. Do not put login details or payment secrets in a general contact form. We can then discuss the investigation and whether it fits a repair or development engagement.
For prevention, agree which payment paths should be retested after updates as part of your WordPress maintenance. A successful update notice is not a checkout test, and one working payment method is not proof that every customer can pay.