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 サービスを使用するには、サポートにお問い合わせください。

顧客がカードの詳細情報を入力します。

このステップで顧客の銀行が取引を評価し、3D セキュアを完了することができます。

銀行から要求された場合、顧客は追加の認証ステップを実行します。

3DS フローを制御する

強力な顧客認証 (SCA) などの規制要件によって要求された場合、またはカード発行会社から再試行可能な支払い拒否コード authentication_required によってリクエストされた場合に、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_payment_method に移行します。3DS が起動した理由によっては、支払いのオーソリステップを続行できる可能性があります。その場合、PaymentIntent のステータスは processing に移行します。
- 必須の場合: Stripe が、カード発行会社の 3D セキュアアクセス制御サーバー (ACS) に接続して、3DS フローを開始することで、3DS 認証フローを開始します。
Stripe が、カード発行会社から 3DS フローの情報を受け取ると、認証を試行します。PaymentIntent のステータスは requires_action に移行します。
- 必要な 3DS アクションの表示方法については、以下をご覧ください。カード発行会社はさまざまな 3DS フローのアクションタイプをリクエストする可能性があるため、常に 3DS チャレンジが視覚的に表示されるとは限りません (負担のないフローなど)。
- カード発行会社が 3DS にまったく対応していないか、障害が発生している場合、Stripe は認証なしで支払いの完了を試みることがあります (許容される場合)。
- Data for 3DS authentication requests is typically provided by the customer at the time of the transaction. To reduce friction and the possibility of failed authentication, we might complete these requests with data we infer from other sources such as data collected from your customer during the payment flow, records related to your customer’s past transactions with you, or relevant information available from the customer’s card or issuers.
- Stripeがすでに必要なすべての 3DS データ要素にアクセスできる場合、最適化された Stripe の 3DS サーバーが PaymentIntent を確定する際に、認証リクエストの完了を試行することがあります。これにより、3DS フローが成功した場合は PaymentIntent のステータスが processing に直接移行し、3DS フローを完了するために追加のステップまたはデータ要素が必要な場合は、requires_action のステータスに直接移行します。
3DS 認証の結果に応じて、次のようになります。
- 認証済み: Stripe は支払いを試み、PaymentIntent のステータスは processing に移行します。
- 失敗: PaymentIntent のステータスが requires_payment_method に移行し、別の支払い方法を試みる必要があることを示します。再確定して 3DS を再試行することもできます。
- その他のシナリオ: 支払いで 3DS が起動された理由によっては、エッジケースとして支払いに対するオーソリの続行が許容される可能性があります。たとえば、結果が attempt_acknowledged になると支払いに進み、PaymentIntent のステータスが processing に移行します。
  - 例外は、継続支払いのためのインドの電子同意書を作成する場合です。 authenticated 以外の結果はすべて失敗として扱われます。
支払いの結果に応じて、PaymentIntent のステータスは succeeded、requires_capture、requires_payment_method のいずれかに移行します。

カード支払いに対して 3DS がサポートされ、試行されたかどうかを追跡するには、Charge の payment_method_details でカード情報の three_d_secure プロパティーを読み取ります。three_d_secure プロパティーは、顧客がカードの認証を試行するときに Stripe によって設定されます。three_d_secure.result は、認証の結果を示します。

ダッシュボードで Radar ルールを使用する

Stripe は、PaymentIntent (支払いインテント) または SetupIntent (支払い方法設定インテント) の作成時や確定時に 3DS を動的にリクエストするデフォルトの Radar ルールを提供しています。お客様は、これらのルールをダッシュボードで設定できます。

Radar for Teams を利用している場合は、カスタムの 3DS ルールを追加できます。

API を使用して 3DS を手動でリクエストする

3DS をトリガーするデフォルトの方法は、リスクレベルやその他の要件に基づいて Radar を使用して 3D セキュアを動的にリクエストすることです。手動による 3DS のトリガーは、Stripe を独自の不正利用防止エンジンに導入する上級ユーザー向けの方法です。

