Missing WooCommerce payment method: check activation, conditions and compatibility

Specify which option is missing and where

A method appears enabled in administration, but customers cannot find it at checkout. An active gateway does not promise display for every cart. Country, currency, amount, product type, shipping and form may all matter. The desired result is a method visible for purchases it is actually intended for.

First distinguish the gateway connecting the store to a service from the specific method it offers. One plugin may offer cards, local bank transfer and express buttons. Its presence in the plugin list does not guarantee every method is enabled. An express button above the form does not necessarily replace a classic payment option below.

This guide concerns a WordPress store already using WooCommerce with administrative permission for settings. The provider dashboard may require separate authorization. In multisite, check the correct site. On WordPress.com, open WooCommerce settings in store administration; payment-service conditions remain separate from the hosting plan.

WooCommerce is a free plugin; payment methods have their own conditions and sometimes service fees. Payment is not a WordPress-core-only function. Installing a new gateway is unnecessary before understanding why the intended one does not appear.

Build a comparison case without making a payment

Record the exact expected method, page, amount after discount, currency, billing and shipping countries, shipping method and cart products. Specify whether the visitor is logged in. Compare a missing-method case with one actually known to be eligible instead of an old memory of its appearance.

Check the final total. If a full discount leaves nothing to pay, WooCommerce may not display normal payment selection. This is not a provider connection failure. Do not change a public product’s price to test: use an isolated copy and diagnostic product.

Also identify checkout type. Under WooCommerce, Settings, Advanced, record the assigned page and open it under Pages. List View shows a Checkout block or classic shortcode form unless a builder supplies its own module. An integration compatible with one is not automatically compatible with every other.

For comparisons changing settings, use a copy with a separate database, gateway connected to its test environment and other external effects disabled. Use fictional test contact information, never a customer’s details or payment methods. Simply inspecting the live-site form does not require clicking Place order. Do not ask customers to make repeated purchases or change their real address to reveal a method unavailable in their country.

• Method disabled or setting unsaved: use the first route.
• Method enabled but absent for some carts: examine availability conditions.
• Method expected for an eligible case but invisible: check form compatibility and loading.
• Payment already collected: change diagnosis and reconcile the order before another attempt.

Route 1: check the activation that actually controls the method

Open WooCommerce, Settings, Payments. Find the service already used, check its state and open Manage or its settings. A plugin installed but inactive under Plugins cannot provide its form. Conversely, an active plugin may keep its payment option disabled. Record values before any correction.

If activation was overlooked, confirm the service is among the store’s authorized methods. Do not simultaneously change merchant account, payment mode and currency: you would no longer know which value explains the option’s return.

Offline methods included in WooCommerce, such as bank transfer or cash on delivery, are under Take offline payments or its translated equivalent in current Payments settings. Use Enable, then Manage for the intended method. Do not add them as false substitutes for card payment: they require a different tracking process.

The expected result is a method offered in a compatible case with the intended title and instructions. Enabling it alone collects no funds but makes it available to customers; verify the organization can handle it. To undo an unsuitable diagnostic activation, restore its initial state and save.

If all states are correct, continue with cart conditions and the provider account. Reinstalling a plugin or recreating keys is not automatically next: absence may be a normal availability decision.

1. Under Installed Plugins, confirm the intended gateway is active.
2. Under WooCommerce, Settings, Payments, open Manage for that gateway and record its initial state.
3. Enable only the intended method and save changes.
4. Reload the same screen to verify the retained value, then refresh the test cart without placing an order.
5. If activation was unjustified, restore the initial state and save the rollback.

Route 2: correct an inconsistent availability condition

This route fits a method missing only for a group of carts. Start with the simplest case: an in-stock product, positive amount and destination the store serves. Then change one characteristic at a time on the isolated copy. An address change may alter shipping and taxes together; record the final result, not just the entered value.

