SafariでPayPalのボタンは表示されるのに、購入完了後の注文が管理画面に残らない。
今週は、ボタン表示だけで合格にせず、Sandboxで「表示・ログイン・承認・キャンセル・サーバー側の捕捉」を分けて確認し、最後に隔離した実Safari環境で再試験してください。
誰がこの受け入れ手順を使うべきか
この手順は、PayPal JavaScript SDK v6 移行 2026の結果を受け入れるか判断する、越境ECの責任者向けです。Safariで回帰試験を担当する運用・テスト担当者にも使えます。
PayPal連携、サーバー側の注文処理、エラー対応を修正する社内または外部の技術担当者は、各シナリオの証跡と判定条件をそのまま引き継げます。
最終更新は2026年8月30日です。PayPal Developerのv6設定・移行・ブラウザー対応・Sandbox資料と、AppleのSafari設定・開発者ツール資料を確認して整理しています。PayPalの旧バージョンに一律の移行期限が発表された、とは扱っていません。
PayPal JavaScript SDK v5からv6へ移行する必要があるかを先に判定する
PayPal公式には、v5からv6への移行資料と新しい設定手順があります。ただし、公式の移行資料があることと、v5がすべて直ちに停止されることは別です。実際のサイトがどのSDKを読み込んでいるかを確認してから、移行完了を判定します。
PayPal公式のv5からv6移行資料と、公式のSDK設定手順を照合し、次の情報を台帳に記録します。
- 商品詳細ページ、カート、チェックアウトページ、購入導線内の別決済入口
- 現在動作している旧実装の画面結果と注文結果
- 読み込んでいるSDKのURL、初期化方法、クライアントIDの扱い
- 注文作成、買い手承認、サーバー側捕捉の担当者
- v6で不具合が出た場合に戻す旧実装と、戻す判断者
ページにPayPal Checkoutのボタンがあるだけでは、v6を使っている証拠になりません。タグ管理ツール、共通レイアウト、キャッシュされたJavaScriptに旧読み込みが残っていると、ページごとに別の実装が動くためです。
| 確認対象 | 合格に近い状態 | 保留にする状態 |
|---|---|---|
| SDK読み込み | 対象ページで想定したv6のURLと初期化を確認できる | ページによってURLや初期化処理が異なる |
| 支払い入口 | 商品ページからチェックアウトまで同じ注文導線を追える | 一部の入口だけ旧処理が残っている |
| 回退計画 | 旧実装へ戻す手順と担当者が決まっている | 障害時にタグやサーバー処理を戻せない |
| 判定材料 | 画面、通信、注文ID、捕捉結果がそろっている | ボタンの見た目だけで判断している |
今週の判定メモ
- [ ] 対象ページを一覧化し、旧実装の正常な基準を残す
- [ ] 実際のSDK URLと初期化処理をSafari Web Inspectorで確認する
- [ ] 旧実装への回退条件と責任者を記録する
- [ ] Sandbox用の買い手アカウントと注文確認担当を用意する
ボタンがSafariで表示されないときは、初期化と読み込み順を分けて見る
Safariでv6のボタンが出ない場合、いきなりプライバシー設定だけを変更しないでください。まず、SDKの読み込み、初期化のタイミング、コンソールエラー、ネットワーク応答、コンテンツセキュリティポリシーを順に確認します。
PayPalの公式ブラウザー対応情報を基準にし、Safariだけの現象か、他のブラウザーでも再現するかを分けます。地域や買い手情報によって表示される支払い方法が変わる場合があるため、表示されなかった決済方法を全利用者共通の不具合とは記録しません。
- Safariで対象ページを開き、開発メニューからWeb Inspectorを起動します。
- Consoleで赤色のエラーを保存します。SDKの読み込み失敗、初期化前の呼び出し、CSP違反を分けて記録します。
- NetworkでPayPal関連のスクリプトとAPI通信を確認します。ステータス、失敗したURL、発生時刻を残します。
- 初回訪問、ページ更新、カートから戻る操作、チェックアウトへの再入場を同じ買い手条件で再現します。
- ボタンのコンテナが存在するか、初期化処理が複数回走っていないかを確認します。
- クライアントID、Sandbox設定、許可済みドメイン、CSPを技術担当者と照合します。
Safariの開発者機能を有効にするApple公式手順も参照してください。証跡には、画面全体の脱落だけでなく、コンソールと通信ログを含めます。
注意：他のブラウザーで表示されたことは、Safariの受け入れ合格を意味しません。Safari固有の失敗を残したまま、別ブラウザーの成功結果で置き換えないでください。
ログイン、承認、キャンセルを買い手の操作として再現する
ログイン画面が開かない場合と、閉じた場合を分ける
PayPalログインのポップアップが開くケース、Safariにブロックされるケース、買い手が閉じるケース、ログイン途中で中断するケースを別々に記録します。ページ上の表示は「決済失敗」の一文だけにせず、再試行、別の支払い方法、カートへの復帰など次の操作を示せる状態にします。
Safariのポップアップ設定は、Apple公式のポップアップブロック案内に沿って確認します。ただし、支払いのためにプライバシー保護を恒久的に弱める運用は避けます。
同じSandbox買い手アカウントで、次の変数を1つずつ変更します。
- サイトデータを削除した直後か、既存セッションがあるか
- Safariのサイト越しトラッキング設定
- ブラウザー拡張機能の有効・無効
- ポップアップを許可した場合と、初期設定のままの場合
- 支払い承認後に元のタブへ戻れるか
Safariのプライバシー設定に関するApple公式資料を参照し、設定を変えた場合は変更内容を証跡に残します。設定変更だけで成功するなら「合格」ではなく、実装とブラウザー挙動の技術確認が必要な状態です。
承認とキャンセル後の画面を確認する
Sandbox買い手として支払いを承認した後、元のチェックアウトへ戻った画面を確認します。次に、ログイン画面を閉じる、支払いをキャンセルする、カートへ戻る操作も行います。
確認するのは見た目だけではありません。カートの商品・数量・割引状態、二重送信防止、再試行ボタン、別決済への切り替え、注文番号の表示を記録します。
| シナリオ | 画面側の確認 | サーバー・注文側の確認 |
|---|---|---|
| 支払い承認 | 成功表示、注文番号、再送信防止 | 注文作成・承認・捕捉の状態が対応する |
| 買い手キャンセル | カートへ戻り、再試行できる | 未捕捉の注文を履行対象にしない |
| ポップアップ終了 | 理由が分かる案内を表示する | エラーや未完了状態を記録する |
| 支払い拒否 | 別手段または再試行を案内する | 拒否結果と注文状態を照合する |
| 通信・サーバー異常 | 決済済みと誤表示しない | エラーIDと注文IDを担当者へ渡す |
Sandboxで成功したのに注文がない場合は、捕捉処理を確認する
Sandboxで買い手画面が成功しても、独立サイトの注文が作成されないことがあります。注文作成、買い手承認、サーバー側の捕捉は別の状態として追跡し、PayPalの取引記録とサイト側の注文番号を関連付けます。
PayPal公式の高度なSDK連携資料を技術担当者と確認し、クライアント側の成功コールバックだけで履行へ進まない設計にします。ブラウザーの遷移完了は、サーバーが捕捉を確認した証拠ではありません。
- Sandboxで注文を作成し、注文IDを控えます。
- 買い手承認後、承認結果と戻り先の画面を記録します。
- サーバーが捕捉APIを呼び出したか、応答状態とエラー内容を確認します。
- PayPalのSandbox活動記録と独立サイトの注文番号を照合します。
- 支払い拒否、サーバー異常、キャンセル、同じ操作の再送信を個別に試します。
- 未捕捉、重複、状態不明の注文が履行へ進まないことを確認します。
エラーの分類は、PayPal公式のAPIエラー概要に合わせます。ログにはアクセストークンや個人情報を残さず、注文ID、エラーコード、時刻、画面結果など必要な情報だけを保存します。
PayPalの本番環境設定資料へ進む前に、Sandboxで例外分岐を終わらせます。Sandboxの成功だけを本番の決済成功率や審査結果へ置き換えることはできません。
受け入れ判定をチェックリストで固定する
- [ ] 対象ページすべてでv6のSDK読み込みと初期化を確認した
- [ ] Safariの初回訪問と再入場でボタンが安定して表示された
- [ ] 支払い方法の表示結果を、地域・買い手条件とともに記録した
- [ ] ログインポップアップの開始、ブロック、終了、中断を確認した
- [ ] 承認後に注文IDとサーバー側の捕捉結果を照合した
- [ ] キャンセル後にカート状態と再試行導線を確認した
- [ ] 支払い拒否、通信異常、重複操作を試した
- [ ] Safari以外の結果は比較資料として保存し、代替合格にしていない
- [ ] スクリーンショットを脱敏し、時刻、Safariのバージョン、結果を記録した
- [ ] 旧実装へ戻す手順、期限、担当者を確認した
米国買い手向けSafari試験に遠隔Macを使う範囲
米国買い手のチェックアウトを再現するには、Safariだけでなく、買い手の地域、サイトデータ、ログイン状態、商品、通貨、言語などを固定する必要があります。遠隔Macは、同じmacOS環境を繰り返し使うための試験端末としては有効ですが、決済ポリシーを回避したり、取引成功やアカウント審査を保証したりするものではありません。
実機を社内で確保できない場合は、MESHLAUNCHの遠隔Mac環境を候補に入れ、短い期間で次の受け入れ条件を確認します。
- Safariの設定とサイトデータを試験ごとに初期化できる
- VNCまたはWebコンソールで画面とWeb Inspectorの証跡を取れる
- SSHなどで技術担当者がログ確認を行える
- 同じ地域ノード、買い手条件、テストアカウントを再利用できる
- 作業終了後に個人情報や決済情報を端末へ残さない
米国向けの隔離環境が必要なら、米国東部のMac環境のように、利用するノードと接続方法を事前に確認します。地域設定だけで実際の買い手全体を代表できるわけではないため、本番判定では対象商品の主要な入口と通貨を組み合わせて再試験します。
最終判断は、主要な買い手導線が通ること、失敗時の回退または代替決済が動くこと、サーバー側の状態を証明できることの3点で行います。いずれかが欠けるなら、全面公開ではなく延期または限定公開にします。
現在の試験方法が担当者の個人Macや一時的な共有端末に依存していると、Safari設定の差、サイトデータの残留、証跡の欠落が起こりやすくなります。物理Macの購入は長期的な常設負荷には向きますが、短期間の移行検証では調達、保守、担当者間の共有が負担になります。再現可能なSafari環境をすぐ確保したい場合は、MESHLAUNCHの遠隔Macを短期利用し、同じチェックリストで検証してから継続利用か自社設備かを決める方法が現実的です。
まずSandboxの全シナリオを終え、次に隔離した米国向けSafari環境で証跡をそろえてください。必要な場合は、MESHLAUNCHの環境で今回の受け入れマトリクスを実行し、正式公開へ進めるかを判断できます。