3DS を手動でトリガーするには、PaymentIntent または SetupIntent の作成または確認時、あるいは Checkout セッションの作成時に最適化する対象に応じて、payment_method_options[card][request_three_d_secure] を any または challenge に設定します。このプロセスは、1 回限りの支払いの場合も、今後の支払いのために支払い方法を設定する場合も同じです。このパラメーターを指定すると、Stripe は 3DS の実行を試み、PaymentIntent、SetupIntent、または Checkout セッションの動的 3D Secure Radar ルールを上書きします。

このパラメーターを提供するタイミングは、お客様の不正利用防止エンジンがいつリスクを検知するかによって異なります。たとえば、不正利用防止エンジンがカードの詳細のみを調べる場合は、PaymentIntent または SetupIntent を作成する前に 3DS をリクエストすべきかどうかがわかります。不正利用防止エンジンがカードの詳細と取引の詳細の両方を調べる場合、確認中に詳細情報を取得した時点でパラメーターを指定します。その後で、結果として得られた PaymentIntent または SetupIntent をクライアントに渡して、プロセスを完了します。

API リファレンスで以下の各ケースの request_three_d_secure パラメーターの使用方法を確認してください。

request_three_d_secure を any に設定して、frictionless フローを優先して手動で 3DS をリクエストします。この場合、顧客が追加入力をせずに認証が完了する可能性が高まります。

request_three_d_secure を challenge に設定し、challenge フローを優先して 3DS をリクエストします。この場合、顧客はアクティブ認証のプロンプトに応答する必要があります。

ただし、カード発行会社が最終的な認証フローを決定するため、Stripe はご希望の優先順位を保証することはできません。最終的な認証フローを確認するには、Charge (支払い) または SetupAttempt の three_d_secure プロパティの authentication_flow を調査してください。3DS フローについて、詳細は Stripe のガイドをご覧ください。

注意

3D セキュア認証がカードで利用可能な場合にのみ、Stripe は顧客に認証を実行して支払いを完了するよう求めます。3D セキュア認証が特定のカードで利用できない場合や、認証プロセス中にエラーが発生した場合、支払いは通常どおりに処理されます。

Stripe の SCA ルールは、3DS を手動でリクエストしたかどうかに関係なく、自動的に実行されます。お客様からの 3DS のプロンプトは補助的なものであり、SCA に必須ではありません。

3DS フローを表示する

confirmCardPayment と handleCardAction を呼び出す際に、Stripe はポップアップモーダルで認証 UI を自動的に表示します。銀行のウェブサイトにリダイレクトすることも、iframe を使用することもできます。

Stripe.js は、3DS2 認証中に基本デバイス情報を収集し、リスク分析のためにカード発行会社に送信します。

銀行のウェブサイトにリダイレクトする

顧客を 3DS 認証ページにリダイレクトするには、サーバー上またはクライアント側での確定時に PaymentIntent に return_url を渡します。

確定後、PaymentIntent のステータスが requires_action の場合、PaymentIntent の next_action を調べます。これに redirect_to_url が含まれる場合、3DS が必要であることを意味します。

next_action: {
    type: 'redirect_to_url',
    redirect_to_url: {
      url: 'https://hooks.stripe.com/...',
      return_url: 'https://mysite.com'
    }
}

ブラウザーで、顧客を redirect_to_url hash の url にリダイレクトして認証を完了します。

var action = intent.next_action;
  if (action && action.type === 'redirect_to_url') {
    window.location = action.redirect_to_url.url;
  }

認証プロセスを完了した顧客は、お客様が PaymentIntent の作成時または確認時に指定した return_url にリダイレクトされます。またリダイレクトによって、payment_intent および payment_intent_client_secret の URL クエリパラメーターも追加されます。アプリケーションはこれを使用して購入に関連付けられた PaymentIntent を識別できます。

iframe で表示する

ウェブ上の認証 UI をウェブサイトのデザインに合わせてカスタマイズすることはできません。カードを発行した銀行がフォントと色を管理します。

