When a client’s WooCommerce store started showing an “Apple Pay domain registration failed” warning in the WordPress admin, I knew we had an interesting problem to solve. What made it particularly puzzling was that Apple Pay buttons were appearing and working on product pages, but weren’t showing up on the cart or checkout pages—despite the plugin settings having them enabled for all three locations.

This is exactly the kind of challenge that gets our team excited at Creare Web Solutions. We don’t just apply quick fixes; we dig deep to understand why things happen and how systems work. This approach not only solves the immediate problem but often uncovers insights that prevent future issues.

Let me walk you through the entire troubleshooting journey—from initial confusion to discovering that the main issue was overly strict security rules, with a surprising simple solution to the admin warning at the end.

The Problem: A Warning That Didn’t Make Sense

The WordPress admin was displaying this persistent error:

“Apple Pay domain registration failed. Please check the logs for more details on this issue.”

The confusing part? Apple Pay buttons were appearing and working on product pages, but the plugin settings clearly showed they should also appear on cart and checkout pages—yet they didn’t:

• Apple Pay button appeared on product pages and worked correctly
• Customers could complete purchases with Apple Pay from product pages
• Plugin settings had cart and checkout locations enabled
• But no Apple Pay buttons on cart or checkout pages
• And that persistent admin error warning

So what was actually broken?

First Stop: The Logs (That Showed Nothing)

As any good developer does, I checked the WooCommerce Stripe gateway logs first. Logging was enabled, and the logs showed normal payment processing, webhook notifications, and API calls—but no Apple Pay domain registration errors.

This was our first clue that something more subtle was happening.

The Cloudflare Investigation

We use Cloudflare security rules to help protect our clients’ WordPress sites from bad actors—particularly blocking suspicious traffic to login and admin screens. It’s an effective layer of defense, but sometimes these security rules can be too strict for legitimate functionality like WooCommerce checkout processes.

Since the site uses Cloudflare, I suspected that might be interfering with the Apple Pay buttons loading on cart and checkout pages. We discovered that Cloudflare’s security rules were blocking requests to /wp-json endpoints—but there was a typo in the bypass rule.

The rule had:

starts_with(http.request.uri.path, "wp-json")

But it needed to be:

starts_with(http.request.uri.path, "/wp-json")

That missing leading slash meant WooCommerce’s REST API wasn’t bypassing security checks. This is crucial because modern WooCommerce features—including payment request buttons—rely heavily on REST API endpoints to function properly.

Building a Comprehensive WooCommerce Cloudflare Bypass Rule

While fixing the /wp-json rule, we took the opportunity to build out a complete bypass rule for all critical WooCommerce paths. Here’s what we ended up with:

(http.request.uri.path contains "admin-ajax.php") or 
(http.cookie contains "wordpress_logged_in") or 
(http.request.uri.path contains "wp-includes/js") or 
(starts_with(http.request.uri.path, "/app/plugins/")) or 
(starts_with(http.request.uri.path, "/wp-json/")) or 
(starts_with(http.request.uri.path, "/wc-api/")) or 
(http.request.uri.query contains "wc-ajax=")

Let me break down why each of these is important:

• /wp-json/ – The WordPress REST API that modern plugins and themes rely on. Critical for WooCommerce blocks, payment integrations, and real-time data updates.
• /wc-api/ – WooCommerce’s legacy API endpoints. Payment gateways like Stripe, PayPal, and others use these for webhooks and IPNs (Instant Payment Notifications). If these are blocked, you won’t receive payment confirmations.
• ?wc-ajax= – Modern WooCommerce AJAX requests used for cart updates, checkout field validation, and dynamic content loading. Blocking these breaks the checkout experience.
• admin-ajax.php – WordPress’s AJAX handler, used extensively by WooCommerce for backend operations.
• wordpress_logged_in cookie – Ensures logged-in users don’t get aggressive security challenges while managing their accounts or checking order history.

