フォールバックに成功した支払いであっても、3DS を完了していなければ、ライアビリティシフトの対象とはなりません。例外として、payment_method_details.card.three_d_secure.result
のステータスが attempt_acknowledged
であるフォールバック支払いはライアビリティシフトの対象となります。
ライアビリティシフトの対象とならない支払いが成功しないようにしたい場合は、Radar for Fraud Teams を利用できます。次のような対策をお勧めします。
API を使ってすべての支払いで 3DS をリクエストし、3D セキュアソースを確認する。支払いで 3DS をリクエストするには、API による支払いの作成時に request_three_d_secure: any を設定します。この設定を行った後、次の Radar ルールを使用できます。Block if not :is_3d_secure: and not :is_off_session:
このようにしても、継続的なサブスクリプションの支払い (免除がリクエストされる) は引き続き成功し、オンセッション支払いが認証されているかどうかが確認されます。加盟店が Apple Pay / Google Pay を受け付けている場合は、このルールを次のように変更する必要があります。Block if not :is_3d_secure: and not :is_off_session: and :digital_wallet: != 'apple_pay'
and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)
このようにする必要があるのは、Stripe が Apple Pay カードで 3DS を許可しておらず (Apple Pay はヨーロッパでのみライアビリティシフトに対応しています)、Google Pay カードについても、トークン化の際に暗号が送信された場合は 3DS を許可していないためです (その理由で :has_cryptogram:
を確認しています)。
Radar を使って 3DS をリクエストし、3D セキュアソースを確認する。API による支払いの作成時に 3DS をリクエストする代わりに、Radar を使って 3DS をリクエストできます。この場合は、3DS が必要なすべての支払いで設定するカスタムメタデータ属性 (たとえば foo: bar
) を選択します。その後は、次の Radar ルールにより、このメタデータを確認して 3DS をリクエストする処理を実行できます。Request 3D Secure if ::foo:: = 'bar'
次に、3DS をリクエストする条件を満たす支払いで 3DS が実行されたかどうかを確認する Radar ルールを追加できます。Block if ::foo:: = 'bar' and not :is_3d_secure:
Apple Pay / Google Pay の支払いを処理する場合は、Radar ルールを次のようにする必要があります。Block if ::foo:: = 'bar' and not :is_3d_secure: and :digital_wallet: != 'apple_pay' and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)