#hendie_webhooks
static forgeBOT
đ 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/1357704275462979905
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
mental zealot
hey there, tkaing a look
mild coyote
thx
I had looked at a previous refund, cannot remember the request, where a refund.created as well as a final refund.updated was received. In this test case however, the refund.updated never came. I would prefer to listen for refund.* events in case of doing a refund, rather than charge.refunded.
mental zealot
Looks like the refund was not update after creation, so there is no updated event to send.
mild coyote
So I guess my question is: what is the expected events for such refunds
mental zealot
Was that other refund also for interac_present?
If i recall, the refund succeeds synchronously at the time the card is re-presented to the reader, so there are no further changes expected
mild coyote
ah! you are correct. Previously the refund state upon create was pending. For this one it was succeeded immediately.
I guess I need to look for that state too on the create
mental zealot
I would prefer to listen for refund.* events in case of doing a refund, rather than charge.refunded.
But you do have arefund.createdevent here, right? Additionally, this only happens with explicit action by you to create the refund.
Yea, because of the interac refund flow (requires the card at the reader again) this succeeds or fails immediately
I expect that the pending refund might have been for a different payment method type
mild coyote
well, doesn't the refund get created BEFORE the customer maybe has time to swipe?
so if there's a longer delay between creating an swiping, maybe THEN there would be an update?
mental zealot
well, doesn't the refund get created BEFORE the customer maybe has time to swipe...
It's kind of all bundled together with the collection triggered by the refund flow
https://api.stripe.com/v1/terminal/readers/tmr_xxx/refund_payment
mental zealot
so if there's a longer delay between creating an swiping, maybe THEN there would...
You can test this by cancelling the card collection on the reader
My expectation is that the reader action would fail and the refund would not be created