#NewtReyes

1 messages ยท Page 1 of 1 (latest)

sturdy zodiacBOT
zinc dome
#

Hey, it looks like you've had 4 threads in the last few hours that have not had replies. Can you confirm you're getting thread messages?

steep glade
#

Yeah, it was bad luck

#

I got into other stuff and then when back, the threads were closed

#

although they were only 2 threads as far as I can tell

#

Or maybe they were 4

#

Not sure

#

Sorry about that

#

I've been reading the messages but keep getting pulled in different directions

#

and sometimes I was able to figure things out myself

zinc dome
#

Ah, okay. Just wanted to make sure we were hurling answers into the void.

Okay, onto your question: an Application Fee Refund should have a Balance Transaction object attached to it (see here: https://stripe.com/docs/api/fee_refunds/object#fee_refund_object-balance_transaction)

steep glade
#

Yes, and I can see it

#

Ex.

#

Ex.

zinc dome
#

Expand the source field

steep glade
#

Am I missing something?

zinc dome
#

What's in the source field of the object in your last screenshot?

steep glade
zinc dome
#

Okay, so the source is a Charge object. It looks like it has an Application Fee ID in it. When you retrieve that, does it give you the Application Fee object you're looking for?

steep glade
#

look into source.application_fee.refunds.data[0].balance_transaction

#

that's the same txn_1M7MqwIJwkxnVmNV1tRL4qTE as returned here:

#

but source.application_fee.refunds.data is listing both application fee refunds.

zinc dome
#

I'm not following. Where's the issue here?

steep glade
#

as far as I can tell, there is nothing that links txn_1M7MqvRLMLVyikfkXg7krfgQ (transaction id as returned by https://api.stripe.com/v1/balance_transactions) and txn_1M7MqwIJwkxnVmNV1tRL4qTE (transaction id attached for the application fee refund)

#

Am I missing something?

#

txn_1M7MqvRLMLVyikfkXg7krfgQ should be linked to txn_1M7MqwIJwkxnVmNV1tRL4qTE. But according to that, it is linked to txn_1M7MqwIJwkxnVmNV1tRL4qTE and txn_1M7MqaIJwkxnVmNVYrSejfa9

#

Now txn_1M7MqvRLMLVyikfkXg7krfgQ and txn_1M7MqwIJwkxnVmNV1tRL4qTE have the same amount and that is why I can tell that they represent the same fee refund. But txn_1M7MqaIJwkxnVmNVYrSejfa9 has a different amount, so I can tell that it doesn't represent the same fee refund.

#

In that last image, txn_1M7MqvRLMLVyikfkXg7krfgQ represents txn_1M7MqwIJwkxnVmNV1tRL4qTE because the amounts match. But it doesn't represent txn_1M7MqaIJwkxnVmNVYrSejfa9 because the amounts don't match.

#

So among the refunds that I am getting, how can I tell which one is the one that represents the balance transaction I am getting? Because it doesn't represent both of them, just one.

#

So, I don't see a reliable way to go from fr_1M7MqvRLMLVyikfkiSDt0B7K to txn_1M7MqvRLMLVyikfkXg7krfgQ

#

Here's the other balance transaction that represents the other fee refund:

zinc dome
#

These screenshots are not helpful, please post code in the form of a .txt that I can collapse rather than rapid fire screenshots of the same information. You say these objects are "linked", but you don't seem to know what relationship they have other than being of the same amount.

The two transactions you listed are on entirely different objects. One represents a fee_refund (txn_1M7MqwIJwkxnVmNV1tRL4qTE) that is going to the platform, and one represents an adjustment (txn_1M7MqvRLMLVyikfkXg7krfgQ) that is being made on the platform's connected account.

You shouldn't be using amount to link things. I gave multiple detailed ways to link transactions via their properties. Please re-read my message about the relationship between Refunds --> Charges --> Application Fees --> Application Fee Refunds below

It seems like you would need to work backward from the Refund object to get the Charge ID, then retrieve the Charge object to get the Application Fee ID, then use the Application Fee ID to retrieve the Application Fee object and look at the refunded boolean field to see if it has been refunded and get the amount_refunded field if you're simply looking for that. Otherwise, if you really need the actual Application Fee refund object, then I think you would need to look at the refunds hash on the Application Fee object to find the Application Fee Refund ID to retrieve the Application Fee Refund: https://stripe.com/docs/api/application_fees/object?event_types-payment_intent.payment_failed#application_fee_object-refunds

steep glade
#

So by means of the amounts I can tell that:

  • txn_1M7MqaRLMLVyikfkH4ltjR6H -> fr_1M7MqaRLMLVyikfk1K4k2Glo
  • txn_1M7MqvRLMLVyikfkXg7krfgQ -> txn_1M7MqwIJwkxnVmNV1tRL4qTE

Is there any other way to get to that conclusion?

#

You shouldn't be using amount to link things.

Yeah, I know

zinc dome
#

Please carefully read my message before responding with more questions. This is complicated already, so we need to tackle one thing at a time

steep glade
#

It seems like you would need to work backward from the Refund object to get the Charge ID, then retrieve the Charge object to get the Application Fee ID, then use the Application Fee ID to retrieve the Application Fee object and look at the refunded boolean field to see if it has been refunded and get the amount_refunded field if you're simply looking for that.

I have this working already.

#

Does that make sense?

zinc dome
#

I'm still not following, what does this mean? Please use the specific object names (e.g. "I need to match a Balance Transaction with its' corresponding Application Fee Refund").

Your sentence above basically says "I got the Balance Transaction from the Balance Transaction API, is there a way to match the Balance Transaction with the Balance Transaction that I got from the Balance Transaction API?" and I have no idea what that means or what you're looking for.

steep glade
#

btw, thank you for all your help

#

I know this is complicated and more so, I may be missing something silly here and making things more complicated for the both of us.

#

My phrase should be read as: "I got the Balance Transaction from the Balance Transaction API, is there a way to match the Balance Transaction from the Balance Transaction API, with the Balance Transaction that I got from the fee refund object?"

#

I am getting the fee refund object from the charge object (charge->application_fee->refunds->data)

zinc dome
zinc dome
#

So the Application Fee Refund object in your screenshot has a Balance Transaction in it. Why isn't this nested Balance Transaction the one that you're looking for? What are you actually trying to do with all of this?

steep glade
#

Good question

#

Here's why that's not enough: we are using https://api.stripe.com/v1/balance_transactions to synchronize an external system with stripe. We retrieve all the latest balance transactions since the last synchronization and then we match those balance transactions with their corresponding stripe objects already saved in this external system. If any object is missing, it gets created. If it's there already, then we updated it with the latest information from Stripe.

#

So, we are storing fee refunds in this external system and we were expecting to see balance transactions for those fee refunds as we see for charges, refunds, transfers, transfer reversals, etc.

zinc dome
#

Ahhhhhh, okay

steep glade
#

๐Ÿ™‚

#

In this example, we applied two partial refunds to a charge and we refunded the application fee in both cases. So, we got 2 fee refunds.

#

And we can see them in the charge object. So far so good

#

They even have their corresponding balance transactions as expected.

#

But then, when using https://api.stripe.com/v1/balance_transactions, what we see coming is not matching those balance transactions that we saw attached to the fee refunds. We can tell because of the amounts which ones are the ones related to those fee refunds, but we haven't been able to find a reliable way to match those.

#

Hopefully, I make more sense now

zinc dome
#

So you're querying a mass list of Balance Transactions and you're finding the ones with corresponding amounts to verify a relationship. I think we may have covered this part already, but can you post the Balance Transaction IDs you're looking at?

steep glade
#

So you're querying a mass list of Balance Transactions and you're finding the ones with corresponding amounts to verify a relationship.

The amount matching is not in the code. I am doing this just for my own understanding.

zinc dome
#

Okay, got it

steep glade
#

txn_1M7MqvRLMLVyikfkXg7krfgQ -> txn_1M7MqwIJwkxnVmNV1tRL4qTE

txn_1M7MqaRLMLVyikfkH4ltjR6H -> txn_1M7MqaIJwkxnVmNVYrSejfa9

zinc dome
#

Okay, so in terms of your own understanding here's the high-level of what's going on.

txn_1M7MqvRLMLVyikfkXg7krfgQ -> txn_1M7MqwIJwkxnVmNV1tRL4qTE
This transaction txn_1M7MqvRLMLVyikfkXg7krfgQ lives on the connected account. It represents the credit to the connected account's balance (e.g. the connected account is getting +$0.64 to their balance).

This transaction txn_1M7MqwIJwkxnVmNV1tRL4qTE lives on the platform's account. It represents the debit to the platform account's balance (e.g. the platform account has -$0.64 from their balance).

Does all that make sense so far?

steep glade
#

This transaction txn_1M7MqvRLMLVyikfkXg7krfgQ lives on the connected account. It represents the credit to the connected account's balance (e.g. the connected account is getting +$0.64 to their balance).

Got it

#

This transaction txn_1M7MqwIJwkxnVmNV1tRL4qTE lives on the platform's account. It represents the debit to the platform account's balance (e.g. the platform account has -$0.64 from their balance).

Yes

#

Does all that make sense so far?

100%

#

Is there a way to match those?

zinc dome
#

Okay cool. Now, knowing that, in order to get to the root of both of those, you need to follow their corresponding source fields back to the Charge object. That is the thing that ultimately connects the two Balance Transactions to each other. So, the pathways of each Balance Transactions source field should look like this:

  • txn_1M7MqvRLMLVyikfkXg7krfgQ (Balance Transaction representing the Application Fee Refund) --> py_abc123 (Payment object) --> tr_abc123 (Transfer object) --> ch_abc123 (originating Charge object)
  • txn_1M7MqwIJwkxnVmNV1tRL4qTE (Balance Transaction representing the Application Fee Refund) --> fr_abc123 (Application Fee Refund object) --> fee_abc123 (Application Fee object) --> ch_abc123 (originating Charge object)

Does that make sense?

steep glade
#

Reviewing

#
  • txn_1M7MqvRLMLVyikfkXg7krfgQ (Balance Transaction representing the Application Fee Refund) --> py_abc123 (Payment object) --> tr_abc123 (Transfer object) --> ch_abc123 (originating Charge object)

This takes me to the originating charge but I am still not seeing how to get from there to txn_1M7MqwIJwkxnVmNV1tRL4qTE. If I follow the next path in reverse (from the charge to the balance transaction) I get to the point where I have 2 application fee refund objects. How do I pick the right one?

zinc dome
#

That's up to you to decide. As I recall, you said that there could be multiple Application Fee Refunds, so you'll have to decide how to store/sync in situations where more than one exists

steep glade
#

I mean txn_1M7MqvRLMLVyikfkXg7krfgQ is related to txn_1M7MqwIJwkxnVmNV1tRL4qTE and not the other one. But the only way I can tell that right now is by means of the amounts.

#

It's not really up to me to decide which one it is related to. But from what I can tell, there seems to be no way to tell that starting from txn_1M7MqvRLMLVyikfkXg7krfgQ

#

Am I missing something here?

last fractal
#

Hi, stepping in for two-shoes as they are away. Let me catch up here

#

Ok, there is a lot of context here, what is the question that is not answered?

steep glade
#

LOL

#

There is

#

That's the key question right now

last fractal
#

What does this mean? How do I pick the right one?

steep glade
#

A simpler way to ask the same question: By means of which path can I find out that txn_1M7MqvRLMLVyikfkXg7krfgQ is related to txn_1M7MqwIJwkxnVmNV1tRL4qTE and not txn_1M7MqaIJwkxnVmNVYrSejfa9?

#

That is the main question

last fractal
#

I see, you'd know this by amount. The amount on the connected account, txn_1M7MqvRLMLVyikfkXg7krfgQ and this amount, txn_1M7MqwIJwkxnVmNV1tRL4qTE on the platform account.

steep glade
#

Yeah

#

But I can't rely on that for the logic

last fractal
steep glade
#

Is that metadata copied to the fee refund?

last fractal
#

From the screenshot you provided, it looks like it. You'd want to test this

steep glade
#

Not working

#

metadata from the refund is not copied to the application fee refund

#

:/

#

Is there a way to map a fee refund to its corresponding refund?

last fractal
#

Hmm, let me try reproducing this on my end. You're trying to see how you can tie one txn_ from on the connected account to tie to the other one on the Platform account.

steep glade
#

Yes!!!

last fractal
#

Is there a way to map an application fee refund to its corresponding refund?

#

Moving this here

steep glade
#

Ok

last fractal
steep glade
#

The fee refund is created when creating the refund

#

I am not creating any application fee refunds manually

#

And as far as I can tell, no application fee refunds have any metadata

#

Only the refunds

frank owl
#

๐Ÿ‘‹ taking over here. You were correct that when creating a Refund (and probably you passed refund_application_fee = true to trigger the application fee refund), the auto-generated application fee refund doesn't have metadata generated automatically

#

One solution is listen to the webhook event to catch when the application fee refund is generated, immediately call a Update Application Fee Refund with the metadata you wish

steep glade
#

Right

#

Although that would be very timing dependant

#

Any other alternatives?

frank owl
#

Only that AFAIK. And to be safe let's also verify the connection by Ids, not just timing

steep glade
#

What do you mean?

#

by account id?

frank owl
#

So the Application Fee Refund coming to webhook has a fee id https://stripe.com/docs/api/fee_refunds/object?lang=ruby#fee_refund_object-fee, you can Retrieve it to expand to the Application Fee object's original charge https://stripe.com/docs/api/application_fees/object?lang=ruby#application_fee_object-charge

steep glade
#

Thank you