- Newest
- Most votes
- Most comments
Two potential options (there are likely more):
- Rename the merchantid file to an
.htmlfile and add a rewrite rule:
Rename the file to include .html and use a rewrite rule to map the original path:
# In your build output:
dist/.well-known/apple-developer-merchantid-domain-association.html
Then add this rewrite rule (place it first in your rules list):
[
{
"source": "/.well-known/apple-developer-merchantid-domain-association",
"target": "/.well-known/apple-developer-merchantid-domain-association.html",
"status": "200",
"condition": null
}
]
Amplify's normalization will find the .html file on the first lookup (step 1 above), serve it with a 200, and your path stays clean.
- Reverse proxy rewrite:
Host the Apple Pay verification file externally (e.g., S3 bucket, API Gateway, or CloudFront function) and use Amplify's reverse proxy rewrite:
[
{
"source": "/.well-known/apple-developer-merchantid-domain-association",
"target": "https://your-s3-bucket.s3.amazonaws.com/apple-developer-merchantid-domain-association",
"status": "200",
"condition": null
}
]
Reverse proxy rewrites are evaluated before the S3 origin lookup, so the trailing-slash normalization never triggers.
Problem
Amplify treats extension‑less paths as directories → adds trailing slash → returns 301 instead of 200.
Solution (rename + rewrite)
-
Rename the file in your repo:
public/.well-known/apple-developer-merchantid-domain-association
→public/.well-known/apple-developer-merchantid-domain-association.json -
Add a rewrite rule (top of list in Amplify Console):
Source Target Type /.well-known/apple-developer-merchantid-domain-association/.well-known/apple-developer-merchantid-domain-association.json200(Rewrite) -
Redeploy.
Why it works
Amplify sees the .json extension → no directory‑slash redirect → serves the file directly.
No other changes needed – Apple Pay verification passes because the final served content matches the expected file.
Relevant content
- asked 6 months ago
- AWS OFFICIALUpdated 4 years ago
