#pantelis-tsak_best-practices
nimble oreBOT
👋 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/1363878566067966032
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
rapid musk
Hi, can you share a specific example where you see this please? In case the payment is declined due to 3DS, you should get the authentication failure decline, https://docs.stripe.com/declines/codes
nimble oreBOT
digital delta
Hello, for example I am looking at a customer, the activity on stripe says "3d secure attempt failed" but I did not receive the payment_intent.payment_failed webhook
rapid musk
I should clarify that if the issuing bank send that decline code, we would surface that too.
Can you share that payment id please?
digital delta
Here's the payment id pi_3REYfoLqftC4CYgb0Zai9IHh
The main issue is that we don't have a single 3ds related issue recorded on our MMP
while on the test environment, we do
tired turret
Hi there 👋 I'm jumping in as my teammate needs to step away. Can you also tell us more about how you built your integration?
3DS is handled client-side while your customer is on-session, so typically the client-side code being run at the time that authentication is attempted knows immediately whether 3DS was successfully completed or not. It's usually not something that requires a webhook endpoint to detect, but maybe I'm not grasping when this is happening in your flow.
tired turret
The main issue is that we don't have a single 3ds related issue recorded on our ...
What is MMP?
digital delta
The only recorded codes from that webhook
digital delta
Hi there 👋 I'm jumping in as my teammate needs to step away. Can you also tell ...
Hello, we want a central point to report payment failures so we can report them to external services. If you see on the screenshot above, we do receive some of these errors
digital delta
What is MMP?
Mobile Measurement Partner - an engagement platform
The current implementation uses a webhook with the type payment_intent.payment_failed
tired turret
Mobile Measurement Partner - an engagement platform
This payment wasn't declined due to authorization being required though.
The Payment Intent was confirmed client-side in this request:
https://dashboard.stripe.com/logs/req_m9S4h4elCmfhzh
The intent was returned with a status of requires_action indicating that 3DS needed to be completed. This is what we typically refer to as a soft-decline. The issuer indicates to us that the payment wasn't approved, but that it likely would be with customer authentication, so we put the intent in a requires_action state so 3DS can be triggered.
Then 3DS wasn't completed successfully, and the intent was then canceled in this request when the associated Invoice was voided:
https://dashboard.stripe.com/logs/req_XxPW4bxDncNz8Q
The only time coming to mind when I'd expect you to see an authentication related decline code, would be for a recurring off-session payment (not the first payment for a Subscription, typically, but one of the recurring payments it triggers) failing due to 3DS being required.
digital delta
Ah great thanks
Would you suggest that this should happen on the client side then?
Or a combination of both
to report the decline codes
tired turret
I'm not really sure how to answer that.
The Payment Intent you referenced didn't surface a decline code, so I'm not sure I understand what information you're hoping to pull from intents like this one.
If you're mostly looking to capture the decline codes surfaced when payments fail, then a webhook approach sounds sufficient.
digital delta
So currently we only support payments through subscriptions and the only payment methods we support are cards.
We wanted a single source for reporting the errors, in this case the webhooks
but it seems when testing through the test cards and the real cards there could be some differences in the scenarios
tired turret
Can you elaborate on that last point? What are the differences you're seeing?
digital delta
For example this webhook event pi_3RFdfNLqftC4CYgb0AZHgecS on the test environment reported a code "authentication_required"
tired turret
The only time coming to mind when I'd expect you to see an authentication relate...
That looks like it wasn't the first payment for a Subscription, so it seems like the scenario I was referring to in this previous message, where an off-session payment failed due to 3DS being required.
Are you saying you have an example payment from livemode that went through the same pattern, but that you didn't see a decline code logged for?
digital delta
Probably I am wrong, and it's the case you are saying
So if I understand correctly maybe it's safer to report the decline codes from the client as it can include more sufficient error reporting due to the error being related to the client/bank rather than the stripe itself ?
tired turret
Nope, because the Payment Intent you shared most recently all happened in background. Client-side logging would have no visibility into that intent's lifecycle.
digital delta
Ah ok, maybe I've to rethink the approach or if you have something to suggest let me know, thanks for your time
tired turret
The webhook approach sounds solid to me. Just sounds like you're testing a scenario in testmode that you aren't running into within livemode as well (which I see as a good thing, that means you're doing thorough testing)
digital delta
Thanks for the feedback, have a great rest of the day