#oleksii_best-practices

1 messages · Page 1 of 1 (latest)

vestal lindenBOT
#

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

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

whole matrix
#

👋 Hi there! Let me take a look

broken flint
#

what is the usual time in US?

whole matrix
#

Sorry, I don't know how long it normally takes. And I think it would depend on which bank the card belongs to

broken flint
#

so after we created a refund we must do an asynchronous polling until reference_status becomes not pending, right?

whole matrix
#

You can, or you can listen for refund.updated events

broken flint
#

we cannot use webhooks.

#

ok. I'm testing refunds on my sandbox account with stripe test bank. API says that if refund is initialized shortly after a payment its type can be "reversal". But every refund I made has type "refund". Is it because of sandbox or test bank? How can I get refund with type "reversal"?

image.png
whole matrix
#

Yes, I think that it's probably because of testmode

vestal lindenBOT
broken flint
#

is there a way to get a refund with type "reversal" in testmode?

spare vessel
#

hey there 👋 I'm afraid that's not possible directly

whether a refund is a "reversal" or not, in live mode, depends on whether the transaction has been captured fully, or merely authorised, by Stripe, on the acquiring side

since no actual fund movement happens in test mode, this same distinction doesn't apply

the closest user-facing way to achieve a similar result in test mode is to create an uncaptured payment (i.e. capture_method: 'manual'), and then cancel this resulting PaymentIntent: https://docs.stripe.com/api/payment_intents/cancel

but this will not create a Refund object, so technically, there's no "reversal" - just a cancelled authorisation (which is basically the same thing in reality, but in the API there's no Refund object: re_1234)

broken flint
#

thanks. I found here that refund with ststus "succeded" can then become "failed". How will reference_status change in that situation?

spare vessel
#

not sure off the top of my head but checking into it

are you asking specifically about card payments, or are you also thinking in the context of other payment methods like ACH?

#

in most failure scenarios, the reference_status property is set to "unavailable"

broken flint
#

mostly for card payments

#

as I understand even if refund status is "succeeded" the reference_status can be "pending", right?

spare vessel
#

yes

in most cases the reference number (ARN) isn't generated until the refund succeeds, so what you'll usually see is reference_status=pending up until the reference itself is populated (i.e. when the bank confirms receipt of the refund)

but I'm speaking very broadly here, because there can be edge cases and different behaviours across different payment method types

broken flint
#

but it is true for card payments, right?

spare vessel
#

yes, it's possible to have status=succeeded and reference_status=pending with cards

vestal lindenBOT