This comprehensive rule ensures that all WooCommerce functionality—from browsing products to completing checkout to receiving payment webhooks—can bypass Cloudflare’s security challenges without compromising overall site security.

We fixed that, which immediately improved overall site functionality, but the Apple Pay error persisted.

The Page Caching Factor

After fixing the Cloudflare rules, we still weren’t seeing Apple Pay buttons on cart and checkout pages consistently. The site had page caching enabled, and I suspected this might be compounding the issue.

Here’s what we think was happening: With the Cloudflare rules blocking critical /wp-json and /wc-api endpoints, the Apple Pay button initialization was failing. Modern payment request buttons likely have fallback mechanisms to handle API failures, but when the page itself is cached, those fallback mechanisms can’t execute properly because the page is serving static HTML without the necessary JavaScript execution context.

When pages are cached, they’re missing:

• Fresh Stripe publishable keys
• WooCommerce checkout nonces
• Dynamic cart and order data

The combination of blocked API endpoints (from Cloudflare) plus cached pages (no dynamic data) meant the buttons couldn’t initialize at all on cart and checkout. Product pages were working because they have simpler initialization requirements and possibly different fallback behavior.

We temporarily disabled page caching and confirmed that cart/checkout Apple Pay buttons started appearing after the Cloudflare rule fix.

Pro tip: If you’re using page caching with WooCommerce, always exclude these paths:

