#themacproguy_api
rain troutBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1309222806004699136
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
orchid flicker
You can also cause a very large state discrepancy as a result of this as you can set the customer on the charge to cus_foo and the payment intent to cus_bar (like in those request IDs) and Stripe will accept it and the dashboard will display the customer on the charge, not the intent
fallen hollow
Hi, let me help you with this.
If you're using PaymentIntents you shouldn't need to interact with Charges API directly.
orchid flicker
The issue is a payment intent wont represent the movement of money at the time. IE for ACH, a payment intent could be "created" for days before successful. Theres a lack of timestamps on the intent themselves to where they aren't a direct replacement for charges
For bank rec, the time the movement of money matters and thats what you get with charges and balance transactions.
fallen hollow
I mean, yeah, you might need to fetch the list of Charges sometimes. But you shouldn't need to update it.
orchid flicker
But we are trying to correct the reporting within the dashboard as well
fallen hollow
What do you mean exactly?
rain troutBOT
orchid flicker
Since we have no control of how the e-commerce side of our payments work, we are trying to update the customer of the transaction to match our ERP so we can have some level of reporting within stripe
naive tulip
Hi 👋 taking over as my teammate needs to step away soon. As far as I'm aware there is no expectation that updating a Charge causes the related Payment Intent to also be updated. Is there something in our docs that gave you a different impression that we should look into?
orchid flicker
It's more so it should as you can result in a state like I described with those two request IDs
naive tulip
I can file feedback with our teams to consider adjiusting this behavior, in the meantime I recommend not providng different customer IDs for those.
orchid flicker
Ok, thanks - can we also get a timestamp added for when a payment intent is actually paid/captured? IE when it receives a balance transaction
naive tulip
What capture_method are you using?
orchid flicker
We're looking to move larger transactions to manual
Obviously with capture automatic, the succeeded event is enough. But just like charges, the succeeded gets called when a payment intent is just authorized and not captured
naive tulip
If capture is set to automatic, then the capture is also triggered at the same time as confirmation.
Ignore that, I'm trying to move too fast.
If you use automatic_async then you'll want to follow the suggestions in our guide for listening to when the Balance Transaction is created:
https://docs.stripe.com/payments/payment-intents/asynchronous-capture
If you use manual, then you know when the capture is triggered.
orchid flicker
Yeah, thats quite a mess to get something that should be available on the payment intent/charge itself (IE when it succeeded). We are dealing with the balance transactions when we receive a payout.paid event and then we pull the balance transactions involved in that event.
I guess more so what we're looking for is from a payment intent, getting the timestamp of when it succeeded
Not necessarily the btxn that marked the move of money (since those can be delayed).
naive tulip
Feels like the goal posts are moving a bit here. I'm guessing you're talking about payment intents for asynchronous payment methods here? The ones that can go into a processing state before succeeding?
If so, you'd create a webhook endpoint listening for payment_intent.succeeded Events to be notified when a Payment Intent transitions to a succeeded state, so you can record the time of that.
orchid flicker
The issue is we periodically sync records (incase of a missed event, etc). We'd need to be able to get the timestamp from the API as well. Yes we can grab the event timestamp from the Events endpoint but that doesn't do much good when we're trying to keep the API calls to a minimum and also trying to keep data normalized between a few systems
Essentially maintaining a mapping of our e-commerce transaction <-> stripe transaction <-> ERP transaction
naive tulip
That's not possible currently, I'll file feedback with our teams that this is something you'd be interested in seeing added in the future.
orchid flicker
Yeah, honestly it'd be nice to see something similar to charge.updated too for payment intents so when metadata/desc/etc changes, it fires
Got a few built up feature requests. You guys added my last one (refund.created)!
But yeah, succeeded at/updated at timestamps would be nice because then you can run an incremental sync every hour or so to check you recieved all events since X time.
naive tulip
Got those filed for you.
orchid flicker
Thank you! Ok to close this thread out. Have a great rest of your week!