#mark-reckard_webhooks

1 messages · Page 1 of 1 (latest)

tough bridgeBOT
#

đź‘‹ 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/1367936525257543791

đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.

shut wraith
inner garden
#

ok gotcha. So in production, when we submit a refund for a BACS payment, the refund will exist in pending status. it might take days for the charge to succeed like normal, but then when it does, the refund will process and the update the status to succeeded.

#

Also when the original payment fails, the docs indicate that the refund will be marked as cancelled. Does that emit a refund.updated event as well, or refund.failed, or some other event?

shut wraith
inner garden
#

For asynchronous payments, we can initiate a refund in pending state while the initial charge itself is pending.

#

you can see an example at the payment intent i linked pi_3RJySOCMpnBh61hX0V5q23b8

shut wraith
#

That example shows that the payment succeeded, and then you refunded it

inner garden
#

That will be helpful information when we expand into US Bank accounts, but for now we're focusing on BACS specifically. I'm wondering about the event emitted when the original payment fails because we've already surfaced a bug in this Discord around that behavior. When a payment should be destined to fail in test mode, if you issue a refund it transitions the payment to successful unexpectedly.

inner garden
shut wraith
#

It looks like what my teammate shared is a quick in test mode behavior.

inner garden
#

Ok. So it seems like instead of being able to rely on test mode in this case, we'll just need to test payments and refunds with real money in production to confirm which events are fired when a payment fails and a refund is pending on that payment?

shut wraith
#

On this payment method, you should not be able to create a refund cancel as the payment is in 'pending' status. When the payment fails, you would get 'payment_failed' event.

inner garden
#

Hmm, that's not how we've read this:

Refunds are processed only after the payment process is complete. If you create a full or partial refund on a payment that hasn’t completed yet, the refund process starts when the Charge object’s status transitions to succeeded. If the Charge object’s status transitions to failed, the full or partial refund is marked as canceled because the money was never debited from the customer’s bank account.
And that's also not how the API has behaved. We've been able to initiate refunds on pending payments. It sounds like a refund can be created on pending payment, but that the process starts when the charge succeeds, which is all pretty much what we've seen in test mode for success. But for failure, the refund will exist still and it will "be marked as cancelled", which I assume will change its status, so maybe we'll just listen to the refund.failed event.

shut wraith
#

I might be remembering some other edge case then. Let me confirm this .

inner garden
#

Thank you!

shut wraith