For WooCommerce’s included cash on delivery, open its settings from Payments, Take offline payments, then Manage. Examine Enable for shipping methods: restrictions must match the methods and rates actually selected. A recreated shipping method or another rate instance may no longer match the original selection.

Also examine Accept for virtual orders. A cart without shipping may be excluded if this option disallows virtual orders. Enable it only if your organization genuinely accepts this payment for those products. Revealing a method that cannot be collected is not a repair. Retain initial values and save only the justified correction.

For an online gateway, check supported currencies, countries, amounts and product categories. Recurring purchases, bookings or preorders may require specific support. Availability for one-time payment does not guarantee subscription support. Do not force display with a code snippet ignoring these conditions.

The expected result is presence for authorized cases and absence for intentionally excluded ones. Then repeat the original cart to confirm the difference. If adjustment was unjustified or ineffective, restore the saved value before another comparison. Rules from a restrictions plugin must be examined in that plugin, not assumed to belong to WooCommerce core.

Check both levels of Stripe settings

If the store specifically uses WooCommerce Stripe Payment Gateway, open WooCommerce, Settings, Payments, Stripe. This free plugin differs from WooPayments and other plugins using Stripe. Payment-service fees and conditions remain separate. Verify its exact name under Installed Plugins before following this route.

In general settings, check Enable Stripe. Under Payment Methods, then check the individual expected method, select it if consistent with policy and save. When synchronization is active, these choices are also sent to the Stripe configuration associated with WooCommerce. A change from a copy may therefore extend beyond that copy if it uses the live account: confirm the test environment before changing methods.

Also inspect Account details for the connected account and any restrictions. On the copy, open Configure connection, then Test to verify test connectivity; under General, select Enable test mode and save. If that connection is missing, have the account administrator prepare it before testing. Do not switch the live store between live and test modes to diagnose its copy. Resolve account restrictions in the affected account instead of bypassing them with another organization’s keys.

If you just changed a method, refresh the plugin’s Payment Methods page, then checkout. A configuration update may require data refreshing; that does not justify deleting all WordPress temporary settings. Keep the same eligible cart for comparison.

The expected result is consistent activation of the gateway and supported method in the correct account. If Account details shows Sync disabled, do not assume a change propagated between dashboards. A method visible in Stripe may also be unsupported by the WooCommerce plugin. Verify that precise compatibility before concluding there is a bug. To undo unnecessary activation, restore the method’s original state and save.

Distinguish a missing express button from missing classic payment

Express buttons also depend on browser, device and customer wallet configuration. Their absence on one machine does not mean classic card payment is unavailable. Compare the express area and ordinary payment list before concluding the whole gateway is missing.

With Stripe, an expected wallet must be used in a supported environment with a configured payment method when required. A private browser may help isolate cache or an extension, but it can also alter wallet access. It therefore is not, by itself, a universal control for express display.

Also check which pages allow buttons and product compatibility. A button present at checkout may not be enabled on product or cart pages. Do not move the entire payment area to imitate another store with different settings and products.

The useful result is more precise than “I see a button”: the expected method appears in the correct location for a supported environment and cart. Keep working classic payment when policy calls for it. Do not request personal wallet data or a real purchase to prove eligibility. Use the documented test route for the relevant wallet; success on one device does not guarantee display on all others.

Route 3: check the form and scripts on an isolated copy

If the case is eligible and settings are correct, examine the form used. For the Checkout block, the gateway must offer block-compatible integration with its scripts and availability checks. An old classic integration may be active in administration without supplying the interface expected in that block.

In the Checkout page editor, open List View and select Payment Options. Its sidebar lists active integrations and may flag incompatible ones. The editor preview does not, however, verify real-cart eligibility: check that on the copy’s public form.

On the isolated copy, check the installed version’s declared compatibility and dependencies. Update only within a compatible, backed-up set of versions. Do not immediately switch all production from blocks to a classic form: other fields, shipping rules or integrations may depend on the current flow.

