2026年、BigCommerceのSafari決済でカートが消えたら？

今週の確認方針

今週は、まず店面とチェックアウトのドメイン関係を確認し、次にカートと顧客セッションがどの引き継ぎ地点で失われるかを記録してください。そのうえで、同じ購入手順を実機のmacOS Safariと別の対応ブラウザーで比較します。遠隔MacはSafariでの再現確認には使えますが、店面の設定を直したり、取引の成功を保証したりするものではありません。

BigCommerceのSafari決済でカートが消える問題は、埋め込み型、ヘッドレス型など、利用中の構成ごとに確認すべき条件が異なります。店面と決済ページのホスト名を確かめずに、すべての構成を同じ原因として扱わないでください。

• BigCommerceの独自店面から決済へ進むと商品が消える原因を切り分けたい運営者向けです。
• 購入経路を再現し、カートの消失とログイン状態の異常を区別したい運用担当者にも役立ちます。
• ドメイン、セッション、ブラウザーの記録をもとに調査したい技術協力者にも向いています。

ドメインの連続性

最初に把握するのは、顧客がどのホスト名からどのホスト名へ移動するかです。店面が通常のホスト型かヘッドレス型か、チェックアウトが埋め込みか遷移型かを確認し、構成に対応するBigCommerceの要件と照らし合わせます。

ホスト名は、ブラウザーのアドレスバーで店面とチェックアウトの両方を確認します。似た名前のドメインでも、実際のホスト名が違う場合があります。メモや画面記録ではURL全体を残し、顧客情報や認証情報は隠してください。

BigCommerceの資料は、特定のチェックアウト方式に対して、それぞれのドメイン条件を説明しています。たとえば、Catalystのチェックアウトドメイン資料は、ドメインをまたぐ構成でSafariなどのブラウザーにおいて顧客セッションやカートが継続しない可能性を扱っています。これは、すべての店面に同一の条件が適用されるという意味ではありません。

注意：ドメイン名が異なるという一点だけで原因を断定しないでください。まず利用方式を特定し、その方式に対応する公式要件を確認します。

カート状態の引き継ぎ

カートが「どこで」空になるかを記録すると、店面側のカート作成、決済への引き継ぎ、遷移先の取り違えを区別しやすくなります。BigCommerceのカート作成APIの説明では、カートを作成するためのAPIとデータの扱いが示されています。フロントエンドで商品追加の操作が完了したように見えても、決済に渡すカートが同じとは限りません。

記録は、同じ商品、同じ購入経路で揃えます。店面でカート画面を開かずに決済へ進んだ場合と、カート画面を確認してから進んだ場合を混ぜると、消失地点が特定しにくくなります。無頭構成では、BigCommerceのヘッドレス決済ガイドも参照し、フロントエンドから決済へ渡す情報を確認してください。

顧客セッションの継続

訪問者とログイン済み顧客を分けて試すと、カートの問題とアカウント状態の問題を混同しにくくなります。同じ購入手順で、ログイン前後、アカウント画面から戻った後、決済に進んだ後の状態をそれぞれ記録してください。

Catalystを使うヘッドレス構成では、公式のセッション同期資料を確認し、セッションをどのように引き継ぐ設計か照合します。ログイン後に画面上の名前が表示されても、決済側で同じ顧客セッションが維持されているとは限りません。

• 訪問者として商品を追加してから決済へ進み、商品が残るか確認します。
• ログインして同じ商品と経路を試し、カートと顧客情報の状態を分けて記録します。
• ログアウトやアカウント画面への移動を挟み、どの時点で状態が変わるか確認します。

条件分岐で次の調査を選ぶ

• 店面のカート画面ですでに空の場合：まずフロントエンドのカート作成処理と商品追加後の画面状態を調べます。決済ページのドメインを先に変更しても、店面側で作られていないカートは引き継げません。
• 店面では商品が見え、決済へ移った直後に空になる場合：利用中の方式に対応するドメイン要件、遷移先URL、カートの引き継ぎを確認します。
• 訪問者では再現せず、ログイン後だけ発生する場合：ログインやアカウント遷移の時点を特定し、ヘッドレス構成ならセッション同期の設計を照合します。
• 別の対応ブラウザーでは起きず、Safariだけで再現する場合：実機のmacOS Safariで同じ条件を試し、ドメインと状態の記録を揃えます。Safariの保護機能を無効にして解決したことにしないでください。

