#davide_api
silk reefBOT
đ 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/1381999700311544042
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
prime mirage
hey there, taking a look
silk reefBOT
prime mirage
charges are only created if the 3DS is successfull
I don't think this is accurate, so its possible a colleague misunderstood or was mistaken about some detail here.
For example, we can see in the Charge object itself that there exist records of 3DS failures
https://docs.stripe.com/api/charges/object#charge_object-payment_method_details-card-three_d_secure-result
failed
The customer failed 3D Secure authentication.
prime mirage
However I have this example (evt_3RAvvxG0HkO3ZPnp1Vks1t3f) (and many others) where I see "payment_intent_authetication_failure" and there is a charge associated (latest_charge not null). I want to understand why I have an associated charge.
For example, if you retrieve the related charge here from the API, you should hopefully see those details: ch_3RAvvxG0HkO3ZPnp1XytF4Gh
crystal pebble
well if i look at the charge I see a card_declined error
how can i associate it to a 3DS failure?
this is very misleading
prime mirage
With the details i shared above, looking at payment_method_details[card][three_d_secure][result]
prime mirage
this is very misleading
What is misleading?
crystal pebble
three_d_secure
Object
authentication_flow
"challenge"
electronic_commerce_indicator
"02"
exemption_indicator
null
result
"authenticated"
result_reason
null
transaction_id
"af17eb48-c896-4850-89a3-a17fcc264c2b"
version
"2.2.0"
prime mirage
ok so maybe you can explain better how to identify 3DS failures?
Identify in what context, can you explain more about what you're trying to do exactly?
crystal pebble
from the charge it seems that 3DS is successfull!
crystal pebble
Identify in what context, can you explain more about what you're trying to do ex...
please tell me exactly how to identify when a customer fails the 3DS authentication
prime mirage
Yep, in this case the customer passed 3ds, then the issuer declined the transaction, so it was not a 3ds failure
crystal pebble
in the example i shared it seems from the payment_intent that the 3DS is failed; if I look in the charge associated i see the 3DS is authenticated.
then how can i understand what happened??
crystal pebble
then why i see authentication_failure ion the event associated?
can you please clearly tell me how to identify the 3DS failures exactly?
umbral escarp
I am confused, authentication_failure says failure, correct?
crystal pebble
YES!
That's what I'm trying to say: authentication is failure, previously I was told this identifies 3DS failures, now you tell me this customer passed the 3DS and the issuer declined the payment
so I don't understand what happened
and again, PLEASE, can you precisely tell me how to identify 3DS failures?
umbral escarp
So there are two different things that can succeed or fail here, the 3DS process itself and the outcome from the issuer. The 3DS process itself can run in to an issue or it can complete, even when 3DS completes successfully the issuer can still determine that they don't want to approve the transaction.
crystal pebble
ok fine, this is clear. so 1) in this specific example did the 3DS succeed or fail? and again 2) how do i identify 3DS failures in general?
??
umbral escarp
As you noted, the result on that object says authenticated, that means 3DS completed properly. If you are interested in distinguishing between 3DS failing and the charge declining then the field we have been pointing to is the best one to look at. https://docs.stripe.com/api/charges/object#charge_object-payment_method_details-card-three_d_secure-result
I think the confusion here is because the payment intent error from this payment failure is payment_intent_authentication_failure, there authentication failure means an issuer decline. So related a related, similarly named, but separate failure
crystal pebble
Then why the payment_intent says authentication_failure?
when I asked the other time your colleague said I CANNOT see 3DS failure from charges
Unless i manually create a charge with specific fields in the 3DS part
why is the payment_intent failed and the charge not?
how can you say the authentication_failure is not due to the 3DS?
umbral escarp
Unfortunately my colleague was mistaken
crystal pebble
since in the last_payment_error.code i see also card_declined, why don't I see card_declined instead of authentication_failure?
umbral escarp
I will reach out to them to clarify this going forward, we do our best but mistakes can still be made here
crystal pebble
this is NOT clear
crystal pebble
since in the last_payment_error.code i see also card_declined, why don't I see c...
since you are saying that apparently the authentication_failure is due to the issuer
Also, I NEVER saw any 3DS failure related field in the charges
NEVER
umbral escarp
The charge does say it was failed though. If you check status it should say failed and if you check its outcome.type it should show a decline
https://docs.stripe.com/api/charges/object?api-version=2025-05-28.preview#charge_object-outcome-type
crystal pebble
so that actually leds me to think your colleague was right
crystal pebble
The charge does say it was failed though. If you check `status` it should say `f...
but the charge says card_declined!!!!!!!
umbral escarp
I was responding to you saying this
why is the payment_intent failed and the charge not?
The charge did fail and it says it failed, do we both agree on that?
crystal pebble
yes. but I'm interested in understanding if the 3DS failed
don't focus on the charge!
yes or no: did the 3DS fail?
??
hello
can you please reply?
yes or no: did the 3DS fail?
umbral escarp
Hello, on this server we help multiple people at once, and I was also rereading this conversation because information that I thought I communicated clearly was not read as such. It sometimes takes time for replies to happen on this server
Overall I'd recommend only focusing on the error at the payment intent level, at the end of the day the charge succeeded or failed. Some banks will say that 3DS authenticated but the charge declined, some will just say 3DS failed. I do think that the distinction you are trying to make is legitimately confusing in our current API, so I think what would be best here is for you to write in to our support team with full details on what each of these fields is showing for you in the API for the intent and charge here and explaining why you find that confusing.
umbral escarp
Can you post the full json response that you get when you retrieve the charge via the API?
I've said what I can see is on the charge from my side multiple times, but it sounds like that isn't translating to what you are seeing
Oh wait this is a live charge
Never mind
crystal pebble
I am not interested in the chargE!!!!!
crystal pebble
I am interested in the payment_intent error
I want to know if the payment_intent_authentication_failure indicated a 3DS not successfull!!!!!!!
umbral escarp
No it does not
crystal pebble
SO:
umbral escarp
It just means that that specific charge failed in some way
crystal pebble
yes or no: did the 3DS fail?
crystal pebble
then why for some payment_intent_authentication_failure indicated there is no latest_charge associated??????
crystal pebble
That info is on the charge itself
NO IT'S NOT!!!!!
umbral escarp
Ah there we go
Okay so that is also part of what I clarified during the pause: some 3DS failures do generate a charge object that is visible to you and some don't. I am not fully clear behind the design decision there, but sometimes the specific detail at the charge level will not be available to you in that way.
crystal pebble
I said earlier that I NEVER SAW ANY CHARGE WITH 3DS FIELDS WITH FAILURES
umbral escarp
I feel like some of our talking in circles was us thinking the other one was talking about a specific field or object. That is part of why I wanted to see the charge object that you were seeing, because I couldn't see it the exact way you can
crystal pebble
ok fine, let's do this:
you tell me EXACTLY, STEP-BY-STEP how to identify 3DS failures. And don't tell me to look at the three_d_secure field in the charge object
you want the charge associated?
_id
67f2aa33e75bc054637bd9ab
id
"ch_3RAvvxG0HkO3ZPnp1XytF4Gh"
object
"charge"
amount
8907
amount_captured
0
amount_refunded
0
application
null
application_fee
null
application_fee_amount
null
balance_transaction
null
billing_details
Object
calculated_statement_descriptor
"SUBBYX - ABBONAMENTI"
captured
false
created
1743956528
currency
"eur"
customer
"cus_Rbs6GJdNvkzNBZ"
description
null
destination
null
dispute
null
disputed
false
failure_balance_transaction
null
failure_code
"card_declined"
failure_message
"Your card was declined."
fraud_details
Object
invoice
null
livemode
true
metadata
Object
on_behalf_of
null
order
null
outcome
Object
paid
false
payment_intent
"pi_3RAvvxG0HkO3ZPnp157hdtEY"
payment_method
"pm_1RAvvxG0HkO3ZPnpFLsGHDW1"
payment_method_details
Object
card
Object
amount_authorized
null
authorization_code
null
brand
"mastercard"
checks
Object
country
"IT"
description
"Debit MasterCard"
exp_month
11
exp_year
2027
extended_authorization
Object
fingerprint
"Ik5BiYn3hNjILyNw"
funding
"debit"
iin
"534413"
incremental_authorization
Object
installments
null
issuer
"UNICREDIT SPA"
last4
"5781"
mandate
null
moto
null
multicapture
Object
network
"mastercard"
network_token
Object
network_transaction_id
"MDSJMZ3JO0406"
overcapture
Object
regulated_status
"unregulated"
three_d_secure
Object
authentication_flow
"challenge"
electronic_commerce_indicator
"02"
exemption_indicator
null
result
"authenticated"
result_reason
null
transaction_id
"af17eb48-c896-4850-89a3-a17fcc264c2b"
version
"2.2.0"
Show 1 more field in card
type
"card"
radar_options
Object
receipt_email
"mohamedzafer@icloud.com"
receipt_number
null
receipt_url
null
refunded
false
review
null
shipping
null
source
null
source_transfer
null
statement_descriptor
null
statement_descriptor_suffix
null
status
"failed"
transfer_data
null
transfer_group
null
eventTimestamp
1743956529
you want the event?
anyway: please, please, please, please, tell me exactly how to understand 3DS failures. like:
- take all the event with code = "XXX"
- check this and that
- ....
if you are able to do that i can let you go
umbral escarp
Okay, so overall the answer is that you can't always tell when 3DS is specifically the thing that failed. Sometimes a 3DS failure will generate a charge object that you can see, sometimes it won't generate a charge at all. When a charge is present, you can check that result field we've been talking about. When a charge hasn't been generated, you can't get any further detail on what happened with 3DS via the API, you can only tell that the specific attempt at a payment failed somehow and the best place to check for that is the last_payment_error field on the payment intent.
https://docs.stripe.com/api/payment_intents/object#payment_intent_object-last_payment_error
umbral escarp
Correct, unfortunately that info is not surfaced to you in the API at the moment
crystal pebble
I'm also going to paste another screenshot
umbral escarp
You can write in to our support team with feedback around this API design and why it would be helpful for this to be more consistent.
crystal pebble
I definitely will. but you should be more supportive here
I am going home that i haven't understood if and how i will be able to understand what fails or not
still you are able to tell from the dashboard
umbral escarp
We've both tested each other's patience here. I apologize for getting short with you, I am happy to keep speaking to this if you can give me some leeway as well.
crystal pebble
look at those screenshots: you can tell if 3DS fails
umbral escarp
I am going home that i haven't understood if and how i will be able to understand what fails or not
Can you give me a bit more detail on what is ambiguous here?
Correct, that info is available to Stripe and is surfaced via the dashboard but it is not available in our API under some circumstances.
umbral escarp
Unfortunately, I am not privy to our design decisions and cannot speak to them. The dashboard has its own API version that sometimes has access to additional info and it can pull data from other endpoints to have a more complete view of the timeline here.
crystal pebble
> I am going home that i haven't understood if and how i will be able to underst...
everything is pretty ambiguous.
what would you do if you were me?
I need to look for 3DS failures for anti-fraud operations
but if i'm unable to even understand what fails, if fails, and for what reason, well, I can let all scammers come to my website and I'll be bankrupt
because stripe is telling me that i will not always able to understand what i want
nice
umbral escarp
what would you do if you were me?
I would have my code look at the payment intent'slast_payment_error. The anti-fraud decisions have already been made by Stripe and the bank by then. If the payment has failed for either of those reasons, you can tell that the payment failed there and not provision your service because the payment got declined. Right now, that is the best that is possible in our API and that is all that we can consult on on this server. You should absolutely detail how you believe this ambiguity makes you more vulnerable to scammers in your email to our support team. That feedback will absolutely be raised further and that is the best way to raise it to the people who do make design decisions about our API.
If you have further questions on what can currently be coded with our API, I am happy to speak to that. For feedback outside of that, writing to our support really is the best next step.
crystal pebble
Well:
- "The anti-fraud decisions have already been made by Stripe and the bank by then". not true. we had embarked lots of scammers even with those. so we definitely NEED our own anti-fraud engine
- definitely going to contact the support and also attaching this and the previous discussion i had on discord, because I find UNBELIEVABLE and not professional that this is the quality of this service.
you can close this as I need to go. after one hour I know nothing more than when I started this thread.
thanks
bye