サードパーティ Cookie の変更が支払いワークフローに与える影響を確認する

Chrome は、サードパーティ Cookie に関するユーザーの選択のための新しいエクスペリエンスを提案しています。サードパーティ Cookie なしでブラウジングすることを選択したユーザーに対応できるように、サイトを準備する必要があります。

このページでは、今後の変更の影響を受ける可能性があるものについて説明します。

一般的なユーザー ジャーニー

多くの支払いワークフローとショッピング ワークフローは、サードパーティ Cookie に依存しています。次の表に、サードパーティ Cookie が無効になっている場合に影響を受ける可能性があるユーザー ジャーニーを示します。また、デベロッパーが機能の損失を回避するために使用できる代替 API も示します。このリストはすべてを網羅しているわけではなく、プライバシー サンドボックス ソリューションが利用可能になると更新される場合があります。影響を受けるその他のシナリオが見つかった場合は、フィードバックを送信してください。

ユーザーフローがサードパーティ Cookie の制限の影響を受けているかどうかをテストする最善の方法は、サードパーティ Cookie テストフラグを有効にしてユーザーフローをテストすることです。

ウェブサイトが想定どおりに動作することを確認するには、サードパーティ Cookie を制限して次のフローをテストします。

  • クロスサイト チェックアウト: サードパーティの決済プロバイダ( <example-provider> で支払うなど)に依存する支払いフローをテストします。次のことを確認します。
    • リダイレクトが正常に実行されます。
    • 決済ゲートウェイが正しく読み込まれている。
    • お支払い手続きをエラーなく完了できる。
    • ユーザーは、想定どおりにウェブサイトにリダイレクトされます。
  • お支払いダッシュボード: サードパーティ Cookie が制限されている状態で、取引ダッシュボード ウィジェットが想定どおりに動作することをテストします。お客様が次の操作を行えることを確認します。
    • ダッシュボードにアクセスします。
    • すべての支払いが期待どおりに表示されます。
    • ダッシュボードのさまざまなセクション(取引履歴、お支払いの詳細など)をエラーなく移動します。
  • お支払い方法を管理: お支払い方法の管理ウィジェットが想定どおりに動作することをテストします。サードパーティ Cookie をブロックした状態で、以下をテストします。
    • お支払い方法の追加または削除は想定どおりに機能します。
    • 以前に保存したお支払い方法での支払いには影響しません。
  • 不正行為の検出: サードパーティ Cookie ありとサードパーティ Cookie なしで、不正行為検出ソリューションの動作を比較します。
    • サードパーティ Cookie をブロックすると、追加の手順が必要になり、ユーザーの負担が増加しますか?
    • ブラウザでサードパーティ Cookie がブロックされている場合でも、疑わしいパターンを検出できますか?
  • パーソナライズされた購入手続きボタン: サードパーティ Cookie が制限されている場合に、支払いボタンが正しくレンダリングされるかどうかをテストします。
    • パーソナライズされたボタンに希望の方法が表示されない場合でも、ユーザーは購入を完了できますか?

クロスサイト チェックアウト

一部のお支払いプロバイダは、サードパーティ Cookie を使用して、ユーザーが複数の販売者サイトでアカウントにアクセスする際に再認証を行う必要がないようにしています。サードパーティ Cookie を使用しないブラウジングを選択したユーザーには、このユーザー ジャーニーが影響する可能性があります。

埋め込み購入手続きフォーム

次のドメインについて考えてみましょう。

  • payment-provider.example は販売者のサイトに支払いサービスを提供します。また、ユーザーのお支払いとセッションのデータを保存します。
  • merchant.example は、payment-provider.example が提供する購入手続きフォームを埋め込んだウェブサイトです。

ユーザーが payment-provider.example にログインしたばかりです(別のサイトで購入手続きを完了している場合など)。ユーザーが merchant.example で購入手続きを開始します。

サードパーティ Cookie が使用可能な場合、merchant.example に埋め込まれた payment-provider.example 購入フォームは、トップレベル コンテキストの payment-provider.example に設定された独自のトップレベル セッション Cookie にアクセスできます。ただし、サードパーティ Cookie がブロックされている場合、埋め込みは独自のトップレベル Cookie にアクセスできません。

