#ricoswann_webhooks

1 messages · Page 1 of 1 (latest)

sick bloomBOT
#

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

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

buoyant aurora
#

The event listed here is one of several refund.updated events that have not been sent to our webhook within normal time parameters. And we are stuck in an odd state because of this with several refunds.

sacred ginkgo
#

Hello
Depending on your usecase, you only need to listen to one event.
charge.refund.updated event was send because the ARN was updated -

    destination_details: {
      card: {
        reference_status: "pending",
        reference: null
      }
    }
  }```

`charge.refunded` was generated when the refund was actually created.
#

ARN is generated async

buoyant aurora
#

Yes. we could listen to charge refunded, but it does not include the actual refund in the webhook payload, which we need.

#

of course that would also require a code change and deployment, and we haven't had this issue before. Is stripe experiencing longer update times in these situations now?

sacred ginkgo
#

One to your account and on to the Platform's endpoint listening to Connect events
we_1NUsQZGnuktvs6vKZf2OABzt is on a 2020 API version. If you look at the payload, refund is included.

#

Is stripe experiencing longer update times in these situations now?
I'm not sure but our general recommendation is to never rely on webhook events for synchronous operations

buoyant aurora
#

I mean, it doesn't have to be synchronous, but 6 hours later is really slow.

#

To be clear, it is not directly synchronous.

#

There is no refund or refund ID in the payload. To clarify, will charge just be a "refund" charge associated with the refund, or will it be a the orignal payment.

sacred ginkgo
#

There is no refund or refund ID in the payload. To clarify, will charge just be a "refund" charge associated with the refund, or will it be a the orignal payment.
I think you're looking at the wrong UI

If you look under webhook attempts to platforms section, refund object is there

Screenshot_2025-10-03_at_3.23.13_PM.png Screenshot_2025-10-03_at_3.23.31_PM.png
buoyant aurora
#

ok, I was looking at the event itself

sacred ginkgo
#

Yup, the actual payload might be different based on the API version associated with the webhook endpoint

buoyant aurora
#

ok

#

can you confirm that we will always receive this event in the case of a refund success?

sacred ginkgo
#

charge.refunded is sent whenever refund is created. If the refund fails after it's been created then you'd receive charge.refund.updated event. Like you're currently receiving the ARN

buoyant aurora
#

So I don't see it under webhooks, is that related to the api version that I have selected in my UI?

#

Meaning I still dont' see the refund data

sacred ginkgo
#

Are you looking at the Platform webhook endpoint or the direct webhook endpoint?

buoyant aurora
#

I went to platform webhooks and event deliveries under that. is there a different place I should be looking?

#

We're also on a pretty old version of the SDK...it won't even let me select it in the event dropdown...so not sure what it supports.

#

Sorry, I mean newer SDK, older API

sacred ginkgo
#

Sorry, I'm not sure I follow..

buoyant aurora
#

Not sure I understand how this works. But our "default" API version is pretty old, but I see activity against several API versions.

#

Trying to make sure I understand which API version we are associated with from the perspective of webhooks and what we will get.

sacred ginkgo
#

Your account API version might be different than the one associated with your webhooks as you may have created the webhooks with a specific version. Also in the newer SDKs, we pin the API version 😅

But esentially, shape of the payload is decided by the API version that's associated with the particular endpoint.

Like we_1NUsQZGnuktvs6vKZf2OABzt is on 2020 API version. The others may have a different version associated.

buoyant aurora
#

OK. And when you say the refund payload should be present, where are you looking. Obviously I'm in the wrong place.

sacred ginkgo
#

under charge.refunded event delivery that was sent to - we_1NUsQZGnuktvs6vKZf2OABzt
just to clarify, that endpoint is created and owned by Hubspot

So are you part of Hubspot account? OR are you looking at the dashboard in getskimmer account?

buoyant aurora
#

GetSkimmer

#

got it..that's probably newer.

#

When we added our hubspot integration

#

How would i go about updatin the API version on the webhook?

sacred ginkgo
#

Gotcha. So you're looking at the platform webhook endpoint.

HubSpot webhook endpoint is on an older API version.
GetSkimmer webhook endpoint is on a newer API version - we_1MMHObG3ZxgN8JF7OZFYyWE4 - 2022-11-15

So you won't be able to see refunds on the payload that's delivered to the endpoint with the newer API version.. You'd need to do - #1423763419638796428 message

#

How would i go about updatin the API version on the webhook?
do you mean downgrade?

#

I don't think we allow updating the API version of the webhook endpoint once it's been created. The only option is to re-create the endpoint with the specific event types and the API version. You can use the same URL.

buoyant aurora
#

No, I figured it was the opposite....don't want to downgrade

sacred ginkgo
#

Ah gotcha.

#

once you recieve charge.refunded, make an API call to retrieve that ch_xxx and expand refunds

buoyant aurora
#

Yeah, that's what I figured. OK. I don't want to take any more of yoru time. Appreciate the help.