#nickdnk_api
spice compassBOT
đź‘‹ 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/1483240637691330660
đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.
tribal rose
Hi there!
mossy ore
Hello
tribal rose
having a look
mossy ore
I just want to make sure this is intentional before I start coding around it
For context:
The one with duplicate is test, the one with only one is live (working env)
(live is separate account)
What's worth pointing out is that "source" is "automatic" for both of the events; I didn't update the payment intent as far as I can tell.
In those few seconds, I only did req_Sd4sQtB2PNG3OX
maybe I should listen for charge.succeeded instead in this particular flow
mossy ore
I mean it looks like it shouldnt need to fire twice
There's nothing going on that changed the PI or the amount capturable
tribal rose
Yeah and there is no previous_attributes in the event body
Which makes the events real duplicates, I think
mossy ore
I think that's intentional; neither of the events have that property, not in the working live version either. evt_3TBj6MGwbovMPuni0bEWqRT4
But I'm thinking your logic is they should have previous attributes: "amount_capturable": 0,
like it has at evt_3TBj6MGwbovMPuni0x2A6md2 (0 amount capturable at that stage)
But regardless, I think I'll move my handler to charge.succeeded and look for "status": "requires_capture" instead of relying on payment_intent.amount_capturable_updated
tribal rose
Yeah I was able to reproduce this but I can't really explain it. I'll likely need to talk to our product team
mossy ore
Can you maybe explain why I'm not seeing it in live? What am I doing differently there?
I mean I know I'm doing a bunch of stuff differently, but I mean what am I doing differnetly with Stripe specifically that causes the duplicate
You can compare the live flow at the event log for acct_1F4QmMGwbovMPuni
It only ever fires once there
tribal rose
What's the payment method on the livemode PaymentIntent? We saw behavior like this around a year ago but it only affected a subset of European payment methods like Revolut Pay and Klarna
even then from the report I read, I don't think we saw it happening 100% of the time
mossy ore
Sec
Looks like mobilepay, this particular one
But I have never seen this duplicate event once in the live env
And it's mixed card, apple pay, mobile pay
The main difference is that it does not use the payment intent secret on the frontend to render available payment methods
It uses a custom payment selector and some odd mix of posting the payment method ID directly to the backend because it uses payment method cloning (standard connect) and creating a payment method on the backend. We're getting rid of that entirely and movign it all to frontend with client secret and async only
But the live env works 100% of the time, is the point
tribal rose
I'm not sure, to be honest. The example you gave in testmode is revolut pay and it is one of the payment method types explicitly implicated in the previous version of this bug
mossy ore
Yeah but you asked what payment method was on the live
tribal rose
That might be part of why you haven't seen it on live - cards/mobilepay might be unaffected
Or it might be a testmode-only bug
mossy ore
Ok
So, given that this appears to be long-standing, I would be looking into a different iomplementatin path
Plan is then charge.succeeded and just retrieve the payment intent. It's quite important the event I work with here only fires once per payment intent
tribal rose
Correction: I don't think it is long-standing. I think we fixed it a little more than a year ago and then we maybe broke it again. So if you would like, I can send you a link with instructions to create a support case and we can keep you updated on what happens with the bug
Because if you want to understand the amount capturable you should listen to this webhook event and it should only fire once and it should just work
mossy ore
Im not really interested in creating a support case for it. To be quite honest, I think you should be the ones to do that if you have confirmed it’s not working as intended. I don’t really have the time to manage this bug; I need it to work right now, so I’ll be working around it immediately with a different event.
Appreciate the insight though
tribal rose
Okay
spice compassBOT
mossy ore
I hope this means you’ll still work on the bug even if it means I won’t receive updates on your progress.