この図は、サードパーティ プロバイダ(payment-provider.example)の支払いウィジェットを使用する販売者のウェブサイト(merchant.example)とのやり取りを示しています。サードパーティ Cookie がブロックされている場合、ウィジェットはトップレベル Cookie にアクセスできず、ユーザー エクスペリエンスが中断する可能性があります。
サードパーティ Cookie が無効になっている場合、payment-provider.example ウィジェットは、payment-provider.example の最上位コンテキストで設定されたユーザー セッション Cookie にアクセスできません。

FedCM を使用したカスタマイズ可能なソリューション

payment-provider.example は、ID プロバイダとして機能する FedCM の実装を検討する必要があります。この方法は、次のような場合に適しています。

  • payment-provider.example が関連性のないサードパーティのサイトに埋め込まれている。
  • payment-provider.example が 5 つを超える関連サイトに埋め込まれている。

FedCM の主なメリットは、UI でユーザーに選択の状況に関するより多くのコンテキストを提供できることです。ユーザーの許可があれば、FedCM は、リレーリング パーティ(merchant.example)と ID プロバイダ(payment-provider.example)間でカスタムデータを共有できます。リレーリング パーティは 1 つ以上の ID プロバイダをサポートできます。FedCM UI は条件付きでのみ表示されます。

デベロッパーは、必要に応じて、ユーザーが ID プロバイダでログインしたときに FedCM プロンプトを自動的に表示するパッシブ モードと、ユーザーによるアクション(決済ボタンのクリックなど)の後にログイン プロセスをトリガーするアクティブ モードを選択できます。

FedCM は Storage Access API(SAA)の信頼シグナルとしても機能します。これにより、ユーザーが埋め込みプロバイダでログインすることに同意した後、埋め込みがトップレベルのパーティショニングされていない Cookie にアクセスできるようになります。追加のユーザー プロンプトは必要ありません。

ストレージ アクセスに重点を置いたソリューション

検討すべきもう 1 つの API は Storage Access API(SAA)です。SAA では、payment-provider.example の埋め込みを許可して独自のトップレベル Cookie にアクセスするよう求めるメッセージが表示されます。ユーザーがアクセスを承認すると、サードパーティ Cookie が使用可能な場合と同様にフォームをレンダリングできます。

FedCM と同様に、payment-provider.example が埋め込まれている新しいサイトごとに、ユーザーがリクエストを承認する必要があります。API の仕組みについては、SAA デモをご覧ください。デフォルトの SAA プロンプトがニーズに合わない場合は、FedCM を実装してカスタマイズされたエクスペリエンスを提供することを検討してください。

関連する少数のサイトでユーザーの負担を軽減する

販売者のサイトと支払いプロバイダの両方が同じ会社に属している場合は、関連ウェブサイト セット(RWS)API を使用してドメイン間の関係を宣言できます。これにより、ユーザーの操作を減らすことができます。たとえば、insurance.examplepayment-portal-insurance.example が同じ RWS にある場合、payment-portal-insurance.example 埋め込み内でストレージ アクセスがリクエストされると、payment-portal-insurance.example は自動的に独自のトップレベル Cookie にアクセスします。

その他の試験運用版ソリューション

このシナリオで役立つ可能性がある別の試験運用版 API は、パーティショニングされたポップインです。この API は現在開発中です。

パーティショニングされたポップインを使用すると、merchant.example によって開かれたポップイン内で、payment-provider.example にログインするための認証情報を入力するようユーザーに求めるメッセージを表示できます。ストレージは、オープン merchant.example によってパーティショニングされます。この場合、payment-provider.example 埋め込みはポップイン内に設定されたストレージ値にアクセスできます。このソリューションでは、ユーザーはサイトごとに決済プロバイダにログインする必要があります。

一部の決済プロバイダは、販売者のサイトにカスタムの購入手続きページをレンダリングする支払いリンクを生成するサービスを提供しています。決済リンク サービスと決済プロバイダのユーザー ポータルは、多くの場合、異なるドメイン(payment-provider.examplepayment-link.example など)に実装されます。

payment-link.example は、payment-provider.example が提供する購入手続きフォームを埋め込みます。これは、埋め込み購入手続きフォーム パターンのバリエーションです。このケースでは、FedCMSAARWS も検討に値するオプションです。

