支払いで 3D セキュア認証が要求されていても開始できない場合は、最終的に認証を行わずに支払いの完了が試行されます。このフォールバックの支払いによって、PaymentIntent のステータスが次のいずれかに更新されます。

• succeeded:支払いが完了し、指定した支払い方法で Charge オブジェクトが作成されます。これ以上のステップは必要ありません。
• requires_capture:リクエストが認証なしで完了し、引き続き売上をキャプチャーすることが可能です。
• requires_payment_method:支払いが失敗した可能性があり、別の支払い方法が要求されています。

一般的に、3D セキュアをトリガーする支払いでは、PaymentIntent のステータスが最終的に requires_action になります。ここでは、3D セキュアが要求される一般的な決済フローを紹介します。

1. 購入者が支払い情報を提出すると、その情報が PaymentIntent に関連付けられます。
2. Stripe で 3D セキュアが必要かどうかを確認します。この過程では、Radar ルールやその他の要素によって、3D セキュアが支払いに対して手動でリクエストされたかどうかを判断できます。
3. Stripe の判断で 3D セキュアが
   1. 不要な場合は、続行してカードへの請求を試行します。この時点で、銀行は「再試行可能な支払いの拒否」を送り返し、支払いを成功させるために認証が必要なことが伝えられます。
   2. 必要な場合は、次のステップに続行して 3DS をトリガーします。
4. Stripe で 3D セキュアを開始します。
5. Stripe による 3D セキュアのリクエストが完了したら、購入者が認証するのを待ちます。PaymentIntent のステータスが requires_action に移行します。

ステップ 4 または 5 が失敗した場合、上記の決済フローは以下のような形に変更されます。

1. 購入者が支払い情報を提出すると、その情報が PaymentIntent に関連付けられます。
2. Stripe で 3D セキュアが必要かどうかを確認します (Radar ルールやその他の要素によって、3D セキュアが支払いに対して手動でリクエストされたかどうかを判断します)。
3. Stripe で 3D セキュアが必要だと判断し、認証プロセスを試行します。
4. 3D セキュアのプロセスの開始中に問題が発生します。これは、カードが 3DS に対応していない、処理のエラー、カード発行会社の 3D セキュアサーバーがダウンしているなど、さまざまな理由で発生する可能性があります。
5. 3DS が正常に完了しなかった場合でも、続行して、認証なしで最終的な支払いを試みます。これにより、支払いの結果に応じて、PaymentIntent のステータスが succeeded、requires_capture または requires_payment_method に移行します。

すぐに支払いをブロックしたり、エラーを返したりせずにこうしたことを試行する理由は、コンバージョンの実現のために最適化することを選択しているからです。

このフォールバックの支払いが失敗した場合は、PaymentIntent のステータスが requires_payment_method に更新されます。このフォールバックの支払いが成功した場合は、payment_method_details.card.three_d_secure.result で当該のフォールバックの支払いのステータスが attempt_acknowledged になっていない限り、支払いはライアビリティシフトでカバーされません。

認証されていない支払いとライアビリティシフトの詳細については、Radar for Fraud Teams による、ライアビリティシフトの対象とならない支払いの防止を参照してください。