海外ECのApple Payが落ちる理由｜ ドメイン検証のよくある誤解

実務ガイド

誤解1：決済代行をONにすれば十分

決済代行（PSP）の管理画面でApple Payを有効にしても、販売サイトのドメイン検証が終わっていなければボタンは出ません。AdyenやRazorpayなどのヘルプでも、ドメイン検証ファイルの配置が前提条件として書かれています。PSP側のトグルと、自社ドメイン側のファイル配置は別作業です。

切り分けの最初の質問は「どのドメインで買うか」です。本番が www で検証が非www、またはチェックアウトが checkout. サブドメインだけ、というズレがよく起きます。買うURLと検証したホスト名が一致しているかを1行でメモします。

メモが無い週は、障害報告のチャットに「PSP設定済み」とだけ書かない運用にします。書くなら「購入URL／検証済みホスト／ファイルURL」の3点です。

3点が揃うまで、クリエイティブや広告のABテストに原因を寄せない方が早いです。表示可否はフロントのデザイン問題より、ドメイン検証の失敗であることが多いです。

障害の優先度は「売上に効く購入導線か」で決めます。Apple Pay比率が高い市場向けキャンペーンなら、検証失敗は広告停止級です。比率が低い市場でも、サポート問い合わせが増える前に直します。

誤解2：ファイルをどこかに置けばよい

パスは任意ではありません。正は https://[ドメイン]/.well-known/apple-developer-merchantid-domain-association です。ファイル名の改変、ディレクトリの追加階層、拡張子の付与は失敗しやすいです。PSPから配布された内容を改変せずに置く、が基本です。

Content-Typeは text/plain、HTTPSで配信、認証の後ろに置かない、がよくある要件です。社内のCDNやWAFが .well-known を弾いていないかも確認します。弾いている場合、ブラウザでは見えるのにAppleの検証だけ落ちることがあります。

確認手順は単純です。ブラウザのシークレットでファイルURLを開き、中身がプレーンテキストで返るか見ます。ログイン画面やHTMLエラーが出たら、配置失敗です。

配置担当と決済担当が別チームの場合、ファイルURLをチケットの先頭に貼ります。貼らないと「設定したつもり」の往復が続きます。

ステージングと本番でホストが違う場合は、ステージング合格を本番合格とみなしません。本番ホストで同じ確認をやり直します。証明書やCDNの設定が環境で違うことが多いためです。

誤解3：リダイレクトがあっても通る

検証ファイルの応答はHTTP 200が必要で、301／302などのリダイレクトは通らない、と複数のPSPドキュメントが明記しています。HTTPからHTTPSへの強制リダイレクト、wwwへの寄せ、国別のジオリダイレクトが、検証だけを落とす典型パターンです。

越境サイトでは、言語パスや国別サブドメインのリダイレクトルールが強いことがあります。検証パスだけを例外にするか、購入に使うホストごとにファイルを置くかを先に決めます。例外ルールを後回しにすると、本番リリース後にだけ失敗します。

切り分けはcurlや開発者ツールでステータスコードを見ます。最終的に200でも、途中に3xxがあるなら検証は落ちやすい、と覚えておきます。

CDNの「常時リダイレクト」設定を触る権限が無い場合は、インフラ担当に「Apple検証パスはリダイレクト禁止」と1行で依頼します。依頼文にパス全文を含めます。

国別の自動振り分け（例：IPで別ドメインへ送る）は、検証ボットにも効くことがあります。検証期間中だけ例外を入れるか、購入ホストを固定するかを先に決めます。後から例外を足すと、他の導線のテストが壊れやすいです。

誤解4：メインドメインだけでサブドメインもカバー

サブドメインは別ホストです。Digital Riverなどの説明でも、追加ドメインごとに同じパスへファイルを置く必要がある、と書かれています。www と shop と pay を使うなら、使うホストの数だけ検証が必要です。

マーケットプレイスやヘッドレス構成では、購入完了ページのホストがブランドサイトと違うことがあります。広告の着地がブランドドメイン、決済が別ホスト、という設計では、両方の検証が必要になることがあります。

台帳の列は「ホスト名／検証日／担当／PSP側ステータス」の4つで足ります。ホスト列が空のまま「Apple Pay対応済み」と書かない運用にします。