In Chrome, open developer tools through More tools, then Network. Clear only the displayed request list, reload Checkout and find the failing payment script. Select its row to read status and headers, then inspect Console for the associated error. Keep the file and first relevant error without sharing tokens or exporting all session data. If a style rule merely hides the form, removing it may reveal the element; that does not make an ineligible method usable.

Then compare without the suspected script transformation only on this page and copy. Use options of the existing tool and its documentation without adding a second optimizer. If protection blocks the request, have the precise rule examined. Do not make the entire API public or globally remove security checks to display the form.

The expected result is an interface loading without the identified error. Confirm by restoring the suspected component on the copy: failure must be attributable to the same scenario. Restore ineffective settings. If a component remains incompatible, retain the understood production configuration and have a compatible correction chosen before deployment.

1. Record form type and the compatibility signal in the editor without publishing another form.
2. Reload the copy’s public page with the same cart and record the network or JavaScript error.
3. Change only the suspected script exclusion in the existing optimizer, retaining its initial value.
4. Compare the result, then restore that setting on the copy to verify whether the same error returns.
5. Retain only an explained correction; restore ineffective tests before preparing production deployment.

Read logs without confusing visibility with bank authorization

Under WooCommerce, Status, Logs, examine gateway events when opening the form. An account-connection or method-retrieval error offers a different lead from a bank rejection after submission. Absence of a payment in the log is normal if you only displayed the page.

For the cited Stripe plugin, the setting is under Advanced settings: Debug mode, Log error messages. Record its value, enable it temporarily and save, then reload the safe case once. Read the corresponding Stripe log under WooCommerce, Status, Logs. After collecting evidence, restore the initial logging value and save. For another gateway, follow its own documented route. These logs concern future events, not unrecorded past ones. Remove personal data, tokens and secrets before sharing a targeted excerpt.

Under WooCommerce, Status, System Status, examine versions and overridden theme templates. An old checkout template may explain a display difference but its presence alone does not prove responsibility. Compare with the compatible template on the copy before changing the active theme.

To request a correction, supply the precise method, anonymized cart, country and currency, form type, versions and first error. Saying only “payments do not work” mixes display, authorization and collection. Previous checks help the administrator address the right level without requesting another customer card.

Check authorized cases and retained exclusions

After correction, repeat a case that should display the method and one that should remain excluded. For example, an intentional shipping restriction must still apply to unsupported deliveries. A change revealing the method to everyone may have removed a necessary commercial condition.

On the secured copy, then complete one test-mode order if the correction affected integration or scripts. A visible payment option does not prove submission succeeds. Verify the single order, test result and expected status without replaying a real payment.

Keep final values and rollback procedure: method state, targeted rule or compatible component version. Do not restore the entire store database to undo activation. Recent orders must be preserved when applying the correction.

The missing method is restored when activation, conditions and interface match the customer’s actual need. If payment becomes visible but then loads endlessly, return to request diagnosis. If collection already exists without consistent status, reconcile that transaction before another attempt.

For developers: check both sides of a block payment gateway

A custom payment integration contains a server side and JavaScript registration in the Checkout block. Declaring a PHP gateway alone does not supply its block interface. Conversely, displaying a JavaScript component does not prove the server accepts the corresponding payment.

The maintainer first examines script registration, dependencies and the identifier linking the method to the server. They then check canMakePayment, the callback deciding whether the method suits the cart and customer context. The editor uses a preview; that rendering does not replace evaluating the public cart. A rejected promise, missing dependency or overly restrictive condition each calls for a different fix.

On the copy, retain two test carts: one eligible and one intentionally excluded. After correction, the method should appear only in the first. The test must not systematically replace canMakePayment with true: that could remove currency, product or wallet restrictions that make the method usable.

Native free WooCommerce settings remain the merchant’s first route. Code here belongs to the gateway owner; they must deliver a versioned, block-compatible fix and then verify one order in the provider’s test mode. If testing fails, restore that targeted version without changing prices or the order database.