#rikless
1 messages · Page 1 of 1 (latest)
Hi there!
That refund ID does exist, but it's on a different Stripe account.
yes but the standard account is connected on our platform
Then you need to use the Stripe-Account header as explained here: https://stripe.com/docs/connect/authentication
I don't see that in our logs so there must be an issue. Can you share your full code that makes this request?
$account_id = $notification['account'] ?? null;
$obj = (new $class)->retrieve(
$notification['data']['object']['id'],
['stripe_account' => $account_id]
);
where $notification is the webhook request
And this code created the request ID you shared earlier? req_jGfckVVt2HPxc4?
Hi there 👋 I'm jumping in as my teammate needs to step away, please bear with me a moment while I catch up on the context here.
Hi Toby
I checked that request as well, and am not seeing a Connected Account's ID on it. Have you tried making another request since then that I could double check? Additionally, have you tried logging account_id before that request is made to ensure it's being set as expected?
another request on this connected account ?
No, didn't logged it because if i'm not wrong, that id is sent from Stripe webhook
I would recommend checking to see if that parameter is getting set then. What I'm gathering is that you're building a flow which listens for webhook events and then makes request(s) based on the information contained within those webhook events.
Is $notification being populated by the constructEvent function?
mmmh no, what we only do is : ```php
(array) json_decode(Request::getContent(), true)
and we can see the request here, where account is populated
pretty strange, it looks like a new try has been done for the event, and all was ok
actually not
Can you elaborate on what you're seeing?
I've seen a retry, with the same error
What I don't understand is that it looks like I receive 2 identical notification in the same time
I can see both here https://dashboard.stripe.com/events/evt_3Lnx1bC4QTOJGsXo1j0TRZep
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
It does look that event was sent to that endpoint multiple times. Looking at the logs, we encountered a 500 response from your server for the first delivery attempt, so it is expected that we would queue that event to be resent. Any status outside of the 2XX range is interpreted as the event failing to be delivered, so we try to send it again until you tell us that your server successfully received the event (or the retry period is exhausted).
I know this, but it does not explain why I revieve the same event 2 times at the same time
They were ~17 seconds apart