“Apple Pay Domain Registration Failed” — Why the Real Bug Wasn’t Where the Error Pointed

FixesWooCommerce

Estimated reading time: 4 minutes

If you run WooCommerce Stripe Gateway — the official Stripe plugin for WooCommerce — you’ve probably seen this one in your admin dashboard at some point:

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

Worth being specific about the plugin here, since there are a few different ways to get Apple Pay/Google Pay working in WooCommerce, and they don’t all store things the same way. This post is specifically about WooCommerce Stripe Gateway — if you’re on a different payment plugin, the surface symptom might look identical but the underlying fix below (the WP-CLI option patch) won’t apply directly, since it’s fixing a setting specific to this plugin’s data structure.

I hit this recently on a client site, and it’s a good example of why you shouldn’t stop investigating the moment you find an error — because it isn’t always the error.

First stop: the actual log

The dashboard notice isn’t very helpful on its own, but the WooCommerce Stripe logs are (WooCommerce → Status → Logs). The real error underneath was:

cURL error 6: Could not resolve host: api.stripe.com

cURL error 6 means the server itself failed a DNS lookup — it never got as far as talking to Stripe. That’s a hosting/network issue, not a plugin misconfiguration. Worth knowing this code specifically, because it tells you immediately where not to waste time: don’t go digging through API keys or webhook settings, go check connectivity.

Pulling an earlier log turned up a second occurrence of the exact same error nine days prior — that one had failed while fetching the site’s Payment Method Configuration (the list Stripe uses to decide which payment methods are eligible to show at checkout), and the plugin had responded by disabling configuration sync entirely. Two symptoms, one root cause.

Second stop: is it actually still broken?

With SSH access, the obvious next move is to just test connectivity directly:

dig api.stripe.com
curl -v https://api.stripe.com

Both came back clean — DNS resolved, TLS handshake completed, Stripe responded normally. So the network problem was real, but intermittent — not a standing misconfiguration, which changes how you chase it (and is worth escalating to the host with timestamps in hand, since a status page won’t catch account-specific blips).

But here’s the twist: even with connectivity confirmed fine, the admin error was still showing, and the button still wasn’t rendering in early tests. Except — once I actually tested live checkout in a real Safari session (BrowserStack, since Apple Pay is Safari-only and I didn’t have a Mac handy), the button was working perfectly. Customers were never actually blocked. The dashboard was lying to me.

Third stop: why won’t the notice go away?

This is the part worth remembering. Toggling the Apple Pay setting off and saving made the notice disappear. Toggling it back on and saving brought it straight back — but with no new log entry at all. That’s the tell: if the plugin isn’t even attempting a fresh registration, the notice can’t be reflecting a live check. Something was just stuck.

A quick WP-CLI dig into the stored settings confirmed it:

wp option get woocommerce_stripe_settings --format=json

Buried in there:

"apple_pay_verified_domain": "example.com",
"apple_pay_domain_set": "no"

apple_pay_verified_domain already matched the live domain correctly — so the plugin had no reason to think anything needed re-checking. But apple_pay_domain_set was still sitting on "no" from the earlier failed attempt. Two related fields, tracking overlapping state, quietly out of sync. The plugin’s own logic meant this pairing had no path back to “yes” on its own.

The fix

One WP-CLI command, clearing the field the plugin actually checks for a mismatch:

wp option patch update woocommerce_stripe_settings apple_pay_verified_domain ''

That forces a genuine mismatch, which forces a genuine re-verification — which, since connectivity was fine, succeeded immediately and cleared the notice properly.

Takeaways

  • cURL error 6 = DNS failure, full stop. Check host-level connectivity before touching plugin settings.
  • An admin error notice and actual site behaviour can disagree. If you can, test the real thing (a live checkout, a live button) before trusting what the dashboard is telling you.
  • No new log entry on a retry is itself a diagnostic clue — it tells you the thing you’re looking at isn’t a live check, it’s stored state.
  • WooCommerce Stripe Gateway tracks Apple Pay domain status across two separate option fields that can fall out of sync after a failed attempt. If you’re stuck on this exact error and a re-save isn’t clearing it, this is worth checking before anything more drastic.
0
0