#dai-developers_docs

1 messages · Page 1 of 1 (latest)

kindred shoalBOT
#

đź‘‹ Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

đź”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1480785282197360812

đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

meager drum
#

I understood that if a card does not support 3DS, the transaction is not eligible for liability shift in case of fraud. Is this correct?
Yup that is correct

#

This can be seen from the document here: https://docs.stripe.com/payments/3d-secure/authentication-flow#disputed-payments

The liability shift rule typically applies to payments successfully authenticated using 3DS.

If a cardholder disputes a 3DS payment as fraudulent, the liability typically shifts from you to the card issuer.

However

If a card doesn’t support 3DS or an error occurs during the authentication process, the payment proceeds normally. When this occurs, liability doesn’t generally shift to the issuer, because a successful 3DS authentication hasn’t taken place.

fluid python
#

In other words, if the PaymentIntent status is requires_capture, my understanding is that this could mean either the frictionless flow succeeded or the card simply does not support 3DS.

And if the card does not support 3DS, completing the payment in that case would mean that even if the transaction is later identified as fraudulent, the liability would not shift to the issuer.

Is my understanding correct?

#

If my understanding is correct, when the PaymentIntent status is requires_capture, I would like to distinguish whether it is because the frictionless flow succeeded or because the card does not support 3DS.

How can I tell the difference between these two cases?

meager drum
#

if the PaymentIntent status is requires_capture, my understanding is that this could mean either the frictionless flow succeeded or the card simply does not support 3DS.
Actually, could i understand how you arrived to this conclusion?

Because the requires_capture status mainly occurs when you’re separately authorising and capturing funds. As seen here:

If you’re separately authorising and capturing funds, your PaymentIntent can instead move to requires_capture. In that case, attempting to capture the funds moves it to processing.
https://docs.stripe.com/payments/paymentintents/lifecycle#processing-pi

fluid python
#

In February 2025, I received the following explanation from email support (support-reply@stripe.com):
"Regarding the test card '378282246310005', as indicated, 3DS is not supported, but it is a card that will result in a successful payment (succeeded or requires_capture)."
Based on this, I understood that when a card does not support 3DS, the PaymentIntent status will be requires_capture.
I also understood that in the case of fraudulent use with a non-3DS card, liability does not shift to the issuer.
Therefore, I believed that when a PaymentIntent is in requires_capture status, there is a possibility that the card does not support 3DS.
If any of these understandings are incorrect, could you please clarify and provide the correct specifications?

#

Actually, could i understand how you arrived to this conclusion?
If the status of the PaymentIntent is requires_capture, does that mean there is no possibility that the card used does not support 3D Secure?

meager drum
fluid python
#

Yes, we have set capture_method: 'manual'.

meager drum
#

Ah I see, so essentially, you are following the separate auth and capture flow. Let me list down what happens in this flow, assuming the frictionless 3DS test card 4000000032200000 was used

TImeline:

  1. Create Payment Intent with capture_method: 'manual'
  2. Confirm Payment Intent via Payment Element with frictionless 3DS test card 4000000032200000 link
  3. Payment Intent will transit to requires_capture status, which means that the payment has been authorise but not yet captured on the customer’s payment method. (I believe this was what Stripe support and my colleague previously meant by Successful transaction/payment. So Successful Payments = Authorised Payments OR Succeeded Payments)
  4. At this point in time, your Payment Intent would have an associated charge object. You can retrieve that Charge from the Payment Intent and search for the field latest_charge.payment_method_details.card.three_d_secure.authentication_flow to see if it has the value "frictionless" or null (3DS not supported)
  5. Capture Payment Intent: To capture the authorised funds, make a PaymentIntent capture request.