ただし、3D セキュア UI が表示される「方法」と「場所」はお客様が選択できます。大多数のビジネスは、これを支払いページの上に表示されるモーダルダイアログに表示しています。自社で構築済みのモーダルコンポーネントがある場合は、3DS フレームをその中に配置できます。認証のコンテンツを決済フォームとともにインラインで表示することもできます。

PaymentIntent を確定するサーバー側

顧客が購入を完了する準備ができたら、お客様は PaymentIntent を確定して支払いの回収プロセスを開始します。

3DS の表示方法を制御するには、return_url を指定します。これは認証の完了後に 3DS の <iframe> がリダイレクトされる場所です。お客様のサイトでコンテンツセキュリティポリシーを使用している場合は、ポリシーが https://js.stripe.com、https://hooks.stripe.com からの iframe、および return_url に渡した URL のオリジンを許可していることを確認します。

フロントエンドから確定している場合は、Stripe.js の confirmCardPayment メソッドを使用します。たとえば、Stripe Elements を使用してカード情報を収集している場合は以下のようになります。

stripe.confirmCardPayment(
  '{{PAYMENT_INTENT_CLIENT_SECRET}}',
  {
    payment_method: {card: cardElement},
    return_url: 'https://example.com/return_url'
  },
  // Disable the default next action handling.
  {handleActions: false}
).then(function(result) {
  // Handle result.error or result.paymentIntent
  // More details in Step 2.
});

サーバーから確定する場合は、return_url を指定してください。実装内容によっては、他の情報も confirm に渡すことをお勧めします。

PaymentIntent のステータスを確認するサーバー側

次に、確定した PaymentIntent の status プロパティーを確認して、支払いが正常に完了したかどうかを特定します。表示される可能性がある status の値とその意味を次のリストに示します。

ステータス	説明
`requires_payment_method`	要求は `402` HTTP ステータスコードで失敗しました。これは、支払いが失敗したことを示しています。last_payment_error プロパティーを確認し、必要に応じて顧客から新しい支払い情報を入手して、再試行してください。
`requires_capture`	リクエストは認証されずに完了しました。引き続き売上をキャプチャーすることができます。
`requires_action`	支払いを完了するには、3DS などの追加ステップが必要です。アプリケーションに戻って支払いを完了するように顧客に依頼してください。
`succeeded`	支払いが完了し、指定した支払い方法で Charge オブジェクトが作成されます。これ以上のステップは必要ありません。

2019-02-11 以前の API のバージョンでは、requires_payment_method の代わりに requires_source、requires_action の代わりに requires_source_action が表示されます。

3DS iframe をレンダリングするクライアント側

status プロパティーの値が requires_action のときは、支払いを処理する前に追加ステップを完了する必要があります。3DS が必須のカード支払いの場合、PaymentIntent の status は requires_action と表示され、その next_action プロパティーは redirect_to_url と表示されます。redirect_to_url のペイロードには、3DS を表示するために iframe で開く URL が含まれます。

var iframe = document.createElement('iframe');
  iframe.src = paymentIntent.next_action.redirect_to_url.url;
  iframe.width = 600;
  iframe.height = 400;
  yourContainer.appendChild(iframe);

3DS2 については、3DS のコンテンツを 250x400、390x400、500x600、600x400 の各サイズおよび全画面で表示できるようにカード発行会社が対応する必要があります (サイズは幅 × 高さ)。3DS の UI は、iframe を厳密に上記のサイズで開くことで視認性を高めることができます。

注意

3DS iframe では、sandbox 属性を使用できません。本番環境では、この iframe 内にある一部のコンテンツがカード発行会社によって制御されます。一部の発行会社の実装では、サンドボックス化されている場合にエラーが発生し、支払いが成功しません。

リダイレクトを処理するクライアント側

