Free multi-brand Apple Pay domain tracker

(function(){ var rows = document.getElementById("ap-rows"); function addRow(domain, proc, date){ var div = document.createElement("div"); div.className = "ap-row"; div.style.cssText = "display:grid;grid-template-columns:1.6fr 1fr 1fr auto;gap:10px;margin-bottom:10px;align-items:center;"; div.innerHTML = '×'; div.querySelector(".ap-del").addEventListener("click", function(){ div.remove(); }); rows.appendChild(div); } addRow("brandone.com", "Stripe", "2025-11-12"); addRow("brandtwo.com", "Braintree", "2025-06-03"); addRow("brandthree.com", "Adyen", "2026-02-18"); document.getElementById("ap-add").addEventListener("click", function(){ addRow("", "", "") ; }); document.getElementById("ap-calc").addEventListener("click", function(){ var rs = rows.querySelectorAll(".ap-row"); var today = new Date(); var results = []; rs.forEach(function(r){ var dom = r.querySelector(".ap-dom").value.trim(); var proc = r.querySelector(".ap-proc").value.trim(); var d = r.querySelector(".ap-date").value; if (!dom) return; var verified = d ? new Date(d) : null; var expiry = verified ? new Date(verified.getTime() + 365*86400000) : null; var daysToExpiry = expiry ? Math.round((expiry - today)/86400000) : null; var status, color; if (!verified) { status = "NOT VERIFIED"; color = "#ff5a5a"; } else if (daysToExpiry < 0) { status = "EXPIRED " + Math.abs(daysToExpiry) + "d ago"; color = "#ff5a5a"; } else if (daysToExpiry < 30) { status = "Expires in " + daysToExpiry + "d"; color = "#ffa940"; } else if (daysToExpiry < 90) { status = "Expires in " + daysToExpiry + "d"; color = "#ffd666"; } else { status = "OK (" + daysToExpiry + "d left)"; color = "#52c41a"; } results.push({dom:dom, proc:proc, status:status, color:color, days:daysToExpiry}); }); results.sort(function(a,b){ return (a.days||0) - (b.days||0); }); var html = ''; var expired = results.filter(function(r){ return r.days = 0 && r.days < 30; }).length; html += ''; results.forEach(function(r){ html += ''; }); document.getElementById("ap-result").innerHTML = html; }); document.getElementById("ap-calc").click(); })();

Why Apple Pay domains quietly expire and break checkout

Apple Pay domain verification is not a set-and-forget task. Apple rotates the verification requirement on a 365-day cycle. Merchants register once, assume it's permanent, and then discover 11-13 months later that the Apple Pay button has silently stopped rendering. Conversion drops. Nobody notices for weeks. The fix is trivial — re-upload the .well-known/apple-developer-merchantid-domain-association file and re-verify — but the damage done during the gap is real, especially for mobile-heavy stores where Apple Pay accounts for 18-35% of mobile conversion.

For a single-brand operator this is manageable. For a multi-brand operator with 8-20 brands, each on potentially different processors, with different verification dates and different .well-known file contents (each processor issues its own verification file), it's a maintenance nightmare without a tracker.

What the tracker shows

One row per brand domain. Each row has: the domain, the processor the domain is registered with (Stripe, Braintree, Adyen, or direct Apple Merchant ID), and the date of last verification. The tracker calculates days until the 365-day rotation and flags domains that are within 30 days of expiry (warning) or already past (critical). Sort by expiry date ascending — the ones about to break are always at the top.

The three processor-specific workflows

Stripe

Each Stripe account has its own set of Apple Pay domain registrations. A domain registered on Stripe Account A is not recognized by Stripe Account B, even for the same domain. This matters for multi-brand operators who use a Stripe account per brand — each brand needs its own Apple Pay domain registration, and the .well-known file needs to be Stripe-issued for that specific account. Registration via Dashboard → Settings → Payments → Payment methods → Apple Pay → Add domain.

