3D セキュアを使用して認証する
決済フローに 3D セキュア (3DS) を導入します。
注意
主要なカードブランドは 3D セキュア 1 のサポートを終了しました。実装で 3D セキュア 1 を使用している場合は、Payment Intents と Setup Intents API を使用するように更新してください。これらの API を使用すると、次のようになります。
- 3D セキュア 2 (3DS2) をサポートします。
- 動的な 3D セキュアを利用します。
- ヨーロッパの強力な顧客認証 (SCA) 規制に準拠します。
Web、iOS、Android、React Native など、複数のプラットフォームで 3D セキュア (3DS) 認証を決済フローに導入できます。この導入より、顧客の銀行が対応している場合は 3D セキュア 2 (3DS2) が実行され、対応していない場合は 3D セキュア 1 にフォールバックされます。他の決済代行業者で Stripe の 3DS サービスを使用するには、サポートにお問い合わせください。
3DS フローを制御する
強力な顧客認証 (SCA) などの規制要件によって要求された場合、またはカード発行会社から再試行可能な支払い拒否コード authentication_
によってリクエストされた場合に、Stripe は 3DS を自動的に起動します。
Radar ルールまたは API を使用して、3DS 認証の実行をエンドユーザーに求めるタイミングを制御し、任意のパラメーターに基づいてユーザーごとに決定することもできます。ただし、ウォレットやオフセッションの支払いなどの一部の取引は 3DS に対応していません。
支払いで 3DS が起動されると、3DS 認証がカードで利用可能な場合、Stripe は認証を実行して支払いを完了することをユーザーに要求します。使用するフロントエンドによっては、3DS フローの表示を求められる場合があります。
3DS を起動する一般的な Payment Intent API フローは、次のようになります。
- PaymentIntent、SetupIntent を確定するか、Customer に PaymentMethod を関連付ける支払い情報を、ユーザーが入力します。
- 規制に関する同意書、Radar ルール、手動 API リクエスト、カード発行会社による再試行可能な支払い拒否などの基準に基づいて、取引が 3DS をサポートし、必須であるかどうかを、Stripe が評価します。
- 3DS の状況に応じて次のようになります。
- 必須でない場合: 免除などの理由により、Stripe が支払いを試行します。PaymentIntent のステータスは
processing
に移行します。カード発行会社から再試行可能な支払い拒否によってリクエストされた場合は、必要に応じて自動的に再試行して続行します。 - サポート対象外の場合: PaymentIntent のステータスが
requires_
に移行します。3DS が起動した理由によっては、支払いのオーソリステップを続行できる可能性があります。その場合、PaymentIntent のステータスはpayment_ method processing
に移行します。 - 必須の場合: Stripe が、カード発行会社の 3D セキュアアクセス制御サーバー (ACS) に接続して、3DS フローを開始することで、3DS 認証フローを開始します。
- 必須でない場合: 免除などの理由により、Stripe が支払いを試行します。PaymentIntent のステータスは
- Stripe が、カード発行会社から 3DS フローの情報を受け取ると、認証を試行します。PaymentIntent のステータスは
requires_
に移行します。action - 必要な 3DS アクションの表示方法については、以下をご覧ください。カード発行会社はさまざまな 3DS フローのアクションタイプをリクエストする可能性があるため、常に 3DS チャレンジが視覚的に表示されるとは限りません (負担のないフローなど)。
- カード発行会社が 3DS にまったく対応していないか、障害が発生している場合、Stripe は認証なしで支払いの完了を試みることがあります (許容される場合)。
- 通常、3DS 認証リクエストのデータは取引の時点で顧客によって提供されます。負担と認証失敗の可能性を軽減するため、Stripe は、決済フロー中に顧客から収集したデータ、顧客の過去の取引に関する記録、または顧客のカードまたはカード発行会社から入手できえる関連情報など、他のソースから推測されるデータを使用して、これらのリクエストを完了することがあります。
- Stripeがすでに必要なすべての 3DS データ要素にアクセスできる場合、最適化された Stripe の 3DS サーバーが PaymentIntent を確定する際に、認証リクエストの完了を試行することがあります。これにより、3DS フローが成功した場合は PaymentIntent のステータスが
processing
に直接移行し、3DS フローを完了するために追加のステップまたはデータ要素が必要な場合は、requires_
のステータスに直接移行します。action
- 3DS 認証の結果に応じて、次のようになります。
- 認証済み: Stripe は支払いを試み、PaymentIntent のステータスは
processing
に移行します。 - 失敗: PaymentIntent のステータスが
requires_
に移行し、別の支払い方法を試みる必要があることを示します。再確定して 3DS を再試行することもできます。payment_ method - その他のシナリオ: 支払いで 3DS が起動された理由によっては、エッジケースとして支払いに対するオーソリの続行が許容される可能性があります。たとえば、結果が
attempt_
になると支払いに進み、PaymentIntent のステータスがacknowledged processing
に移行します。- 例外は、継続支払いのためのインドの電子同意書を作成する場合です。
authenticated
以外の結果はすべて失敗として扱われます。
- 例外は、継続支払いのためのインドの電子同意書を作成する場合です。
- 認証済み: Stripe は支払いを試み、PaymentIntent のステータスは
- 支払いの結果に応じて、PaymentIntent のステータスは
succeeded
、requires_
、capture requires_
のいずれかに移行します。payment_ method
カード支払いに対して 3DS がサポートされ、試行されたかどうかを追跡するには、Charge の payment_
でカード情報の three_d_secure プロパティーを読み取ります。three_
プロパティーは、顧客がカードの認証を試行するときに Stripe によって設定されます。three_
は、認証の結果を示します。
ダッシュボードで Radar ルールを使用する
Stripe は、PaymentIntent (支払いインテント) または SetupIntent (支払い方法設定インテント) の作成時や確定時に 3DS を動的にリクエストするデフォルトの Radar ルールを提供しています。お客様は、これらのルールをダッシュボードで設定できます。
Radar for Teams を利用している場合は、カスタムの 3DS ルールを追加できます。
API を使用して 3DS を手動でリクエストする
3DS をトリガーするデフォルトの方法は、リスクレベルやその他の要件に基づいて Radar を使用して 3D セキュアを動的にリクエストすることです。手動による 3DS のトリガーは、Stripe を独自の不正利用防止エンジンに導入する上級ユーザー向けの方法です。
3DS を手動でトリガーするには、PaymentIntent または SetupIntent の作成または確認時、あるいは Checkout セッション の作成時に最適化する対象に応じて、payment_
を any
または challenge
に設定します。このプロセスは、1 回限りの支払いの場合も、今後の支払いのために支払い方法を設定する場合も同じです。このパラメーターを指定すると、Stripe は 3DS の実行を試み、PaymentIntent、SetupIntent、または Checkout セッションの 動的 3D Secure Radar ルール を上書きします。
このパラメーターを提供するタイミングは、お客様の不正利用防止エンジンがいつリスクを検知するかによって異なります。たとえば、不正利用防止エンジンがカードの詳細のみを調べる場合は、PaymentIntent または SetupIntent を作成する前に 3DS をリクエストすべきかどうかがわかります。不正利用防止エンジンがカードの詳細と取引の詳細の両方を調べる場合、確認中に詳細情報を取得した時点でパラメーターを指定します。その後で、結果として得られた PaymentIntent または SetupIntent をクライアントに渡して、プロセスを完了します。
API リファレンスで以下の各ケースの request_
パラメーターの使用方法を確認してください。
- PaymentIntent (支払いインテント) の作成
- PaymentIntent (支払いインテント) の確認
- SetupIntent (支払い方法設定インテント) の作成
- SetupIntent (支払い方法設定インテント) の確認
- Checkout セッションを作成する
request_
を any
に設定して、frictionless
フローを優先して手動で 3DS をリクエストします。この場合、顧客が追加入力をせずに認証が完了する可能性が高まります。
request_
を challenge
に設定し、challenge
フローを優先して 3DS をリクエストします。この場合、顧客はアクティブ認証のプロンプトに応答する必要があります。
ただし、カード発行会社が最終的な認証フローを決定するため、Stripe はご希望の優先順位を保証することはできません。最終的な認証フローを確認するには、Charge (支払い) または SetupAttempt の three_
プロパティの authentication_
を調査してください。3DS フローについて、詳細は Stripe の ガイドをご覧ください。
注意
3D セキュア認証がカードで利用可能な場合にのみ、Stripe は顧客に認証を実行して支払いを完了するよう求めます。3D セキュア認証が特定のカードで利用できない場合や、認証プロセス中にエラーが発生した場合、支払いは通常どおりに処理されます。
Stripe の SCA ルールは、3DS を手動でリクエストしたかどうかに関係なく、自動的に実行されます。お客様からの 3DS のプロンプトは補助的なものであり、SCA に必須ではありません。
3DS フローを表示する
3DS フローをテストする
Stripe テストカードと任意のセキュリティコード、郵便番号、将来の日付の有効期限を使用して、テスト環境で 3DS 認証のチャレンジフローを起動します。
テスト API キーを使用してシステムを構築するときに、認証プロセスで認証の模擬ページが表示されます。そのページでは支払いのオーソリまたはキャンセルを行うことができます。支払いをオーソリすると、認証の成功がシミュレートされ、お客様は指定された戻り URL にリダイレクトされます。失敗ボタンをクリックすると、試行での認証の失敗がシミュレートされます。
その他の Visa と Mastercard のテストカードはすべて、顧客のカード発行会社からの認証を必要としません。
カスタムの Radar ルールをテスト環境で作成して、テストカードに対する認証を起動できます。詳細は、Radar ルールのテストをご覧ください。
不審請求の申請とライアビリティシフト
The liability shift rule applies to payments successfully authenticated using 3D Secure. In some cases, liability shift applies with equivalent cryptograms, such as Apple Pay or Google Pay. If a cardholder disputes a 3DS payment as fraudulent, the liability typically shifts from you to the card issuer.
カードが 3DS に対応していないか、認証プロセスでエラーが発生した場合、支払いは通常どおりに進行します。このときは 3DS の認証が正常に行われていないため、通常、責任は発行会社に移動しません。
In practice, this means you typically won’t receive disputes marked as fraudulent if the payment is covered by the liability shift rule, but you might still receive an Early Fraud Warning. You might still receive a low percentage of fraudulent disputes, and we list a few cases below where the liability shift rule might not apply.
3DS を使用して正常に認証された支払いに関して不審請求の申請の照会を受ける場合があります。このタイプの不審請求の申請は、単なる情報のリクエストであるため、チャージバックが発生することはありません。
3D セキュアによって認証された支払いに関する照会を受けた場合、応答する「必要があります」。応答しないと、カード保有者の銀行が「無応答チャージバック」と呼ばれる金融チャージバックを開始して、ライアビリティシフトが無効になる可能性があるためです。3DS の支払いに対する無応答チャージバックを防ぐには、支払いに関する十分な情報を送信するようにします。注文内容、配送方法、配送先についての情報を含めてください (物品、電子製品、またはサービスのいずれの場合も)。
注
その他の理由 (商品を受け取っていないなど) で顧客が支払いの不審請求を申請した場合は、標準的な不審請求の申請プロセスが適用されます。経営管理、特に不審請求の申請への対応と申請そのものの回避について、十分な情報に基づいて判断してください。
カードネットワークで 3DS が要求され、カードまたはカード発行会社が 3DS を利用できない場合にも、ライアビリティシフトが発生する可能性があります。これは、カードネットワークが 3DS への対応を要求しているにもかかわらず、カード発行会社の 3DS サーバーがダウンしている場合や、カード発行会社が 3DS に対応していない場合に発生することがあります。カードが登録されていないため、支払いプロセスでカード保有者に 3DS 認証の実行を求めるメッセージは表示されません。カード保有者が 3DS 認証を実行していなくても、ライアビリティはカード発行会社にシフトできます。
Stripe は、3DS 認証の結果の electronic_
に、リクエストされた E コマースインジケーター (ECI) を返します。このインジケーターは、支払いがライアビリティシフトルールに準拠すべきか判断するのに役立ちます。最初の支払いインテントの応答に続いて 3DS が発生するので、通常はこれをいずれかのイベントの送信先に送信された charge.
イベントから取得します。リクエストされた ECI はカード発行会社の応答で変更される可能性があり、この場合は詳細は開示されません。
3DS を使用して支払いの認証が成功しても、ライアビリティシフトの対象にならない場合があります。これはまれなケースですが、たとえば、現在のアカウントで過度の不正利用があり、不正利用モニタリングプログラムに登録されている場合などに起こることがあります。また、一部のネットワークは、特定の業種をライアビリティシフトの対象から除外しています。たとえば、Visa は、電信送金または小為替に関与するビジネス、外貨または法定通貨以外の通貨を提供している金融機関以外のビジネス、ストアドバリュー型のカードの購入や補充などにおいて、ライアビリティシフトに対応していません。
まれなケースですが、ライアビリティシフトがオーソリ後にダウングレードされるか、カードネットワークの不審請求の申請の拒否システムが取引のライアビリティシフトを取得できないことがあります。このような場合、不審請求の申請に異議を申し立てると、Stripe は、リクエストされた ECI と支払いに対する 3DS 認証の結果を反証資料の詳細に自動的に追加しますが、不審請求の申請に対する主張が認められる可能性を高めるために、追加の詳細を含めることをお勧めします。
3DS とライアビリティシフトに関するカスタム Radar ルール
Radar for Teams を使用している場合は、ルールをカスタマイズして、3DS をリクエストするタイミングとそれぞれの特定の認証結果およびライアビリティシフトを処理する方法を制御できます。Stripe の強力な顧客認証 (SCA) ルールはカスタム Radar ルールとは別に自動実行されます。これにより、SCA が免除されている場合を除き、認証されていない支払いはブロックされます。