顧客が 3DS を完了すると、iframe は PaymentIntent の確定時に指定した return_url に移動します。このページは、3DS 認証が完了したことを知らせるために、お客様のトップレベルのページに postMessage を送信する必要があります。次に、そのトップレベルのページで、支払いが成功したか、顧客による追加のアクションが必要であるかを判別する必要があります。

たとえば、return_url ページで次のような作業を実行することが考えられます。

window.top.postMessage('3DS-authentication-complete');

お客様の支払いのトップページで、この postMessage をリッスンして、認証が終了したときに認識できるようにする必要があります。次に、更新された PaymentIntent を取得して、支払いのステータスを確認する必要があります。認証が失敗した場合、PaymentIntent のステータスは requires_payment_method になります。支払いが正常に完了した場合、ステータスは succeeded になります。オーソリとキャプチャーを分離する場合、ステータスは requires_capture になります。

function on3DSComplete() {
    // Hide the 3DS UI
    yourContainer.remove();

    // Check the PaymentIntent
    stripe.retrievePaymentIntent('{{PAYMENT_INTENT_CLIENT_SECRET}}')
      .then(function(result) {
        if (result.error) {
          // PaymentIntent client secret was invalid
        } else {
          if (result.paymentIntent.status === 'succeeded') {
            // Show your customer that the payment has succeeded
          } else if (result.paymentIntent.status === 'requires_payment_method') {
            // Authentication failed, prompt the customer to enter another payment method
          }
        }
      });
  }

  window.addEventListener('message', function(ev) {
    if (ev.data === '3DS-authentication-complete') {
      on3DSComplete();
    }
  }, false);

3DS フローをテストする

Stripe テストカードと任意のセキュリティコード、郵便番号、将来の日付の有効期限を使用して、テスト環境で 3DS 認証のチャレンジフローを起動します。

テスト API キーを使用してシステムを構築するときに、認証プロセスで認証の模擬ページが表示されます。そのページでは支払いのオーソリまたはキャンセルを行うことができます。支払いをオーソリすると、認証の成功がシミュレートされ、お客様は指定された戻り URL にリダイレクトされます。失敗ボタンをクリックすると、試行での認証の失敗がシミュレートされます。

番号	3DS の使用状況	説明
	必須	支払いを成功させるには、常に 3DS2 認証を完了する必要があります。デフォルトの場合、Radar ルールはこのカードの 3DS 認証をリクエストします。
	必須	このカードでは、将来の支払いに備えた設定がない限り、オフセッションの支払いで 3DS2 認証が必要です。設定した後は、オフセッションの支払いで認証は不要になります。
	必須	3DS 認証が必要ですが、認証後に支払いが `card_declined` エラーコードで拒否されます。デフォルトの場合、Radar ルールはこのカードの 3DS 認証をリクエストします。
	対応可能	3DS 認証も引き続き実行できますが、必須ではありません。デフォルトの場合、Radar ルールはこのカードの 3DS 認証をリクエストしません。
	対応可能	このカードは 3DS に対応していますが、3DS に登録されていません。このため、Radar ルールで 3DS がリクエストされても、顧客は追加の認証を行いません。デフォルトの場合、Radar ルールはこのカードの 3DS 認証をリクエストしません。
	対応不可	このカードは 3DS に対応していないため、呼び出すことができません。PaymentIntent は、認証を行わずに続行されます。

その他の Visa と Mastercard のテストカードはすべて、顧客のカード発行会社からの認証を必要としません。

カスタムの Radar ルールをテスト環境で作成して、テストカードに対する認証を起動できます。詳細は、Radar ルールのテストをご覧ください。

不審請求の申請とライアビリティシフト

ライアビリティシフトルールは、3D セキュアを使用して正常に認証された支払い、または場合によっては同等の暗号化 (Apple Pay や Google Pay など) に適用されます。カード保有者が 3DS による支払いを不正利用として不審請求を申請した場合、責任はお客様からカード発行会社に移動します。

カードが 3DS に対応していないか、認証プロセスでエラーが発生した場合、支払いは通常どおりに進行します。このときは 3DS の認証が正常に行われていないため、通常、責任は発行会社に移動しません。