Safariでのブラウザー比較

比較では、商品、店面URL、購入経路、ログイン状態を揃えます。Safariだけ条件を変えて試すと、ブラウザーの違いが原因なのか、経路の違いなのか判断できません。

WebKitは、トラッキング防止の仕組みを公開しています。これはブラウザーのプライバシー保護の背景を理解する資料であり、個別のBigCommerce店面でカートが消える原因を単独で証明するものではありません。Safariのプライバシー保護を弱めたり回避したりするのではなく、公式のドメイン要件と実際の状態遷移を照合してください。

記録時の注意：画面を保存する場合は、メールアドレス、氏名、住所、注文情報、セッションに関する値をマスキングします。購入が完了したように見える画面だけでなく、注文状態も別に確認してください。

端から端までの結果確認

画面が次のページへ移動したことは、カートが正しく引き継がれたことや、決済・注文が成功したことの証明にはなりません。次の項目を別々に確認し、テスト注文の結果はBigCommerceまたは決済サービスが案内するテスト方法に従って確認します。

1. 店面のカートに商品が残っているか。
2. チェックアウト画面が正しいURLで表示され、商品が一致しているか。
3. 顧客情報が意図した状態で引き継がれているか。
4. テスト注文の処理結果と注文状態が記録と一致しているか。

カートの表示、決済ページの読み込み、顧客情報、注文結果を一つの「成功」にまとめないことが重要です。修正前後の画面、アクセスしたホスト名、テストしたログイン状態を残せば、運営担当者と技術担当者の間で認識を合わせやすくなります。

遠隔Macで再確認する条件

手元に利用できるMacがあり、実機のSafariで同じ経路を再現できるなら、まずそれを使います。Macがなく、Safari固有の再現確認が必要な場合は、遠隔Macを候補にできます。ただし、遠隔環境が提供するmacOS、接続方法、利用期間、テストに必要な操作が合うかを先に確認してください。

VpsKeepの利用を検討する場合は、遠隔Macの利用ガイドで接続方法や利用前に確認したい条件を把握し、必要なテスト内容と照らし合わせてください。遠隔Macを使う利点は、手元にない実機環境でSafariの挙動を確認できることです。一方で、店面のドメイン設定やセッション同期を修正する代わりにはならず、決済結果も保証しません。安定した長期運用や物理機器への直接接続が必要なら、専用のMacを用意する選択肢も比較してください。

よくある質問

店面から決済へ進むとカートが空になります。最初に見る場所はどこですか？
店面とチェックアウトのホスト名、利用中の決済方式を記録し、商品追加後、カート画面、決済開始後の順で商品状態を比べます。最初に商品が消える地点を探すと、店面側のカート作成と決済への引き継ぎを分けて調べられます。

ヘッドレス店面と決済のドメインが違うと、必ず問題になりますか？
ドメインが異なるだけで問題と決めつけることはできません。構成ごとに公式のチェックアウトドメイン要件を確認し、実際のURLと照合します。Catalystなどではドメイン間の移動がセッションやカートに影響する場合があるため、対象構成の資料に沿って確認してください。

SafariでEmbedded Checkoutを調べるときは何を記録すればよいですか？
埋め込み元のURL、チェックアウトのホスト名、遷移前後のカート状態を記録し、Embedded Checkoutの公式要件と照合します。ヘッドレス型のドメイン条件をそのまま当てはめず、Safariのプライバシー機能を無効化する方法も修正策として扱わないでください。

ログイン後に決済へ進むとログアウトしたように見える場合はどうしますか？
訪問者とログイン済み顧客を別々に試し、ログイン、アカウント画面への移動、決済開始のどこで状態が変わるかを残します。無頭構成ならセッション同期の設計も確認してください。一度成功しただけで、すべての顧客で再現しないと判断するのは避けます。

現行環境だけでSafariの再現確認ができない場合は、先に記録した購入経路と必要な接続条件をもとに、遠隔Macがテスト目的に合うか確認してください。VpsKeepの利用条件は案内ページで確認できます。必要なのが店面設定の修正や決済サービスの調査であれば、遠隔環境の手配より先に、その担当範囲と再現記録を整えるのが適切です。

よくある質問