#piercy
1 messages ยท Page 1 of 1 (latest)
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
๐ 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 uselatest_charge
otherwise you can list all charges filtered by PaymentIntent ID https://stripe.com/docs/api/charges/list#list_charges-payment_intent
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
๐ญ 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
unfortunately that's not how it ended up being implemented
since in most cases there was only one charge per payment intent
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 .
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?
We're looking for source transactions and other things inside there
when using PaymentIntents, they should be the point of reference to you
then the latest_charge should be enough though right?
well they could be multiple things, so theres source transaction, but there could also be transfers if memory serves me
yes but again, latest_charge should be enough for that
I don't think you're doing multi-partial-captures
right?
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
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?
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...)