#jonathan_needs_help

1 messages · Page 1 of 1 (latest)

tight heronBOT
silk fractal
#

Let's back up for a second - how are you request 3DS on the payment intent? And is this something you want to be checking just for the purposes of a one-off test, or is this something you want to confirm for every payment?

burnt storm
#

Sure, sorry for jumping the gun. 🙂

Currently, we're mostly using Stripe Radar rules to request 3DS for suspicious payments. We are also working on a few internal risk rules where we would always want to manually request 3DS for certain cases. Either way, I think it would be useful for us to maintain a log of if the payment was actually sent through a full 3DS flow just for logging reasons, to potentially feed back into our Risk engine.

silk fractal
#

Are you hoping to check whether 3DS was completed through the API or through Radar?

burnt storm
#

No, more so just to see if it went through the full flow as that would be greater signal that the payment method is being used nonfraudulently, right?

I don't think the manner of how it is requested to begin with matters as much to us -- we'd be able to easily see that since we kick off the request in the first place. We just lose visibility once 3DS is happening due to the inherent redirect.

silk fractal
#

Sorry let me clarify - there are two ways (that I can think of) that you could utilize to check whether a payment went through a full 3DS flow. You could implement a Radar Rule (see https://stripe.com/docs/payments/3d-secure#custom-rules-for-3d-secure-and-liability-shift for inspiration) to block or review payments that haven't gone through 3D secure. Or you could check the Charge from the API to verify whether 3D Secure was run (see https://stripe.com/docs/api/charges/object?event_types-payment_intent.payment_failed#charge_object-payment_method_details-card-three_d_secure)

burnt storm
#

Oh nice! Thanks, the charge one is perfect for us.