3D セキュアを使用して認証する

You can integrate 3D Secure (3DS) authentication into your checkout flow on multiple platforms, including Web, iOS, Android, and React Native. This integration runs 3D Secure 2 (3DS2) when supported by the customer’s bank and falls back to 3D Secure 1 otherwise. You can also perform 3DS authentication on Stripe while acquiring the transaction with another payment service provider (PSP) by using the Standalone 3DS product.

ウェブ

iOS

Android

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

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

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

3DS フローを制御する

Stripe triggers 3DS automatically if mandated by regulations such as Strong Customer Authentication in Europe, industry guidelines such as the Credit Card Security Guidelines in Japan, if requested by an issuer with a soft decline code, or if certain Stripe optimizations apply.

You can also use Radar or the API to decide when to prompt users for 3DS authentication. This allows you to customize the authentication process for each user based on your chosen parameters. However, not all transactions support 3DS, for example wallets or off-session payments.

When a payment triggers 3DS, the card issuer requires the customer to authenticate to complete the payment, as long as 3DS authentication is supported for that card. While Stripe initiates the authentication request, the requirement comes from the issuer. Depending on the frontend you’re using, this might require you to display the 3DS Flow.

3DS を起動する一般的な Payment Intent API フローは、次のようになります。

1. PaymentIntent、SetupIntent を確定するか、Customer に PaymentMethod を関連付ける支払い情報を、ユーザーが入力します。
2. 規制に関する同意書、Radar ルール、手動 API リクエスト、カード発行会社による再試行可能な支払い拒否などの基準に基づいて、取引が 3DS をサポートし、必須であるかどうかを、Stripe が評価します。
3. 3DS の状況に応じて次のようになります。
   • 必須でない場合: 免除などの理由により、Stripe が支払いを試行します。PaymentIntent のステータスは processing に移行します。カード発行会社から再試行可能な支払い拒否によってリクエストされた場合は、必要に応じて自動的に再試行して続行します。
   • サポート対象外の場合: PaymentIntent のステータスが requires_payment_method に移行します。3DS が起動した理由によっては、支払いのオーソリステップを続行できる可能性があります。その場合、PaymentIntent のステータスは processing に移行します。
   • 必須の場合: Stripe が、カード発行会社の 3D セキュアアクセス制御サーバー (ACS) に接続して、3DS フローを開始することで、3DS 認証フローを開始します。
4. When 3DS flow information is received from the issuer, Stripe submits the request for the issuer to authenticate the cardholder. The PaymentIntent transitions to a status of requires_action:
   • 必要な 3DS アクションの表示方法については、以下をご覧ください。カード発行会社はさまざまな 3DS フローのアクションタイプをリクエストする可能性があるため、常に 3DS チャレンジが視覚的に表示されるとは限りません (負担のないフローなど)。
   • カード発行会社が 3DS にまったく対応していないか、障害が発生している場合、Stripe は認証なしで支払いの完了を試みることがあります (許容される場合)。
   • 通常、3DS 認証リクエストのデータは取引の時点で顧客によって提供されます。負担と認証失敗の可能性を軽減するため、Stripe は、決済フロー中に顧客から収集したデータ、顧客の過去の取引に関する記録、または顧客のカードまたはカード発行会社から入手できえる関連情報など、他のソースから推測されるデータを使用して、これらのリクエストを完了することがあります。
   • Stripeがすでに必要なすべての 3DS データ要素にアクセスできる場合、最適化された Stripe の 3DS サーバーが PaymentIntent を確定する際に、認証リクエストの完了を試行することがあります。これにより、3DS フローが成功した場合は PaymentIntent のステータスが processing に直接移行し、3DS フローを完了するために追加のステップまたはデータ要素が必要な場合は、requires_action のステータスに直接移行します。
5. 3DS 認証の結果に応じて、次のようになります。
   • 認証済み: Stripe は支払いを試み、PaymentIntent のステータスは processing に移行します。
   • 失敗: PaymentIntent のステータスが requires_payment_method に移行し、別の支払い方法を試みる必要があることを示します。再確定して 3DS を再試行することもできます。
   • その他のシナリオ: 支払いで 3DS が起動された理由によっては、エッジケースとして支払いに対するオーソリの続行が許容される可能性があります。たとえば、結果が attempt_acknowledged になると支払いに進み、PaymentIntent のステータスが processing に移行します。
     • 例外は、継続支払いのためのインドの電子同意書を作成する場合です。 authenticated 以外の結果はすべて失敗として扱われます。
6. 支払いの結果に応じて、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 provides fraud controls to dynamically request 3DS when creating or confirming a PaymentIntent or SetupIntent. You can configure these rules in your Dashboard.

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

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

The default method to trigger 3DS is using Radar to dynamically request 3D Secure based on risk level and other requirements. Triggering 3DS manually is for advanced users integrating Stripe with their own fraud engine.

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

curl https://api.stripe.com/v1/payment_intents \
  -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:" \
  -d amount=1000 \
  -d currency=usd \
  -d "payment_method_options[card][request_three_d_secure]"=any

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

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

• PaymentIntent (支払いインテント) の作成
• PaymentIntent (支払いインテント) の確認
• SetupIntent (支払い方法設定インテント) の作成
• SetupIntent (支払い方法設定インテント) の確認
• Checkout セッションを作成する

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

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

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

Stripe’s mandatory authentication rules run automatically, regardless of whether or not you manually request 3DS. Any 3DS requests from you are additional to those required for SCA.

3DS フローを表示する

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

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

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.
});

curl https://api.stripe.com/v1/payment_intents/{{PAYMENT_INTENT_ID}}/confirm \
  -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:" \
  --data-urlencode return_url="https://example.com/return_url"

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

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

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 にリダイレクトされます。失敗ボタンをクリックすると、試行での認証の失敗がシミュレートされます。

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

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

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

The liability shift rule typically 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 の認証が正常に行われていないため、通常、責任は発行会社に移動しません。

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

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

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

Liability shift might also occur when the card network requires 3DS, but it isn’t available for the card or issuer. This can happen if the issuer’s 3DS provider is down or if the issuer doesn’t support it, despite the card network requiring support. During the payment process, the cardholder isn’t prompted to complete 3DS authentication, because the card isn’t enrolled. Although the cardholder didn’t complete 3DS authentication, liability can still shift to the issuer.

Stripeは、リクエストされた Electronic Commerce Indicator (ECI) を 3DS 認証結果の electronic_commerce_indicator で返します。このインジケーターは、請求がライアビリティシフトルールに従う必要があるかどうかを判断するのに役立ちます。3DS は最初の支払いインテントのレスポンスに続いて発生するため、通常は、設定した Webhook エンドポイントまたはその他のイベントの送信先のいずれかに送信される charge.succeeded イベントから取得します。リクエストされた ECI は、イシュアーのレスポンスで劣化する可能性がありますが、この情報は開示されません。

Sometimes payments that are successfully authenticated using 3DS don’t fall under liability shift. This is rare and can happen, for example, if you have an excessive level of fraud on your account and are enrolled in a fraud monitoring program. Certain networks have also exempted some industries from liability shift. For example, Visa doesn’t support liability shift for businesses engaging in wire transfer or money orders, non-financial institutions offering foreign or non-fiat currency, or stored-value card purchase or load.

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

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

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