• /checkout/*
• /cart/*
• /my-account/*
• /wc-api/*

The hCaptcha Mystery

During this investigation, I noticed failed requests to api.hcaptcha.com with 401 errors in the browser’s network tab. This seemed suspicious until I realized what was likely happening.

Stripe now uses invisible hCaptcha as part of their fraud prevention system (Stripe Radar). The JavaScript loads from Stripe’s servers automatically. Based on what we observed, those 401 responses appear to be part of the normal challenge/response flow that hCaptcha uses to verify users aren’t bots—essentially testing whether a challenge is needed before proceeding with a successful verification.

We think this is what’s happening: If you see both 401s and 200s from hCaptcha in the same request waterfall, the 401s are likely initial challenge checks, and the 200s are successful verifications. This pattern suggests the system is working as designed rather than indicating an error.

Of course, if you’re seeing only 401s with no successful 200 responses, that would indicate a real problem. But the mixed pattern we observed seemed to be normal operation.

Down the .well-known Rabbit Hole

Now things got really interesting. I started researching how Apple Pay domain verification actually works. Here’s what I learned:

When you enable Apple Pay through Stripe, the process is supposed to work like this:

1. WooCommerce plugin makes an API call to Stripe: POST /v1/payment_method_domains
2. Stripe registers your domain for Apple Pay
3. Stripe/Apple verify domain ownership by checking for a specific file at: https://yourdomain.com/.well-known/apple-developer-merchantid-domain-association
4. This file contains a cryptographic signature proving your domain is authorized

The interesting part? This file is the same for everyone using Stripe. It’s Stripe’s Apple Pay merchant ID, not yours. You can download it from https://stripe.com/files/apple-pay/apple-developer-merchantid-domain-association.

The Nginx Complication (And a Critical Misunderstanding)

Our client’s server uses Let’s Encrypt for SSL certificates, which also uses the .well-known directory. Their Nginx configuration routes .well-known requests to a directory outside the web root (/sites/.certbot/.well-known), which is smart for security but meant the Apple Pay file couldn’t be placed in the standard web root location.

We set up a parallel structure:

1. Created /sites/.applepay/.well-known/
2. Downloaded the Apple Pay domain association file there
3. Added an Nginx rule to serve it:

location = /.well-known/apple-developer-merchantid-domain-association {
    alias /sites/.applepay/.well-known/apple-developer-merchantid-domain-association;
    default_type application/octet-stream;
    auth_basic off;
    allow all;
}

We could verify the file was now accessible:

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

It downloaded successfully. Perfect! We disabled and re-enabled Apple Pay in WooCommerce to trigger re-registration.

The error persisted.

Plot Twist: This Was All Completely Unnecessary

Here’s where things get interesting. After solving the actual problem (spoiler: it was a stuck database flag), I removed all the Nginx rules and the .well-known file we’d carefully set up. The error didn’t come back. Apple Pay continued working perfectly.

Why? Because the WooCommerce Stripe Gateway plugin doesn’t use the .well-known file approach at all.

The modern WooCommerce Stripe Gateway plugin uses Stripe’s Payment Method Domains API. When you register a domain through this API (which the plugin does automatically), Stripe handles all the Apple merchant validation on their servers. According to the plugin documentation: “You do not need to upload the verification file to your site – the extension does this for you in the background.”

The .well-known file approach is only required for:

• Self-hosted custom Stripe implementations
• Third-party payment gateways that don’t use Stripe’s automatic registration
• Manual Stripe integrations that aren’t using the Payment Method Domains API

So all that work—researching Apple Pay verification, understanding cryptographic signatures, setting up parallel Nginx configurations, managing file permissions—was educational but ultimately unnecessary. The plugin already handles everything automatically through Stripe’s API.

Sometimes the rabbit hole teaches you a lot, even if you didn’t need to go down it in the first place.

The Actual Problem: A Stuck Database Setting

After all that investigation, I took a closer look at the WooCommerce Stripe settings stored in the database:

{
  "apple_pay_verified_domain": "moondancejewelry.com",
  "apple_pay_domain_set": "no"
}

There it was. The domain was set, but the registration flag was stuck at “no”.

Looking at the plugin’s code, I found this logic:

public function register_domain_on_domain_name_change() {
    if ( $this->domain_name !== $this->get_option( 'apple_pay_verified_domain' ) ) {
        $this->register_domain_if_configured();
    }
}

The plugin only attempts registration when the domain changes. Since apple_pay_verified_domain was already set to the current domain, the plugin thought there was nothing to do—even though apple_pay_domain_set said the registration had failed.

The Simple Solution

The fix was remarkably simple:

wp option patch update woocommerce_stripe_settings apple_pay_verified_domain ""

By clearing the apple_pay_verified_domain field, we forced the plugin to think the domain had changed. When we disabled and re-enabled Apple Pay in WooCommerce, it attempted registration again.

Stripe’s API responded: “This domain is already registered and verified.”

The plugin updated apple_pay_domain_set to “yes” and the error disappeared.

The domain had been successfully registered with Stripe all along. At some point in the past, registration had worked fine. The local WordPress database setting had just gotten into a weird state, probably from a failed registration attempt that was later successful, but the flag never got updated.

We even tested by removing all our carefully crafted Nginx rules and the .well-known file—the error didn’t come back. Stripe already had the domain on file.

So to summarize what we actually fixed:

• Cloudflare security rules: Were blocking critical WooCommerce API endpoints, preventing Apple Pay buttons from loading on cart and checkout pages
• Page caching configuration: Wasn’t excluding dynamic checkout pages, which compounded the API blocking issues
• Admin error warning: Was caused by a stuck database flag that just needed to be cleared

The first two were real functionality problems affecting customers. The third was just a persistent warning that made it look like something was broken when it wasn’t.

What We Learned

1. Logs aren’t always the full story: The WooCommerce logs showed no errors because the actual registration attempts were happening successfully at the API level.
2. Frontend functionality doesn’t always match admin status: Apple Pay was working on product pages because Stripe’s systems knew about the domain, even though WordPress didn’t realize it. Cart and checkout had additional issues with blocked API endpoints.
3. Security rules need careful configuration for eCommerce: Cloudflare rules that protect login and admin screens can inadvertently break critical WooCommerce functionality if they’re too broad. Always test checkout processes after implementing security rules.
4. Page caching compounds API issues: When API endpoints are blocked, fallback mechanisms in modern payment buttons may not work properly on cached pages. The combination creates a harder-to-diagnose problem than either issue alone.
5. Not all documentation applies to your specific implementation: General Stripe Apple Pay documentation describes the .well-known file approach, but the WooCommerce Stripe Gateway plugin handles this automatically through Stripe’s Payment Method Domains API. Always check if your specific plugin or framework has a more modern implementation.
6. Sometimes the simplest solution comes last: After investigating Cloudflare rules, page caching, hCaptcha, Nginx configurations, and file permissions, the answer to the admin error was a single stuck database flag.
7. Understanding how systems work still matters: Even though we didn’t need the .well-known file infrastructure, understanding Apple Pay’s domain verification process was valuable for future troubleshooting—and for knowing when we can skip certain steps.

Frequently Asked Questions

The Quick Fix for Others

If you’re facing this same “Apple Pay domain registration failed” error in WooCommerce with Stripe:

Important note: If you’re using the official WooCommerce Stripe Gateway plugin, you do NOT need to manually place any .well-known files on your server. The plugin handles domain registration automatically through Stripe’s Payment Method Domains API. Don’t go down that rabbit hole like I did!

Step 1: Check if buttons are actually appearing

Before fixing the admin error, verify whether Apple Pay buttons are actually showing up where they should:

• Test on product pages
• Test on cart page
• Test on checkout page

If buttons aren’t appearing on cart/checkout but work on product pages, check your Cloudflare security rules (or other WAF/security plugins) to ensure they’re not blocking WooCommerce API endpoints like /wp-json/, /wc-api/, or ?wc-ajax= requests.

Step 2: Check if Apple Pay actually works

Test it on your product page, cart, and checkout. If it works, your domain is probably already registered with Stripe.

Step 3: Clear the stuck setting

If you have WP-CLI access:

wp option patch update woocommerce_stripe_settings apple_pay_verified_domain ""

Or directly in your database, find the woocommerce_stripe_settings option and set apple_pay_verified_domain to an empty string.

Step 4: Trigger re-registration

Go to WooCommerce > Settings > Payments > Stripe > Configure, then:

• Disable “Payment request buttons” and save
• Re-enable “Payment request buttons” and save

The plugin will check with Stripe, find your domain is already registered, and update the local setting correctly.

Step 5: Verify in Stripe Dashboard (optional)

Go to Stripe Dashboard > Settings > Payment methods > Apple Pay to see your registered domains with green checkmarks.

Why This Approach Matters

At Creare Web Solutions, we could have stopped at “Apple Pay works on product pages” or simply dismissed the admin warning. But that’s not how we operate.

By digging deeper, we:

• Fixed actual broken functionality: Apple Pay buttons weren’t appearing on cart and checkout pages where they should have been, limiting payment options for customers
• Improved overall site security posture: We refined Cloudflare rules to maintain protection against bad actors while allowing legitimate WooCommerce functionality
• Enhanced site performance: Proper page caching exclusions ensure dynamic content works correctly while still benefiting from caching elsewhere
• Built transferable knowledge: Understanding how Apple Pay domain registration works with the WooCommerce Stripe Gateway plugin—and when we can skip certain troubleshooting steps—helps us serve every client faster
• Eliminated confusing admin warnings: No mysterious errors means clients can focus on running their business instead of worrying about their payment systems
• Learned from our wrong turns: The .well-known investigation was unnecessary, but it taught us to always verify whether our specific implementation uses modern APIs that handle things automatically

This is the difference between fixing symptoms and solving problems—even when the solution turns out to be simpler than we expected.

Need Help with Complex WordPress Issues?

If your WooCommerce store is showing errors that don’t make sense, payment systems that seem broken, or you just want a team that digs deep to understand how things actually work, reach out to Creare Web Solutions.

We don’t just turn things off and on again. We investigate, understand, document, and solve problems the right way.

Have you encountered this Apple Pay registration issue? Or discovered your own surprising simple solution after extensive troubleshooting? Share your story in the comments below.

Related Resources:

• Stripe Apple Pay Documentation
• WooCommerce Stripe Gateway Plugin
• Apple Pay Domain Verification