Braintree (PayPal)

Braintree uses its own Apple Pay registration flow. One merchant ID in Braintree can serve multiple brands if they're all sub-merchants under the parent. .well-known file is issued by Braintree's dashboard. 365-day rotation applies.

Adyen

Adyen MotoPay and Adyen Checkout have separate Apple Pay registration flows. Multi-merchant Adyen accounts need per-merchant domain registration. The .well-known file is Adyen-issued and distinct from Stripe's.

Direct Apple Merchant ID

For operators doing their own integration via the Apple Pay JS SDK, the merchant ID lives in the Apple Developer Portal and the verification is done there. This is the most flexible but requires native crypto handling for payment tokens. Rare for off-the-shelf ecommerce.

Multi-brand gotchas

.well-known file collision

Every brand domain needs a .well-known/apple-developer-merchantid-domain-association file at the root. If two brands share a server or CDN, make sure each domain's .well-known path serves the correct file — not the file from another brand. Apple fetches that specific URL from each domain to verify; if brandone.com serves brandtwo.com's verification file, Apple declines the registration.

Subdomain vs apex

Apple verifies at the exact hostname. apex.com and www.apex.com are separate registrations. checkout.apex.com is a third. Most brands need at least apex + www, and operators with separate checkout domains need all three. Missing one leaves an entire customer segment without Apple Pay.

CDN cache for .well-known

Some CDNs (Cloudflare especially) cache .well-known paths aggressively. When you update the file for re-verification, clear the CDN cache explicitly — a stale file will cause the re-verification to fail even though your origin has the new file.

Subprocessor changes

If you migrate a brand from Stripe to Braintree, the old Stripe-issued .well-known file stops working at Stripe's end but might still be present on your server. The domain is now verified against the wrong processor. Remove the old file, upload the new Braintree-issued one, re-verify.

The operational cadence

Run this tracker on the 1st of every month. Domains expiring within 60 days go on the next sprint. Domains expiring within 30 days go on the current sprint. Domains already expired are incidents — the Apple Pay button has been off for however long, and the remediation is same-day.

For 8+ brand portfolios, we recommend batch-rotating all domains twice a year on a single calendar day — makes the verification files easier to manage and gives you a reliable one-day ops task instead of monthly drips.

The portfolio view

When you operate 12 brands on 3 processors, the tracker becomes more valuable than the Apple Developer portal. Each processor dashboard only shows its own brands. There is no single Apple-side view of "every domain I have registered across every processor." This tracker is that view.

What multiflow provides instead

For operators on the multiflow parent-merchant-account model, Apple Pay domain verification is handled at the parent level. A single merchant ID covers every sub-brand domain. Verification files are issued once by the parent processor and deployed across every brand's .well-known path via our deploy pipeline. One annual rotation, not 12.

FAQ

Does Apple send a reminder before expiry?

No. Apple does not notify merchants about upcoming expiry. Processors sometimes notify (Stripe sends an email ~30 days before, Braintree sometimes, Adyen rarely). The only reliable approach is a self-maintained tracker like this one.

What happens at expiry?

The Apple Pay button stops rendering on Safari-on-Apple-device sessions. No error is shown to the customer — the button simply does not appear. From the customer's perspective, Apple Pay is not offered. Most operators don't notice until a conversion audit.

Can I register one domain on multiple processors?

Yes. A domain can be simultaneously verified with multiple processors, each issuing its own .well-known file path (they use different filenames under .well-known/). Useful for A/B routing between Stripe and Braintree.

Does Shopify Payments handle this automatically?

Yes — Shopify manages Apple Pay domain registration as part of Shopify Payments setup. But if you run custom checkout (Shopify Plus with a third-party gateway, or non-Shopify), you're on your own.

What about Google Pay?

Google Pay does not require domain verification the same way. No rotation, no .well-known. The only Google Pay domain-level requirement is the merchant verification in the Google Pay Business Console, which is a one-time setup.