#bkrnetic
tender cipherBOT
Hello bkrnetic, 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.
• https://discord.com/channels/841573134531821608/1162305487539281931, 5 days ago, 4 messages
bronze root
As far as I know it wasn't the case with previous api versions.
restive wren
failure_reason is populated when the refund fails. So at creation, failure_reason would always be null
Not sure I understand the usecase
bronze root
It is not present in the response.
restive wren
what API version are you on?
restive wren
does it show if you try and retrieve it again?
bronze root
It doesn't
restive wren
Interesting.. Not aware of any recent changes to this field
looking
bronze root
Okey thanks. I will use nullsafe operator just for storing it to DB. Looking forward to hear back from you.
tender cipherBOT
marble heath
to be clear that refund has not failed, so there is no failure_reason to return. But I looked and I think our implemetation for this field is a little unusual, since usually we return the JSON key and set it to null in that case, but for that specific field on the Refund obect it's implemented to omit the key entirely if it's null. Sorry for the hassle.
bronze root
I assumed so. However it wasn’t the case on my previous implementation of the refund flow in the other project.
Thanks for the clarification.
marble heath
hmm, can you expand on that?