#orange_api
night laurelBOT
đ 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/1443323257578192927
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
rose cliff
Hi there! This is related to changes in the shape of Subscriptions/Invoices in Basil and later api releases
the Invoice doesn't have a payment_intent parameter any more
Let me find the doc for you
rose cliff
No problem!
patent vector
Does the subscription have invoice and intent created right away after the subscription is created?
night laurelBOT
rose cliff
That depends a bit on how the Subscription is configured - there are many factors that can influence what is created and when, such as whether you're sending the invoice to the customer or charging a payment method on file, free trials, what kind of price you're using; usage-based vs licensed, and so on.
patent vector
So it would be better for me to have the payment intent handling after subscription update rather than after subscription creation
rose cliff
That depends! It would be best to explain what you mean by "payment intent handling" and provide an example Subscription that represents the flow you intend to use
patent vector
The current sistem is inserting payment intents details into database right after a payment intent is created. So that's what "payment intent handling" refers to in my case.
The payment intent is never handled by webhoook with event "payment_intent.create" (hope I got this right). There's only the "payment_intent.update" and "payment_intent.update" webooks that do some updates.
It's probably done this way so the user gets to success stage of the payment faster.
balmy sail
Gotcha, so listening to payment_intent.created as well may be helpful here. If you need the payment intent details specifically, the most direct way to do that is to list all payments for the invoice in the latest_invoice property on the subscription that your create or update call returns. That will return the full object of the payment intent assosciated with the invoice.
That said, making that list call after every create or update call may be a bit cumbersome. Are there specific details that are only on the payment intent object that you are logging in your DB here? If not, it may be easier to rework your code to pull its data from the invoice object itself which contains a lot of the same info.
patent vector
The thing is we have payments on bookings and now subscriptions for users are implemented. Some of the payment intent details are stored then a cronjob comes in to update the metadata for each intent
They want metadata to be seen in stripe transactions menu as well
balmy sail
Ah gotcha, so yeah listing the invoice's payments would be the best way to get the ID of the payment intent that was created. I think you could split the confirmation_secret string on its second underscore. The secret has a format of pi_123_456 where pi_123 is the actual ID of the payment intent. The issue with that is that I don't think that format is technically guaranteed so it could in theory change without being flagged as a breaking change.
patent vector
Seems to be working fine with retriving the lastes_invoice and expading expand: ['payments.data.payment.payment_intent']
balmy sail
Ah yes that works as well!
patent vector
Thank you!