3D セキュアを使用して認証する
注意
Major card brands no longer support 3D Secure 1. If your implementation uses 3D Secure 1, update it to use the Payment Intents and Setup Intents APIs. Using those APIs:
- 3D セキュア 2 (3DS2) をサポートします。
- Takes advantage of Dynamic 3D Secure.
- Complies with European Strong Customer Authentication regulations.
Web、iOS、Android、React Native など、複数のプラットフォームで 3D セキュア (3DS) 認証を決済フローに導入できます。この導入より、顧客の銀行が対応している場合は 3D セキュア 2 (3DS2) が実行され、対応していない場合は 3D セキュア 1 にフォールバックされます。他の決済代行業者で Stripe の 3DS サービスを使用するには、サポートにお問い合わせください。
3DS フローを制御する
Stripe triggers 3DS automatically if required by a regulatory mandate such as Strong Customer Authentication or requested by an issuer with the soft decline code authentication_required
.
Radar ルールまたは API を使用して、3DS 認証の実行をエンドユーザーに求めるタイミングを制御し、任意のパラメーターに基づいてユーザーごとに決定することもできます。ただし、ウォレットやオフセッションの支払いなどの一部の取引は 3DS に対応していません。
支払いで 3DS が起動されると、3DS 認証がカードで利用可能な場合、Stripe は認証を実行して支払いを完了することをユーザーに要求します。使用するフロントエンドによっては、3DS フローの表示を求められる場合があります。
3DS を起動する一般的な Payment Intent API フローは、次のようになります。
- PaymentIntent、SetupIntent を確定するか、Customer に PaymentMethod を関連付ける支払い情報を、ユーザーが入力します。
- 規制に関する同意書、Radar ルール、手動 API リクエスト、カード発行会社による再試行可能な支払い拒否などの基準に基づいて、取引が 3DS をサポートし、必須であるかどうかを、Stripe が評価します。
- 3DS の状況に応じて次のようになります。
- Not required: For example, because of an exemption, Stripe attempts the charge. The PaymentIntent transitions to a status of
processing
. If requested by the issuer with a soft decline, we automatically reattempt and continue as if required. - サポート対象外の場合: PaymentIntent のステータスが
requires_payment_method
に移行します。3DS が起動した理由によっては、支払いのオーソリステップを続行できる可能性があります。その場合、PaymentIntent のステータスはprocessing
に移行します。 - 必須の場合: Stripe が、カード発行会社の 3D セキュアアクセス制御サーバー (ACS) に接続して、3DS フローを開始することで、3DS 認証フローを開始します。
- Not required: For example, because of an exemption, Stripe attempts the charge. The PaymentIntent transitions to a status of
- Stripe が、カード発行会社から 3DS フローの情報を受け取ると、認証を試行します。PaymentIntent のステータスは
requires_action
に移行します。- 必要な 3DS アクションの表示方法については、以下をご覧ください。カード発行会社はさまざまな 3DS フローのアクションタイプをリクエストする可能性があるため、常に 3DS チャレンジが視覚的に表示されるとは限りません (負担のないフローなど)。
- カード発行会社が 3DS にまったく対応していないか、障害が発生している場合、Stripe は認証なしで支払いの完了を試みることがあります (許容される場合)。
- 3DS 認証の結果に応じて、次のようになります。
- 認証済み: Stripe は支払いを試み、PaymentIntent のステータスは
processing
に移行します。 - 失敗: PaymentIntent のステータスが
requires_payment_method
に移行し、別の決済手段を試みる必要があることを示します。再確定して 3DS を再試行することもできます。 - Other scenarios: Depending on the reason the payment triggered 3DS, it might be permissible to continue authorization for the charge in edge cases. For example, a result of
attempt_acknowledged
leads to a charge and the PaymentIntent transitions to a status ofprocessing
.- An exception is when creating Indian e-mandates for recurring payments. Anything but an
authenticated
result is treated as failure.
- An exception is when creating Indian e-mandates for recurring payments. Anything but an
- 認証済み: Stripe は支払いを試み、PaymentIntent のステータスは
- 支払いの結果に応じて、PaymentIntent のステータスは
succeeded
、requires_capture
、requires_payment_method
のいずれかに移行します。
To track whether 3DS was supported and attempted on a card payment, read the three_d_secure property on the card information in the Charge’s payment_method_details
. Stripe populates the three_d_secure
property when the customer attempts to authenticate the card—three_d_secure.result
indicates the authentication outcome.
ダッシュボードで Radar ルールを使用する
Stripe provides default Radar rules to dynamically request 3DS when creating or confirming a PaymentIntent or SetupIntent. You can configure these rules in your Dashboard.
If you have Radar for Fraud Teams, you can add custom 3DS rules.
API を使用して 3DS を手動でリクエストする
3DS をトリガーするデフォルトの方法は、リスクレベルやその他の要件に基づいて Radar を使用して 3D セキュアを動的にリクエストすることです。手動による 3DS のトリガーは、Stripe を独自の不正利用防止エンジンに導入する上級ユーザー向けの方法です。
To trigger 3DS manually, set payment_method_options[card][request_three_d_secure]
to any
or challenge
depending on what you want to optimize for when creating or confirming a PaymentIntent or SetupIntent. This process is the same for one-time payments or when setting up a payment method for future payments. When you provide this parameter, Stripe attempts to perform 3DS and overrides any dynamic 3D Secure Radar rules on the PaymentIntent or SetupIntent.
このパラメーターを提供するタイミングは、お客様の不正利用防止エンジンがいつリスクを検知するかによって異なります。たとえば、不正利用防止エンジンがカードの詳細のみを調べる場合は、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 can’t guarantee your preference because the issuer determines the ultimate authentication flow. You can find out what the ultimate authentication flow was by inspecting the authentication_flow
on the three_d_secure
property of the Charge or SetupAttempt. To learn more about 3DS flows, read our guide.
注意
3D セキュア認証がカードで利用可能な場合にのみ、Stripe は顧客に認証を実行して支払いを完了するよう求めます。3D セキュア認証が特定のカードで利用できない場合や、認証プロセス中にエラーが発生した場合、支払いは通常どおりに処理されます。
Stripe の SCA ルールは、3DS を手動でリクエストしたかどうかに関係なく、自動的に実行されます。お客様からの 3DS のプロンプトは補助的なものであり、SCA に必須ではありません。
3DS フローを表示する
3DS フローをテストする
Stripe テストカードと任意のセキュリティコード、郵便番号、将来の日付の有効期限を使用して、テスト環境で 3DS 認証のチャレンジフローを起動します。
テスト API キーを使用してシステムを構築するときに、認証プロセスで認証の模擬ページが表示されます。そのページでは支払いのオーソリまたはキャンセルを行うことができます。支払いをオーソリすると、認証の成功がシミュレートされ、お客様は指定された戻り URL にリダイレクトされます。失敗ボタンをクリックすると、試行での認証の失敗がシミュレートされます。
All other Visa and Mastercard test cards don’t require authentication from the customer’s card issuer.
You can write custom Radar rules in test mode to trigger authentication on test cards. Learn more about testing your Radar rules.
不審請求の申請とライアビリティシフト
The liability shift rule applies to payments that are successfully authenticated using 3D Secure or an equivalent cryptogram such as Apple Pay or Google Pay in some cases. If a cardholder disputes a 3DS payment as fraudulent, the liability shifts from you to the card issuer.
カードが 3DS に対応していないか、認証プロセスでエラーが発生した場合、支払いは通常どおりに進行します。このときは 3DS の認証が正常に行われていないため、通常、責任は発行会社に移動しません。
In practice, this means that you won’t receive disputes marked as fraudulent if the payment was 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.
You might receive a dispute inquiry on a successfully authenticated payment using 3DS. This type of dispute doesn’t precipitate a chargeback because it’s only a request for information.
3D セキュアによって認証された支払いに関する照会を受けた場合、応答する「必要があります」。応答しないと、カード保有者の銀行が「無応答チャージバック」と呼ばれる金融チャージバックを開始して、ライアビリティシフトが無効になる可能性があるためです。3DS の支払いに対する無応答チャージバックを防ぐには、支払いに関する十分な情報を送信するようにします。注文内容、配送方法、配送先についての情報を含めてください (物品、電子製品、またはサービスのいずれの場合も)。
注
If a customer disputes a payment for any other reason (for example, product not received), then the standard dispute process applies. Make informed decisions about your business management, especially in handling and completely avoiding disputes.
カードネットワークで 3DS が要求され、カードまたはカード発行会社が 3DS を利用できない場合にも、ライアビリティシフトが発生する可能性があります。これは、カードネットワークが 3DS への対応を要求しているにもかかわらず、カード発行会社の 3DS サーバーがダウンしている場合や、カード発行会社が 3DS に対応していない場合に発生することがあります。カードが登録されていないため、支払いプロセスでカード保有者に 3DS 認証の実行を求めるメッセージは表示されません。カード保有者が 3DS 認証を実行していなくても、ライアビリティはカード発行会社にシフトできます。
Stripe returns the requested Electronic Commerce Indicator (ECI) in the electronic_commerce_indicator
of the 3DS authentication outcome. This indicator can aid in determining whether a charge should adhere to the liability shift rule. As 3DS occurs subsequent to the initial payment intent response, you typically get this from a charge.succeeded
webhook. A requested ECI might be degraded in the issuer response, which we don’t reveal.
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.
In rare cases, liability shift might get downgraded post-authorization, or the card networks’ dispute rejection system might fail to catch liability shift for a transaction. In these cases, if you counter the dispute, Stripe automatically adds the requested ECI and the 3DS authentication outcome for the payment to your evidence details, but we encourage you to include additional details to improve your odds of winning the dispute.
3DS とライアビリティシフトに関するカスタム Radar ルール
If you have Radar for Fraud Teams, you can customize your rules to control when to request 3DS and how to handle each specific authentication outcome and liability shift. Stripe’s Strong Customer Authentication (SCA) rules run automatically and independently of custom Radar rules, and block unauthenticated payments unless exempted.