ホストが増えるリリースのチェックリストに、検証ファイルの行を追加します。機能リリースと検証リリースを同じチケットにすると、抜けが減ります。

プレビュー用の一時URL（ハッシュ付きホストなど）で検証しても、顧客が使う正式ホストの代わりにはなりません。正式ホストの行が台帳に無い限り、リリース完了にしない運用が安全です。

誤解5：iframe内でもそのまま出せる

Apple Payはクロスオリジンのiframe制約があります。決済フォームをiframeで埋め込む場合、許可属性（例：paymentの許可）や埋め込み方式の見直しが必要、と決済事業者のドキュメントで注意が出ます。「ボタンは実装したのにiframeの中だけ出ない」は、ドメイン検証とは別の層です。

切り分け順は、①単独ページで出るか、②埋め込みで出るか、です。単独で出て埋め込みで出ないなら、iframe／許可属性側を見ます。単独でも出ないなら、まずドメイン検証に戻ります。

社内のデザインシステムが決済をコンポーネント化している場合、埋め込み前提のまま検証だけ直しても直りません。デザインと決済の担当を同じ障害チケットに入れます。

チケットの最初の返信は「単独URLのスクショ」にします。埋め込み画面だけだと、原因の層が特定できません。

誤解6：自社Merchant IDとPSP代行は同じ作業

PSPのホスト型チェックアウトでは、Merchant IDや証明書をPSPが持つ構成があります。一方、自前証明書や独自実装では、Apple Developer側のMerchant ID管理とドメイン検証の責任が自社に寄ります。どちらを使っているかで、ダッシュボードの画面も障害の連絡先も変わります。

契約書やオンボーディング資料に「証明書の所有者」を1行書いておきます。書いていないと、障害時にApple／PSP／自社インフラのどこへ聞くかが毎回揉めます。

国によって使えるカードやフローが違う説明もあるため、「日本向け設定を海外ドメインにコピー」は危険です。国・通貨・PSP契約の単位で、検証ホストを分けて管理します。

分け方の最小単位は、販売ドメイン×PSPアカウントです。アカウントが複数あるのに検証ファイルが1つ、という状態は事故の元です。

引き継ぎ資料には「証明書の更新月」も書きます。更新月が空だと、毎年同じ時期に表示障害が再発しても原因が遅れます。更新月はカレンダー共有で足ります。

海外キャンペーンで起きやすい連鎖

広告は国別LP、決済は共通チェックアウト、計測は別サブドメイン、という構成だと、検証漏れがキャンペーン開始後に発覚します。開始前日のチェックリストに「購入URLでApple Pay候補端末の表示確認」を入れます。管理画面の緑ランプだけでは不足です。

表示確認の記録は、端末OS・ブラウザ・購入URL・可否の4点です。可否だけだと再現できません。再現できない障害は、クリエイティブ側の議論に流れやすいです。

インバウンド向けに日本ドメインで売り、決済だけ海外PSP、という設計でも、購入ホストの検証は必要です。国籍とドメイン検証は別問題です。

キャンペーン用の一時ドメインを使う場合は、終了後の削除前に「検証済みホスト一覧」から外す運用を決めます。残ったホストが次回の誤設定の温床になります。

今週の一手：購入URLでファイルを開く

今週やることは1つです。実際の購入URLのホストで、検証ファイルのURLを開き、ステータス200・プレーンテキスト・リダイレクト無しを確認することです。確認結果を「ホスト／結果／日時」の1行で共有フォルダに残します。

失敗したら、PSPのトグルや広告の差し替えより先に、パス・リダイレクト・サブドメインの3点を直します。直す順番を逆にすると、原因が残ったままクリエイティブだけが動きます。

成功したら、同じホストで実機表示確認を1回だけ足します。ファイルOKでもiframeや端末条件で出ないことがあるためです。

記録の保管先は1フォルダ、更新担当は1名で足ります。パスが分かれると、次回キャンペーンでまた同じ誤解から始まります。

確認に15分しか取れない週は、ファイルURLの200確認だけでも残します。実機確認は翌営業日に回し、日付を台帳に書きます。