WooCommerce Apple Pay Not Showing on Checkout Block

The Problem

I ran into this on a client project last week: WooCommerce 10.6, the new Checkout block, Stripe Gateway 9.4. Apple Pay had been working in the classic shortcode checkout, the merchant migrated to the block, and the Apple Pay button silently disappeared on iOS Safari. Google Pay was still there. Stripe Link was still there. Apple Pay, gone.

The Network tab showed no request to apple-pay-gateway-cert.apple.com. The browser console was clean. wc.wcBlocksRegistry.getRegisteredPaymentMethods() listed stripe_payment_request as registered, but canMakePayment was quietly returning false for that gateway. Switching back to the classic checkout shortcode brought the button back instantly, which told me the bug was inside the block stack and not on Apple's side.

If your Apple Pay button is missing from the Checkout block on iOS while everything else renders fine, the cause is almost always one of three things I will walk through below.

Why It Happens

The Checkout block does not call the Stripe Payment Request API the same way the legacy shortcode did. Stripe Gateway 9.x switched the block integration to the new Express Payments slot, and that slot runs three eligibility checks before it will render any button:

1. The domain is registered with Apple Pay. Stripe re-validates this every time the merchant rotates their publishable key, moves between subdomains, or upgrades through a major Stripe Gateway version. The check is /.well-known/apple-developer-merchantid-domain-association served on the exact origin of the checkout page, including the www prefix or its absence.
2. payment_request is a registered feature on the merchant's Stripe account. I see this break after a Stripe support agent toggles "Restrict payment methods" on the merchant account, or after a Radar rule starts blocking the country the test device is on.
3. The current cart is eligible. Apple Pay refuses to render if the cart total is zero, if there are subscription products with a synced billing date in the past, or if shipping is required but no zone matches the customer's geolocated country. The block does not surface a reason, it just hides the button.

The classic checkout was forgiving about all three. The block is not, and the failure mode is silent.

The Fix

Step 1: Confirm the domain association file is reachable on the exact origin. Open the actual checkout URL on the affected device, copy the origin, then curl the association path from a separate network:

curl -I https://www.yourstore.com/.well-known/apple-developer-merchantid-domain-association

You want HTTP/2 200 and content-type: text/plain. If you get a 301 redirect from yourstore.com to www.yourstore.com, register both origins in the Stripe dashboard under Settings → Payment methods → Apple Pay → Domains. A CDN-level redirect is enough to break the validation.

Step 2: Re-register the domain after a Stripe Gateway upgrade. This trips me up every time. Even if the file is still there, Stripe's domains.create record is invalidated when the plugin's PublishableKey hash changes:

add_action( 'admin_init', function () {
    if ( ! current_user_can( 'manage_woocommerce' ) ) {
        return;
    }
    if ( ! isset( $_GET['qc_reregister_apple_pay'] ) ) {
        return;
    }
    $secret = get_option( 'woocommerce_stripe_settings' )['secret_key'] ?? '';
    $domain = wp_parse_url( home_url(), PHP_URL_HOST );

    $response = wp_remote_post( 'https://api.stripe.com/v1/payment_method_domains', [
        'headers' => [ 'Authorization' => 'Bearer ' . $secret ],
        'body'    => [ 'domain_name' => $domain ],
    ] );

    wp_die( wp_remote_retrieve_body( $response ) );
} );

Trigger it once with ?qc_reregister_apple_pay=1 while logged in as an admin, confirm the JSON response shows "apple_pay": { "status": "active" }, then delete the snippet. Do not leave one-shot admin endpoints behind, they always come back to bite you.

Step 3: Verify canMakePayment is returning true in the block. Open the checkout page in iOS Safari, connect it to your Mac for remote debugging, and run this in the console:

window.wc.wcBlocksRegistry
  .getRegisteredPaymentMethods()
  .stripe_payment_request
  .canMakePayment({
    cart: { cartTotals: { total_price: '1000', currency_code: 'USD' } },
    cartNeedsShipping: false,
  })
  .then( console.log );

A false here means the cart itself is failing eligibility. Most common cause: a free-trial subscription with a 0 total, which Apple Pay refuses outright. The fix is to add a one-cent setup fee or to suppress the express slot when the total is zero, using the official Stripe extensibility filter. For another silent block-checkout failure I have written up, see WooCommerce coupon not applying in the Checkout block.

Step 4: Disable the Stripe Gateway "Restrict payment methods" toggle. In the Stripe dashboard, go to Settings → Payment methods, find your live profile, and confirm Apple Pay shows On for the country your tester is in. I have lost more than one afternoon to a Radar rule blocking the UK while the merchant tested from London. The button hides silently, no warning, no admin notice.

Step 5: Force a fresh asset bundle. The Checkout block caches its payment-method registry in localStorage under wc-blocks_payment_method_data. After any of the fixes above, clear that key in the device's DevTools and hard-reload. Otherwise the device keeps serving the cached "Apple Pay unavailable" decision for up to 24 hours.

The Lesson

A missing Apple Pay button on the Checkout block is almost never a Stripe outage. It is a domain that is registered on the wrong origin, a canMakePayment rejection because the cart is ineligible, or a Stripe-side restriction the merchant did not realise was on. Verify all three in that order and the button comes back.

If your store's express checkout is silently dropping conversions on iOS, this is the kind of WooCommerce stabilisation work I do — see my services for how I run an audit.