#piercy

1 messages ยท Page 1 of 1 (latest)

naive ivyBOT
#

Hello! 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.

  • piercy, 16 minutes ago, 4 messages
latent lake
#

๐Ÿ‘‹ happy to help

#

Also looking at the postman workspace charges still exists in the response but the library doesnt recognise it.
this depends on which API version the code is running

#

How am i supposed to do payment_intent.charges now , latest_charge only returns one?
if you only need the latest charge then you would only need to use latest_charge

warm marsh
#

๐Ÿ˜ญ That's going to be quite the change. An expand option for this would have been nice to not have to change too much of the code

latent lake
#

unfortunately that's not how it ended up being implemented

#

since in most cases there was only one charge per payment intent

warm marsh
#

yeah, ill see what I can do. That might be true for most cases but unfortunately doesn't reflect the reality that it can and does happen.

The problem I have is that a lot of this stuff goes through mapping processes to map the stripe objects to something more friendly for us. The problem now is that we don't really want API calls inside our mapping functions. So everywhere that is mapping that will now need to change

Depending on how much work this is, it might be a blocker for us moving to a newer api verison .

latent lake
#

The problem I have is that a lot of this stuff goes through mapping processes to map the stripe objects to something more friendly for us. The problem now is that we don't really want API calls inside our mapping functions. So everywhere that is mapping that will now need to change
why are you mapping to charges?

warm marsh
#

We're looking for source transactions and other things inside there

latent lake
#

when using PaymentIntents, they should be the point of reference to you

latent lake
warm marsh
#

well they could be multiple things, so theres source transaction, but there could also be transfers if memory serves me

latent lake
#

yes but again, latest_charge should be enough for that

#

I don't think you're doing multi-partial-captures

#

right?

warm marsh
#

Our scenario deals with fees to multiple bodys:

Something like:

Account A takes payment
They need to transfer money to Account B and Account C

So for this PI 3 things have happened, which I think all exist inside the charges object, unless I am mistaken.. just trying to follow the code through to understand it

latent lake
#

that has nothing to do with charges though

#

to be more specific I mean you don't need a list of charges

#

the latest_charge is enough

#

in all cases I guess in your old implementation you were doing payment_intent.charges.data[0], isn't that the case?

warm marsh
#

In some cases, those are the easy ones.

I have a couple examples where we are looking for a specific id inside charges. I am just trying to understand why we do that.

I think, but not 100% sure as I am still reading it through. One of the examples is in the case of a refund.

Using the above example, A needing to pay B and C. If a refund happens, A needs to reverse those transfers, so then needs to go back through the charges to find the info.

I am just reading it more and maybe latest_charge is ok.. transfers are complex (and not my prefferred way to do this, were phasing it out but older customers...)