言い換えると、実際には、支払いがライアビリティシフトルールの対象になっていれば、不正利用のマークが付けられた不審請求の申請をお客様が受け取ることはありませんが、それでも不正利用の早期警告は受け取る可能性があります。低い割合ながら不正利用に関する申請を受け取る可能性もあります。ライアビリティシフトルールが適用されない事例をいくつか以下に挙げます。

3DS を使用して正常に認証された支払いに関して不審請求の申請の照会を受ける場合があります。このタイプの不審請求の申請は、単なる情報のリクエストであるため、チャージバックが発生することはありません。

3D セキュアによって認証された支払いに関する照会を受けた場合、応答する「必要があります」。応答しないと、カード保有者の銀行が「無応答チャージバック」と呼ばれる金融チャージバックを開始して、ライアビリティシフトが無効になる可能性があるためです。3DS の支払いに対する無応答チャージバックを防ぐには、支払いに関する十分な情報を送信するようにします。注文内容、配送方法、配送先についての情報を含めてください (物品、電子製品、またはサービスのいずれの場合も)。

注

その他の理由 (商品を受け取っていないなど) で顧客が支払いの不審請求を申請した場合は、標準的な不審請求の申請プロセスが適用されます。経営管理、特に不審請求の申請への対応と申請そのものの回避について、十分な情報に基づいて判断してください。

カードネットワークで 3DS が要求され、カードまたはカード発行会社が 3DS を利用できない場合にも、ライアビリティシフトが発生する可能性があります。これは、カードネットワークが 3DS への対応を要求しているにもかかわらず、カード発行会社の 3DS サーバーがダウンしている場合や、カード発行会社が 3DS に対応していない場合に発生することがあります。カードが登録されていないため、支払いプロセスでカード保有者に 3DS 認証の実行を求めるメッセージは表示されません。カード保有者が 3DS 認証を実行していなくても、ライアビリティはカード発行会社にシフトできます。

Stripe は、3DS 認証の結果の electronic_commerce_indicator に、リクエストされた E コマースインジケーター (ECI) を返します。このインジケーターは、支払いがライアビリティシフトルールに準拠すべきか判断するのに役立ちます。最初の支払いインテントの応答に続いて 3DS が発生するので、通常はこれをいずれかのイベントの送信先に送信された charge.succeeded イベントから取得します。リクエストされた ECI はカード発行会社の応答で変更される可能性があり、この場合は詳細は開示されません。

3DS を使用して支払いの認証が成功しても、ライアビリティシフトの対象にならない場合があります。これはまれなケースですが、たとえば、現在のアカウントで過度の不正利用があり、不正利用モニタリングプログラムに登録されている場合などに起こることがあります。また、一部のネットワークは、特定の業種をライアビリティシフトの対象から除外しています。たとえば、Visa は、電信送金または小為替に関与するビジネス、外貨または法定通貨以外の通貨を提供している金融機関以外のビジネス、ストアドバリュー型のカードの購入や補充などにおいて、ライアビリティシフトに対応していません。

まれなケースですが、ライアビリティシフトがオーソリ後にダウングレードされるか、カードネットワークの不審請求の申請の拒否システムが取引のライアビリティシフトを取得できないことがあります。このような場合、不審請求の申請に異議を申し立てると、Stripe は、リクエストされた ECI と支払いに対する 3DS 認証の結果を反証資料の詳細に自動的に追加しますが、不審請求の申請に対する主張が認められる可能性を高めるために、追加の詳細を含めることをお勧めします。

3DS とライアビリティシフトに関するカスタム Radar ルール

Radar for Teams を使用している場合は、ルールをカスタマイズして、3DS をリクエストするタイミングとそれぞれの特定の認証結果およびライアビリティシフトを処理する方法を制御できます。Stripe の強力な顧客認証 (SCA) ルールはカスタム Radar ルールとは別に自動実行されます。これにより、SCA が免除されている場合を除き、認証されていない支払いはブロックされます。

注