alessio_webhooks

[weak goblet]

👋 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/1239702693241688156

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[mystic hedge]

Hi 👋

Do you have an ID of a payment intent that was partially captured that I can take a look at?

[whole elbow]

I do, but the event is older than 30 days so I can't verify it on Stripe's dashboard. I was just looking at out Cloudwatch logs when I noticed this.

Just one second please

re_3P1Wb2IDB6WEEZZk0NEsRQeB refund generated by a partially captured PI (received on the charge.refund.updated handler)
pi_3P1Wb2IDB6WEEZZk0XG3qVuX partially captured PI

I cannot find any charge.refunded event on that day

[unkempt barn]

Hi there 👋 taking over, as my colleague needs to step away

Give me a few minutes to get caught up.

[whole elbow]

Sure, in the meantime I double checked an internal note that I found in our code

        // Stripe generates this event in two cases:
        // - A PaymentIntent is captured and then later refunded or partially refunded by a
        //   Charge.Create API invocation
        // - A PaymentIntent is canceled before being captured, but after being authorized.
        //
        // Stripe does not generate this event if a PaymentIntent is only partially captured.

And it looks like that is correct, but only for sandbox events

This is a PI I just created in test mode pi_3PG7PwIDB6WEEZZk198iQk6L and it has not generated any charge.refund.updated, which explains why there is this inconsistency in our billing records

If you can confirm to me that charge.refund.updated will actually always exist in production mode, I will fix our code accordingly, this would actually make things much easier on our side

[unkempt barn]

I think that the difference in what your notes indicate versus the way it works is that a Payment Intent that's fully captured and then refunded would result in charge.refunded, whereas we only send charge.refund.updated for uncaptured Payment Intents and certain transactions where an ARN is generated.

Mostly, I would not rely on that webhook event to be present in all cases.

[whole elbow]

whereas we only send charge.refund.updated for uncaptured Payment Intents
This is true every time a PI is partially captured after being authorized though, or am I missing something?

[unkempt barn]

Correct

[whole elbow]

But there a circumstances in which a captured PI can be refunded (by creating a Refund object) which will only trigger a charge.refunded event?

[unkempt barn]

As far as I know, yes

[whole elbow]

I see. Thank you!

[unkempt barn]

Sure thing!

[whole elbow]

Have a nice day!