Apple Pay Button Not Showing at Checkout: A Pre-Black Friday Fix List for Stripe Stores
If the Apple Pay or Google Pay button is not showing on your checkout, the cause is usually one of four things: the domain the shopper is on is not registered with your payment provider, the page or browser fails a wallet requirement, the shopper's own device has no card in the wallet, or a code change removed the button. Card payments keep working in every one of these cases, so the store looks healthy while the fastest checkout path is gone.
Work through it in order. Confirm the button is missing for a shopper who should see it (a supported browser with a card in the wallet), then check domain registration for every hostname that serves checkout, then check HTTPS and plugin settings, and only then look at code. If you run a custom Stripe integration, also check whether anyone upgraded to Stripe's 2026-09-30 API version or a matching Stripe.js release: that version removes the old Payment Request Button.
At a glance
- A missing wallet button rarely shows up as an error. Card checkout still works, so nobody reports it.
- Stripe requires every domain and subdomain that displays Apple Pay or Google Pay to be registered, including
wwwandshop.variants. - Some shoppers will never see the button: no card in the wallet, a private browsing window, or an unsupported browser and device pair.
- As of October 2026, Stripe's
2026-09-30.endiveAPI version deprecates the Payment Request Button and rejects thepayment_method_typesparameter with a 400 error. - WooCommerce stores on the Stripe plugin need a valid SSL certificate on the entire site, and Apple Pay also needs port 443 open and TLS 1.2 or later.
- Test from a real device on each checkout hostname after every deploy between now and January.
Why it matters now
Two things make this a task for this week rather than for the quiet season.
The first is Stripe's API release dated 30 September 2026, codenamed Endive. According to Stripe's changelog, from that version elements.create('paymentRequestButton') throws an error, and the React PaymentRequestButtonElement component is affected too. Stripe recommends the Express Checkout Element as the replacement and states that Stripe.js versions up to Dahlia still support the old button. The same release stops accepting payment_method_types when you create, update or confirm Payment Intents and when you create or update Setup Intents. A request that still sends it gets a 400 response with the code payment_method_types_no_longer_supported. Stripe's support article says earlier versions still accept the parameter, so stores hit the error after they upgrade.
A developer who bumps the Stripe library during a pre-peak clean-up can therefore remove the wallet button or break payment creation without touching checkout templates. Stores that use a maintained plugin or a hosted checkout depend on the vendor's choice of API version, which is one more reason to test after plugin updates.
The second is the calendar. Black Friday falls on 27 November 2026. Many teams freeze code a few weeks earlier, so the window to find and fix a missing wallet button without an emergency change is closing. Express wallets save the most effort on mobile, where typing a card number and address takes longest.
Step-by-step: find out why the wallet button is missing
1. Confirm the test device should see the button
Stripe's wallet testing guide lists conditions on the shopper's side. The wallet must hold at least one card. The browser and device must be supported, and private or incognito windows are not. In Safari, the setting that lets websites check for Apple Pay must be on (Settings, Advanced). Stripe also notes that it does not show Apple Pay to IP addresses in India and does not show Google Pay there in live mode.
So before you open any admin panel, use an iPhone with a card in Apple Wallet in normal Safari, and an Android phone with a card in Google Wallet in Chrome. If the button is missing on both, the problem is on your side.
2. Check payment method domain registration
Stripe requires you to register each domain that shows Apple Pay, Google Pay, Link, PayPal, Amazon Pay or Klarna through Stripe, and that includes subdomains. Stripe's own example: example.com, shop.example.com and www.example.com each need registering. You also need registered domains for testing. Registering a domain in live mode registers it in test environments as well.
In the Stripe Dashboard, open the payment method domains settings and compare the list with every hostname your checkout runs on: the bare domain, www, any regional or campaign subdomain, and staging if you test wallets there. A new landing subdomain created for a holiday campaign is a common gap.
On Stripe Connect platforms that create direct charges, the platform must register domains through the API on behalf of the connected account (POST /v1/payment_method_domains with the Stripe-Account header).
3. Check HTTPS and the server
The WooCommerce Stripe documentation lists the site requirements for express checkout: a valid SSL certificate and the entire site served over HTTPS. Apple Pay additionally needs port 443 open, TLS 1.2 or later, and the domain enabled on the Stripe account's payment method domains page. The WooCommerce plugin creates the Apple Pay domain association file for you, so a firewall or security plugin that blocks requests to the .well-known path can still break verification.
An expired or mismatched certificate on one hostname will hide the button there and nowhere else.
4. Check the platform settings
For WooCommerce with the Stripe plugin, go to WooCommerce, Settings, Payments, Stripe, Payment Methods and find the Express checkouts section. The plugin documentation notes that Apple Pay and Google Pay cannot be enabled separately, that card payments must be enabled, and that you choose which pages show the buttons (checkout, product, cart). The settings page includes a preview and eligibility section that lists missing requirements, which is the quickest diagnostic you have.
The same documentation lists product situations where express buttons stay hidden: non-default product types, pre-orders charged on release, composite products, products with file upload fields, free products, and variable subscriptions with out-of-stock variations. Virtual products are also hidden when tax is calculated from the billing address. If the button is missing on one product but present on another, check this list before you suspect a bug.
5. Check the code path (custom integrations)
Search the codebase for paymentRequestButton, PaymentRequestButtonElement and payment_method_types. Then check which Stripe API version your server library pins and which Stripe.js version the front end loads. If either has moved to Endive, migrate to the Express Checkout Element using Stripe's migration guide and replace payment_method_types with dynamic payment methods managed in the Dashboard, or with allowed_payment_method_types / excluded_payment_method_types where you need per-request control.
Stripe's Express Checkout Element documentation adds two details worth checking. Some payment methods need activation in the Dashboard, and a method only appears when the shopper's browser is compatible and the currency is supported. If your checkout sits inside an iframe, Stripe's testing guide says Safari 17 and later need allow="payment" on the iframe, and both the iframe domain and the top-level domain must be registered.
Risk and ownership table
| Risk | Owner | Check | Frequency |
|---|---|---|---|
| Checkout hostname missing from payment method domains | Store owner or agency | Compare Stripe domain list with all live hostnames | Monthly, and when any subdomain is added |
| Certificate expired or wrong on one hostname | Hosting or agency | Certificate expiry and hostname match on every checkout domain | Continuous monitoring |
| Plugin update changes express checkout behaviour | Agency | Real-device wallet test on product, cart and checkout pages | After every plugin or theme update |
Library upgraded to Stripe API 2026-09-30.endive |
Developer | Search for paymentRequestButton and payment_method_types; read the API version in logs |
Before any Stripe library upgrade |
| Wallet share of orders falls without an error | Ecommerce manager | Weekly orders by payment method compared with prior weeks | Weekly during peak season |
| Campaign landing page in an iframe or new subdomain | Marketing and developer | allow="payment" on iframe; domain registered |
Before each campaign launch |
Copyable test plan: express wallet check
Run this on each hostname that serves checkout. Record results in your ticket or change log.
EXPRESS WALLET TEST | Store: ________ | Date: ________ | Tester: ________
Pre-conditions
[ ] iPhone, Safari (not private), card present in Apple Wallet
[ ] Android phone, Chrome (not incognito), card present in Google Wallet
[ ] Safari setting allowing sites to check for Apple Pay is on
Stripe Dashboard
[ ] Payment method domains list includes: bare domain, www, every checkout subdomain
[ ] Apple Pay and Google Pay are enabled in payment method settings
[ ] Server API version recorded: ____________ (Endive or later? Y / N)
Server and site
[ ] Valid certificate on each hostname, whole site on HTTPS
[ ] Port 443 open, TLS 1.2+ (Apple Pay)
[ ] /.well-known/ path not blocked by firewall or security plugin
Per page (product / cart / checkout)
[ ] Apple Pay button visible Page: ____ Result: ____
[ ] Google Pay button visible Page: ____ Result: ____
[ ] Wallet sheet opens with correct total, shipping and tax
[ ] Small test order completes and appears in the order list as paid
[ ] Test order refunded
Code (custom integrations only)
[ ] No paymentRequestButton / PaymentRequestButtonElement in use on Endive
[ ] No payment_method_types sent on Endive (no 400 payment_method_types_no_longer_supported in logs)
[ ] Iframed checkout has allow="payment"
Worked scenario (illustrative)
The numbers here are invented to show the method.
A home goods store on WooCommerce sells through www.example-store.com. For the holiday season the marketing team launches gifts.example-store.com with its own product pages and a cart. On launch day nobody notices a problem: card orders arrive, and the new pages look fine on desktop.
A week later the ecommerce manager compares weekly orders by payment method. On the main site, wallet orders hold at about 30% of mobile orders, as in previous weeks. On the gifts subdomain they are zero. The agency opens the Stripe Dashboard and finds only example-store.com and www.example-store.com in the payment method domains list. They add gifts.example-store.com, run the test plan above on both phones, and see the buttons appear on all three page types. They place and refund a small test order through each wallet, then add "register subdomain in Stripe" to the campaign launch checklist.
Nothing was down and no alert fired. The only signal was a payment-method mix that did not match the main site.
Common mistakes
- Testing on a laptop browser or in a private window, seeing no button, and concluding the integration is broken.
- Registering the bare domain and forgetting
wwwor a campaign subdomain. - Treating a clean card checkout test as proof that wallets work. They are separate paths with separate requirements.
- Upgrading the Stripe server library and Stripe.js during a pre-peak tidy-up without reading the changelog for the target version.
- Forcing a wallet to
alwaysin the Express Checkout Element and assuming it will now appear everywhere. Stripe states this setting does not force display on incompatible platforms. - Running the wallet test once in October and never again after later plugin updates.
Limitations: this list covers Stripe-based integrations and the WooCommerce Stripe plugin. Other gateways and Shopify Payments have their own wallet settings and eligibility rules. Device, browser and region support changes over time, so check the current Stripe and Apple tables rather than relying on a list saved months ago. Some shoppers will never be offered a wallet button, and no store-side fix changes that.
FAQ
Why does Apple Pay show on my phone but not on a customer's?
The customer may have no card in Apple Wallet, may be browsing in a private window, may have the Safari setting for Apple Pay checks turned off, or may be in a region where Stripe does not display it. If it fails for many customers, check domain registration for the exact hostname they used.
Does the Stripe 2026-09-30 change affect my WooCommerce or Shopify store?
It affects code that calls Stripe on that API version or a matching Stripe.js release. Plugins and hosted checkouts choose their own versions, so the risk for most stores comes through updates. Test wallets after each update instead of assuming either way.
Do I need to register my staging domain?
Yes, if you want to test wallets there. Stripe requires registered domains for testing as well as for live payments.
Where monitoring helps
Most of the checks above are manual because only a real device with a real wallet can confirm the button renders. What you can automate is the surrounding signal: certificate and domain expiry on every checkout hostname, and order flow. Pingvera watches SSL certificates and uptime on each hostname, and for WooCommerce stores its connector streams order events so the anomaly detector can alert when the site is up but orders fall below the hourly baseline. Deploys and incidents sit on the same timeline as those order events, which makes it easier to connect a plugin update to a drop in sales. It does not see whether a specific wallet button rendered, so keep the device test in your release checklist.
Related reading: WooCommerce checkout monitoring, How to update WooCommerce safely before Black Friday, Post-deployment website checklist and SSL certificate expired.
Sources
- Stripe changelog, "Deprecates the payment request button" (2026-09-30.endive): https://docs.stripe.com/changelog/endive/2026-09-30/deprecate-payment-request-button
- Stripe changelog, "Removes the payment method types parameter from Payment Intents and Setup Intents": https://docs.stripe.com/changelog/endive/2026-09-30/removes-the-payment-method-types-parameter-from-payment-intents-and-setup-intents
- Stripe Support, "Fix the payment_method_types error": https://support.stripe.com/questions/fix-the-payment-method-types-error
- Stripe Docs, "Register domains for payment methods": https://docs.stripe.com/payments/payment-methods/pmd-registration
- Stripe Docs, "Express Checkout Element": https://docs.stripe.com/elements/express-checkout-element
- Stripe Docs, "Test wallets": https://docs.stripe.com/testing/wallets
- WooCommerce Docs, "Stripe: enabling express checkouts": https://woocommerce.com/document/stripe/setup-and-configuration/express-checkouts/
Last reviewed: 2026-10-21
Know about problems before your customers do
Pingvera watches whether an online business actually works — uptime, checkout, orders, domain, SSL and server — and alerts you in Telegram, email or a webhook before a customer has to tell you.
Start freeRead next: Ecommerce Checkout Friction Audit · The unified timeline: the deploy that broke checkout, next to the… · WooCommerce checkout monitoring: catch a broken checkout before the… · Abandoned Cart Recovery Without Spam · Run a free site check.