#scif0642
silk archBOT
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- scif0642, 2 days ago, 3 messages
feral fern
Invoice in_1OAlH4ChMfoWHRa7fp6PDSiP was created during subscription creation https://dashboard.stripe.com/test/logs/req_djRvC1ViMdXtrb , and that's why its billing_reason is subscription_create
What made you think it should be subscription_update instead?
undone beacon
It WAS delivered with this reason
My application has ignored it because of that reason and I started to dig. Eventually I found this discrepancy
feral fern
I don't see any discrepancy here, can you tell me why do you expect the first invoice to have billing_reason=subscription_update ?
feral fern
No, based on what I saw in your log, it's subscription_create
undone beacon
I would expect that as well but as you can see even req_id differs to one you supplied
Could this happen because of old api_version?
feral fern
I don't think so
Let me take a look at your Dashboard again
I checked your log again, it's still subscription_create
undone beacon
Thanks for your efforts but I don't really undertand why are you trying to convince me 😦
The request id differs to one provided by you in first place
I log ALL events coming from Stripe so I can show this request in full
And it does have value subscription_update
feral fern
The request ID that I provided is subscription creation, I just want to show you the first invoice ID that the subscription create.
The request ID in your screenshot is for payment confirmation.
Based on the current information and your logs, I don't see subscription_update in evt_1OAlHaChMfoWHRa7yny48bhk
undone beacon
But you don't see the actual payload which was delivered to my EP
One more time — I was expecting to see subscription_create. And the reason why I started investigation is my app has not shown the payment came trough. Once I checked raw data delivered by Stripe to my webhook handling endpoint, I figured out that reason was subscription_update. I checked that event and raised that question because of discrepancy
feral fern
I noticed something, the event was sent to two webhook endpoints, I was checking one of them and it has subscription_create, but the other one has billing_reason=subscription_update
It's my oversight, sorry about that, you are right, your endpoint did receive a event with billing_reason=subscription_update
This is going to require a bit more investigation. Sorry to redirect you, but can you write in to https://support.stripe.com/contact/email with the information. We'll respond via email/ticket after looking into it further.
undone beacon
Ok, thanks, I will create a ticket, but could you advise how I can see (and prove) the fact that a webhook was delivered?
feral fern
You don't need to prove, Stripe engineers can verify it.
undone beacon
I can see only this state
feral fern
we have internal records to see more information about the webhook event.
undone beacon
Can I refer to particular webhook event sent to me with a some id?
"idempotency_key": "f57def7a-a799-47ab-af14-dd25bde97191" ?
feral fern
You just need to share the webhook event ID