お支払いダッシュボード

一部のアプリケーションでは、複数のサイトにわたる取引ダッシュボードをユーザーに表示し、金融取引を一元的に表示しています。これには、ダッシュボードが複数のドメインにわたるユーザー固有のデータにアクセスする必要があります。

次のドメインについて考えてみましょう。

  • earnings.example は、さまざまなウェブ アプリケーションに埋め込むことができる支払いダッシュボードを提供します。このサービスは、ユーザーの収益データとセッション情報を保存します。
  • catsitting.exampledogsitting.example は、どちらも earnings.example ダッシュボードを埋め込んでいる別のウェブサイトです。

ユーザーが earnings.example アカウントにログインします。catsitting.example または dogsitting.example にアクセスすると、収益を確認できます。埋め込まれた earnings.example ダッシュボードは最上位の Cookie を使用し、ユーザーの収益情報をパーソナライズして表示します。

他の例と同様に、サードパーティ Cookie が無効になっている場合、埋め込まれた earnings.example はトップレベルの Cookie にアクセスできません。

earnings.example でホストされているユーザーの収益情報が、dogsitting.example に埋め込まれたダッシュボードに表示されるシナリオを示す図。サードパーティ Cookie がブロックされている場合、埋め込みダッシュボードはトップレベル Cookie にアクセスできないため、ユーザーのパーソナライズされた収益データは表示されません。
サードパーティ Cookie が無効になっている場合、dogsitting.example に埋め込まれた earnings.example ウィジェットは、earnings.example のトップレベル コンテキストで設定された Cookie にアクセスできません。

ファーストパーティ ダッシュボード

3 つのドメインがすべて同じ当事者に属している場合は、RWS とともに SAA の使用を検討してください。SAA を使用すると、earnings.example はユーザーの許可を得てトップレベルの Cookie にアクセスできます。このパーティが 4 つ以下のドメインで earnings.example を使用している場合は、RWS を使用してドメイン間の関係を宣言すると、よりスムーズなユーザー エクスペリエンスを提供できます。

同じ事業者が 5 つを超えるドメインにウィジェットを埋め込む場合、RWS は 1 つのプライマリ サイトと 5 つの関連サイトのセット内の最大 6 つのサイトのみをサポートしているため、埋め込みサイトとウィジェットのドメインの関係を宣言することはできません。

スケーリングされたダッシュボードの配信

次のケースでは、SAARWS が最適なソリューションではない場合があります。

  • サードパーティのサイト向けのダッシュボード ソリューションを配布する。
  • ダッシュボード ウィジェットを埋め込んでいるサイトが 5 つを超えている。

この場合、earnings.example は、ID プロバイダとして機能する FedCM の実装を検討する必要があります。つまり、ユーザーは earnings.example によって管理されているアカウントで dogsitting.example にログインする必要があります。

FedCM には、どの情報が共有されているかをユーザーに明確に伝えることができるカスタマイズ可能な UI が用意されています。FedCM では、dogsitting.example は、トランザクション データへのアクセスなど、カスタム権限を共有するよう earnings.example にリクエストできます。

FedCM は Storage Access API の信頼シグナルとしても機能し、earnings.example 埋め込みには、SAA API 呼び出しで追加のユーザー プロンプトが表示されることなく、独自のトップレベル Cookie へのストレージ アクセスが許可されます。

サイト固有のダッシュボードの設定

データを複数のサイト間で共有する必要がない場合は、CHIPS を使用して Cookie をパーティショニングすることを検討してください。CHIPS は、ダッシュボードのレイアウトやフィルタなど、サイト固有の設定を保存する場合に便利です。

お支払い方法の管理

別の一般的なフローとして、ユーザーがホストサイトを離れることなく、埋め込み内でお支払い方法を表示、編集する方法があります。

次のフローについて考えてみましょう。

  • payments.example は、ウェブサイトに埋め込むことができる支払い管理ツールを提供します。このサービスは、ユーザーのお支払いデータとセッション情報を保存します。
  • shop.example は、payments.example ツールが埋め込まれたウェブサイトで、ユーザーは shop.example アカウントに関連付けられている優先のお支払い方法の表示、編集、選択を行うことができます。

