Background & Use Case
We utilize a custom-designed checkout flow that gathers specific information from the customer before payment.
Because of this structured, multi-step experience, we require the customer to complete the full checkout form before selecting their payment method at the very end of the process.
The Current Limitation
Currently, the plugin only allows Apple Pay, Google Pay, and Link to appear as distinct “Express Checkout” buttons at the top of the page.
To use an analogy, the current flow is like going to a grocery store and being asked to pay before you’ve even put your groceries on the conveyor belt.
In reality, a customer should be able to put all items on the belt first, get the total, and then decide whether to pay via physical card, phone, or watch.
While there are settings to limit these buttons to the checkout page, they still appear at the top and interrupt the custom flow. Express checkout behavior does not fit our business model.
Proposed Solution
Please provide a configuration option to render Apple Pay, Google Pay, and Link natively inside the standard Payment Element list.
These options should be able to sit alongside traditional payment methods (like credit cards, iDEAL, etc.) at the bottom of the checkout form, rather than forcing them to act as separate Express Checkout buttons.
Open
Last updated: March 19, 2026
Log in to comment on this feature request.
Update: we solved it with a third-party gateway, sharing in case it helps others with the same problem.
We switched from the official WooCommerce Stripe Gateway to “Payment Plugins for Stripe WooCommerce” (v4.0.14, free on wordpress.org). It shows Apple Pay, Google Pay and Revolut Pay as separate methods in the regular payment list, next to the card, after the customer has filled in delivery details and sees the final total. Express Checkout stays disabled. Office and locker delivery (Speedy, Econt, BOX NOW) now works with all wallets.
Tested in test mode with card, Google Pay and Revolut Pay orders, including a refund. The payment is confirmed on return to the site and the Stripe transaction ID is saved on the order right away.
What did not work: the filter wc_stripe_ocs_non_excludable_payment_methods in the official plugin. The method appeared in the list, but the order failed server-side validation.
We would still prefer this as a native option in the official plugin, so the request remains relevant.
+1, and here is a concrete case where Express Checkout cannot work at all.
We run a store in Bulgaria. Most customers here choose delivery to a courier office or parcel locker (Speedy, Econt, BOX NOW), selected from a dropdown or map inside the checkout form. The wallet sheet cannot show that choice, so an Express Checkout order either lacks the pickup point or ends up with the wrong shipping cost. For that reason we had to disable Express Checkout completely, which means we cannot offer Apple Pay and Google Pay at all, even though many of our customers expect them.
Letting Apple Pay and Google Pay appear inside the regular payment method list, after the customer has filled in delivery details and sees the final total, would solve this for every store that uses office or locker delivery. This is the standard in many European markets, not an edge case.
exactly. Comment to follow.
As a strong argument for this feature, please look at how Shopify handles this exact scenario.
While Shopify also pushes Express Checkout buttons at the top of the page, if a customer chooses to ignore them and manually goes through the standard multi-step checkout (entering shipping and details first), Apple Pay and Google Pay are still available at the very end, integrated directly into the final payment methods list alongside credit cards.