# 3D セキュアがリクエストされた場合でも、認証なしで支払いが成功することがあるのはなぜですか？

支払いで 3D セキュア認証が要求されていても開始できない場合は、最終的に認証を行わずに支払いの完了が試行されます。このフォールバックの支払いによって、PaymentIntent のステータスが次のいずれかに更新されます。
* `succeeded`: 支払いが完了し、指定した決済手段で Charge オブジェクトが作成されます。これ以上の対応は不要です。
* `requires_capture`: リクエストが認証なしで完了し、引き続き売上確定処理に進むことができます。
* `requires_payment_method`: 支払いが失敗した可能性があり、別の決済手段が要求されています。
一般的に、3D セキュアをトリガーする支払いでは、PaymentIntent のステータスが最終的に `requires_action` になります。ここでは、3D セキュアが要求される一般的な決済フローを紹介します。
1. 顧客が支払い情報を提出すると、その情報が PaymentIntent に関連付けられます。
1. Stripe で 3D セキュアが必要かどうかを確認します。これは [Radar ルール](https://stripe.com/docs/radar/rules) や、3D セキュアが [支払いに対して手動でリクエストされた](https://stripe.com/docs/payments/3d-secure#manual-three-ds) かどうかなどの要因に基づいて判断されます。
1. Stripe の判断で 3D セキュアが
   * **不要**な場合は、続行してカードへの請求を試行します。この時点で、銀行は「再試行可能な支払いの拒否」を送り返し、支払いを成功させるために認証が必要なことが伝えられます。
   * **必要**な場合は、次のステップに続行して 3DS をトリガーします。
1. Stripe で 3D セキュアを開始します。
1. Stripe による 3D セキュアのリクエストが完了したら、顧客が認証するのを待ちます。PaymentIntent のステータスが `requires_action` に移行します。
ステップ 4 または 5 が失敗した場合、上記の決済フローは以下のような形に変更されます。
1. 顧客が支払い情報を提出すると、その情報が PaymentIntent に関連付けられます。
1. Stripe で 3D セキュアが必要かどうかを確認します (Radar ルールや、支払いで手動リクエストされたかどうかなどの要因に基づいて判断されます)。
1. Stripe で 3D セキュアが必要だと判断し、認証プロセスを試行します。
1. 3D セキュアのプロセスの開始中に問題が発生します。これは、カードが 3DS に対応していない、処理のエラー、カード発行会社の 3D セキュアサーバーがダウンしているなど、さまざまな理由で発生する可能性があります。
1. 3DS が正常に完了しなかった場合でも、続行して、認証なしで最終的な支払いを試みます。これにより、支払いの結果に応じて PaymentIntent のステータスが `succeeded`、`requires_capture`、`requires_payment_method` のいずれかに移行します。
Stripe が支払いを即座にブロックしたりエラーを返したりせずにこの方法を試みるのは、[コンバージョン](https://stripe.com/docs/dashboard/conversion-analysis) の最適化を重視しているためです。
フォールバックの支払いが失敗した場合、PaymentIntent のステータスは `requires_payment_method` に更新されます。フォールバックの支払いが成功した場合、その支払いの [`payment_method_details.card.three_d_secure.result`](https://stripe.com/docs/api/setup_attempts/object#setup_attempt_object-payment_method_details-card-three_d_secure-result) のステータスが `attempt_acknowledged` でない限り、ライアビリティシフトは適用されません。
認証なしの支払いとライアビリティシフトの詳細については、Radar Plus による、ライアビリティシフトの対象とならない支払いの防止 をご覧ください。