#denjaland - Terminal

1 messages · Page 1 of 1 (latest)

fiery agate
wild trellis
#

sorry I made a mistake in the screenshot: this is the right data we get returned:

unknown.png
#

It's very strange data to see amount_refunded > amount_captured...

fiery agate
#

Hi 👋 There is a lot of context here and it's super busy. Give me a minute to read up

wild trellis
#

take your time - you have other impatient customers 😉

#

to summarise my question: I'd like to be 100% sure that any uncaptured amount is always included in the refunded amount for a charge.

fiery agate
#

Okay...So to summarize, any amount not captured is returned to the customer.

wild trellis
#

yes that is what I understand

#

I'm just tryuing to understand how the attributes for a charge object work together

#

like I can have amount = 100, amount_captured = 50 and amount_refunded = 60

#

so is the 60 always the 50 uncaptured + 10 additional refund?

fiery agate
wild trellis
#

yes- I understand the flow - I also understand what I do

#

but how should I interpret amount_refunded on a charge object

#

does it always include the uncaptured amount on the charge?

#

in other words

#

if I have a charge with amount_captured > 0

#

can I safely calculate the "amount paid" as being amount - amount_refunded?

#

it's a bit weird that I need to implement an IF in my logic, hence my question 😉

fiery agate
#

So...from what I have seen in my testing (going back to your initial question) here is how I see it:

  1. Create payment for 100 EUR (not yours, yet)
  2. Capture 50 EUR (now you have 50, customer gets 50 refunded)
  3. You refund 10 EUR - you can only refund from the 50 you captured. So this is added to the other 50 EUR refunded due to the capture.
wild trellis
#

Yes but you are not answering my question 😉

#

The question is: can we be 100% sure that the uncaptired amoung is ALWAYS included in the refunded amoung?

fiery agate
#

Partially capturing automatically releases the remaining amount.

#

From the doc I linked

wild trellis
#

Again: I jnderstand that but you don’t confirm my suestuin

#

Releasing a hold is not the same as refunding for me

#

You are putting it ibto the refunded amount ALWAYS?

fiery agate
#

Okay, what have you tested?

wild trellis
#

you have the test case above. What I need / want to know is whether or not an uncaptured amount is always considered "refunded" in your terminology

#

surely you can see the strange numbers now

#

so what I need from you is confirmation that

#

to know what the "net amount remaining and okay to be considered as paid for our busienss" I should apply this logic:

IF amount_captured = 0 THEN 0
ELSE amount - amount_refunded

fiery agate
#

And when you performed this test, what was the end result on your end?

#

Do you have the Payment Intent ID for this test?

wild trellis
#

it's literally what I sent you above...
amount = 100; amount_captured = 50 and amount_refunded = 60

#

I feel like you don't underatdn my question TBH

fiery agate
#

The question is: can we be 100% sure that the uncaptired amoung is ALWAYS included in the refunded amoung?
Yes

wild trellis
#

okay

#

so in order to know the "final amount of the charge"

#

I need to do

#

IF amount_captured = 0 then 0

#

else

fiery agate
#

Which is why I'm asking for the Payment Intent ID

wild trellis
#

amount - amount_refunded

fiery agate
#

Because I can examine a few more related objects to see if we can make this more explicit

wild trellis
#

it's just a generic question - it's not an issue with one particular pi

fiery agate
#

I know, but concrete examples are better to work with