#nancy-e_api
tropic sunBOT
👋 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/1500944847920431324
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
hard mason
Hello! What specific information are you looking for regarding the failure? What makes your current classification too generic?
drifting fossil
So we are going down the list and choosing the first indication of the reason for failure. In this case, the advice_code said try_again_later so we called it a generic decline to try again later. The decline_code indicated that the error was specifically related to insufficient_funds so that would have been a much better signal for us, but we didn't get there because we "found the reason" too early in our precedence, which appears to be incorrect. If you were building a failure-classification service, what would your process be for determining the cause of the failure? Do we look at the PaymentIntent.last_payment_error information or the Charge.outcome information first?
polar birch
Hello
imo the information under last_payment_error would always be part of outcome so it's redundant to look at both.
I'd just look at charge.outcome for code , decline_code and advice_codetype, reason, network_status and advice_code
drifting fossil
And between code and decline_code, is one of these going to give us more granular information all the time? Will they both always be available?
polar birch
sorry I quoted the wrong params above
drifting fossil
Oh so we don't look at the PaymentIntent at all?
polar birch
Correct
drifting fossil
Okay - is there an order between these fields we should look at? Will they all always be available?
polar birch
No specific order, no. And it should be available for cards. For non-card payment methods, you'd want to look at failed charges and see what's available.
drifting fossil
We are only using cards and digital wallets (just Google Pay and Apple Pay, which I believe are treated the same way as cards), so this should be fine.
polar birch
👍
drifting fossil
There's a lot of documentation surrounding decline codes. What is the utility of those if I'm not looking at the PaymentIntent.last_payment_error.code at all?
polar birch
I mean you still can use that. It should also be present on the charge under failure_code param (this won't be part of the outcome hash)
drifting fossil
ah interesting
polar birch
failure_code and failure_message on the charge are "customer friendly" text snippets. Details under outcome are more so for merchants
Depending on who your target audience is, you can choose one or the other
drifting fossil
our target audience is us, the merchant, but we also want to be able to pass a human-readable recommendation to our support team so they know how to respond in order to capture the outstanding funds
polar birch
Charge object would have both
drifting fossil
Okay thank you. I think we can work with this. So many different fields with failure information - it's difficult to know how to follow it to determine what went wrong