I’m having an issue verifying a domain for a Merchant ID. I’m implementing Apple Pay on the web for a demo, and I’ve configured the Azure server to match Apple’s requirements for domain verification, such as the TLS configuration, not requiring client certificates, and ensuring there are no redirects.
I’ve run tests with OpenSSL and PowerShell and all responses return HTTP/1.1 200 OK. I also tested the URL Apple says it uses to validate the file under .well-known, and it does show the expected result.
I already have the Apple Pay Payment Processing Certificate and the Apple Pay Merchant Identity Certificate approved; the only thing missing is the domain verification. I’m not sure what else to test—if you could help me with a possible solution, I’d really appreciate it. (The project is built in .NET 8 and hosted on Azure App Service.)
Hi @appleAccount@fttecnologias.com,
You wrote:
[...] I already have the Apple Pay Payment Processing Certificate and the Apple Pay Merchant Identity Certificate approved; the only thing missing is the domain verification. I’m not sure what else to test—if you could help me with a possible solution, I’d really appreciate it. (The project is built in .NET 8 and hosted on Azure App Service.)
Given your setup (.NET 8 on Azure App Service), the fact that your own tests return 200 but Apple's verification still fails is a very specific pattern.
There are two root causes that are almost universal in this exact stack, and they are invisible to your local testing because they only surface when a server (Apple's) makes the request rather than a browser or command-line tool.
- Root Cause 1: IIS Blocks the .well-known Directory by Default
- Root Cause 2: ASP.NET Core Static Files Middleware Blocks Extensionless Files
Root Cause 1: IIS Blocks the .well-known Directory by Default
As far as I know, Azure App Service runs on IIS under the hood. IIS has a built-in security rule that treats any directory starting with a dot as a hidden segment and returns 404 or 404.8 to external requests — even if your local curl or PowerShell returns 200.
This is the single most common cause of this exact failure pattern. To resolve this issue, please refer to the support channels for Azure for more guidance.
Root Cause 2: ASP.NET Core Static Files Middleware Blocks Extensionless Files
Even after fixing IIS, ASP.NET Core's own static file middleware has its own restriction: it will not serve files with unknown or missing extensions by default. Since the domain association file has no extension, it will be silently skipped by the middleware pipeline and likely fall through to a 404.
To resolve this, please contact the support channel for ASP.Net directly.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