お支払い方法の管理を実装する決済機関は、FedCM の ID プロバイダになることも検討する必要があります。FedCM を使用すると、ユーザーは ID プロバイダ(payments.example)によって管理されているアカウントを使用して、リレーリング パーティ(shop.example)にログインできます。

ユーザーの許可があれば、FedCM はリレーリング パーティと ID プロバイダ間でカスタムデータを共有できます。FedCM を使用する主なメリットは、UI でユーザーに選択の状況をより詳しく説明できることです。また、Storage Access API の信頼シグナルとしても機能し、埋め込みがトップレベルの Cookie にアクセスできるようにします。

サードパーティ Cookie が無効になっている場合、payments.example 埋め込みはトップレベルの Cookie にアクセスできません。この場合、SAA はストレージ アクセスをリクエストすることで、適切な動作を確保できます。

埋め込み内で設定された情報を、他の埋め込みサイトと共有する必要がない場合があります。payments.example では、特定の埋め込みサイトごとに異なるユーザー設定のみを保存する必要があります。この場合は、CHIPS を使用して Cookie をパーティショニングすることを検討してください。CHIPS では、shop.example に埋め込まれた payments.example 内に設定された Cookie に、another-shop.example に埋め込まれた payments.example からアクセスすることはできません。

このユーザーフローで使用できるもう 1 つの試験運用版 API は、パーティショニングされたポップインです。ユーザーが shop.example によって開かれたポップイン内で payments.example にログインすると、ストレージは開いたユーザーによってパーティショニングされ、payments.example 埋め込みはポップイン内に設定されたストレージ値にアクセスできるようになります。ただし、この方法では、ユーザーはすべてのサイトで支払いプロバイダにログインするための認証情報を入力する必要があります。

不正行為の検出

リスク分析システムは、Cookie に保存されているデータを分析して、標準から逸脱したパターンを特定できます。たとえば、ユーザーが突然配送先住所を変更し、新しいデバイスを使用して複数の大口購入を行った場合、不正行為の可能性スコアが高くなる可能性があります。不正行為検出 Cookie は通常、決済プロバイダまたは不正防止サービス ウィジェットによって販売者のサイトで設定されるサードパーティ Cookie です。

サードパーティ Cookie の制限によって不正行為検出システムが破壊されることはありませんが、ユーザーの利便性が損なわれる可能性があります。ブロックされた Cookie により、システムがユーザーが正当であることを確実に確認できない場合は、本人確認の完了など、追加の確認が必要になることがあります。

サードパーティ Cookie がブロックされている場合に不正行為の検出をサポートするには、プライベート ステート トークン(PST)API を不正行為検出ソリューションに統合することを検討してください。PST を使用すると、決済プロバイダはトークン発行者として登録し、サードパーティ Cookie に依存しないトークンをユーザーに付与できます。これらのトークンは、販売者のサイトで利用して、ユーザーの信頼性を確認できます。実装の詳細については、PST デベロッパー向けドキュメントをご覧ください。

プライバシー サンドボックスでは、他の不正行為防止 API もテストされています。

パーソナライズされた購入手続きボタン

販売者のサイトに埋め込まれた支払いボタン(<優先するお支払い方法> で支払うなど)は、多くの場合、支払いプロバイダによって設定されたクロスサイト情報を使用します。これにより、パーソナライズが可能になり、ユーザーは希望するお支払い方法でスムーズに購入手続きを行えます。ユーザーのブラウザでサードパーティ Cookie がブロックされている場合、カスタマイズされた支払いボタンのレンダリングに影響する可能性があります。

SAA ではストレージへのアクセスを許可できますが、必要なプロンプトによってユーザー エクスペリエンスが損なわれる可能性があります。

Google では、このユースケースを具体的にターゲットとするソリューション(ローカルのパーティショニングされていないデータアクセスを使用したフェンスド フレーム)を検討しています。この API は現在開発中であり、今後の開発にご協力いただけます。ぜひお試しくださいフィードバックをお寄せください。

ヘルプ

不具合が発生した場合は、goo.gle/report-3pc-broken に報告してください。フィードバック フォームを送信するか、GitHub の プライバシー サンドボックス デベロッパー サポート リポジトリで問題を報告することもできます。