Apple Pay Domain Verification returning "partial response" — Cloudflare bot management blocking Square's verification crawler

Questions
1

I’m integrating Apple Pay via the Square Web Payments SDK on a custom React/Vite frontend hosted on Lovable (which uses Cloudflare). Domain verification consistently fails with a “partial response” error from Square.

What I’ve confirmed:

  • The apple-developer-merchantid-domain-association file is correctly served at /.well-known/apple-developer-merchantid-domain-association (4549 bytes, confirmed via curl)
  • All Cloudflare Workers, Transform Rules, and custom routing have been removed from the domain — it is DNS-only
  • Lovable has confirmed Bot Fight Mode is disabled on their Cloudflare account
  • The file is accessible from standard browsers and curl with no issues

Root cause hypothesis:
Square’s Apple Pay verification crawler is being identified and blocked by Cloudflare’s bot management layer at the hosting level (Lovable’s Cloudflare account), even with Bot Fight Mode disabled. This may be a Super Bot Fight Mode or managed ruleset issue that Lovable controls at the account level.

What I need from Square:

  1. The IP addresses and/or User-Agent strings used by Square’s Apple Pay domain verification crawler, so I can provide them to Lovable for explicit whitelisting
  2. Whether a manual domain verification option exists as an alternative

Square SDK version: latest Web Payments SDK. Location ID: available on request.

2

:waving_hand: I’m Square Dev AI, here to help answer your question!
Based on the information you’ve provided, the following documentation will help answer your question:

Additional Documentation

Develop for Japan
Enable Apple Pay
Take Payments and Build Integrations on Square Hardware

If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.

4

Hi @agr2133, Square doesn’t publicly share the specific User-Agent string or IP ranges used by the verification bot — since these values are dynamic and subject to change without notice, we don’t recommend building explicit whitelisting flows.

Are you able to reach out to Lovable and inquire about whether there are other options to allow the verification traffic through without explicit IP/User-Agent whitelisting?

5

Thank you for the response, but the linked documentation covers the In-App Payments SDK for mobile applications. My issue is with the Web Payments SDK and Apple Pay domain verification — specifically Square’s verification crawler being blocked at the hosting/Cloudflare layer.

The file is correctly served and accessible. The issue is not with my implementation. I need either:

  1. The IP addresses and/or User-Agent strings Square’s Apple Pay domain verification crawler uses, so our hosting provider (Lovable) can whitelist them in Cloudflare
  2. A manual domain verification option

This has been open since June 5th. Hoping a developer advocate can weigh in directly.

6

Thank you for the clarification — that’s helpful to know.

We have an open ticket with Lovable and have already confirmed with them that Bot Fight Mode is disabled. However, Cloudflare has multiple layers of bot protection beyond Bot Fight Mode (managed rulesets, Super Bot Fight Mode, etc.) that operate at the account/zone level and may not be visible or controllable from Lovable’s dashboard.

A few follow-up questions that would help us work with Lovable more effectively:

  1. Can you confirm the verification request comes as a standard HTTP GET to /.well-known/apple-developer-merchantid-domain-association? Knowing the general shape of the request (method, expected Content-Type in response) would help Lovable identify which traffic to allow through without requiring specific IPs or UAs.
  2. Is there any way to trigger a manual re-verification attempt on demand? We want to test each configuration change Lovable makes in real time.
  3. Has this issue been reported by other developers using Cloudflare-proxied hosting? If there’s a known workaround we’d appreciate the reference.

We’re actively working with Lovable on this — just want to make sure we’re giving them the right information to resolve it on their end.