Troubleshoot Square Apple Pay domain verification errors

Use this guide when WooCommerce Square reports that Apple Pay domain verification received an HTTP 403 response. You’ll capture the verification-file response, compare it with your CDN and server logs, and identify the rule that needs attention.

Before you start

↑ Back to top

You need a terminal with curl, access to the store’s Square logs, and access to CDN/firewall and web server logs. Work with the hosting provider if you don’t manage those systems. Start with the merchant-facing Apple Pay verification checks.

Capture the failed verification attempt’s hostname, timestamp and time zone, status, and error text. If your request logs include a User-Agent, keep that value for comparison. Don’t assume every verification request uses the same User-Agent.

Request the verification file

↑ Back to top

The verification URL uses the path /.well-known/apple-developer-merchantid-domain-association on the store’s hostname. WooCommerce Square manages the association file and registers the store’s home-URL hostname with Square. Check the exact hostname shown in the failed attempt, including any www prefix.

Replace example.com with that hostname and USER_AGENT_FROM_LOGS with the observed User-Agent. If the User-Agent isn’t available, omit the --user-agent option and record that limitation. Run the command from a directory where you can save the diagnostic files:

curl --silent --show-error \
  --user-agent 'USER_AGENT_FROM_LOGS' \
  --dump-header apple-pay-headers.txt \
  --output apple-pay-body.txt \
  --write-out 'HTTP %{http_code}\n' \
  'https://example.com/.well-known/apple-developer-merchantid-domain-association'

This sends a GET request and saves the response headers and body separately. It prints the HTTP status, keeps TLS certificate validation enabled, and doesn’t follow redirects. For example, if your logs show Go-http-client/2.0, use that exact value for the comparison.

Interpret the response

↑ Back to top

• 403: Inspect the saved body and headers, then correlate the request with your CDN and origin logs. A response may identify a firewall product or rule, but confirm that evidence in the corresponding logs.
• 301 or 302: Inspect the Location header. Record the redirect before making another request; an automatically followed redirect can hide the original response.
• 404: Check whether the association file exists in the document root used by the public hostname and whether the server serves that location.
• 200: Check that the body is the association file rather than a login page, challenge, or other HTML response. A successful local request doesn’t establish that Square’s external request succeeds.

Using the same User-Agent only reproduces one request attribute. Your terminal’s IP address, network route, and TLS behavior can differ from the verifier’s, so compare the actual failed verification attempt too.

Find the blocking layer

↑ Back to top

• Check the CDN or firewall’s request and security logs for the verification path and timestamp. Record the action, matched rule, and request identifier when available.
• Check the origin server’s access and error logs for the same attempt. A request allowed by the CDN can still receive a 403 from an origin rule.
• If no matching origin entry appears, confirm that you searched the correct host, time zone, and log source. Missing log entries alone don’t prove which layer blocked the request.
• Have the responsible administrator adjust the specific rule that blocks legitimate access to the verification file. Keep the change limited to the required resource; don’t disable the site’s firewall or bot protection globally.

Verify after the change

↑ Back to top

Repeat the GET request and check its status and body. Then revisit the WooCommerce Square settings screen with Square logging enabled to check the domain registration result. Successful domain registration is the expected outcome; an HTTP 200 from curl alone isn’t sufficient.

If verification still fails, collect the new error, its timestamp, the response status, and the matching CDN/origin log entries for your hosting provider or developer. Keep diagnostic files private and remove access tokens, cookies, personal information, and unrelated requests before sharing them.

Reference

↑ Back to top

Square’s RegisterDomain API reference describes domain registration and the required association file. The WooCommerce Square extension handles registration; this diagnostic does not require manually calling the API.

Questions and support

↑ Back to top

Do you still have questions and need assistance? 

• Get in touch with a Happiness Engineer via our Help Desk. We provide support for extensions developed by and/or sold on WooCommerce.com, and Jetpack/WordPress.com customers.
• If you are not a customer, we recommend finding help in the WooCommerce support forum or hiring a Woo Agency Partner. These are trusted agencies with a proven track record of building highly customized, scalable online stores. Learn more about Woo Agency Partners.