#takkara_api
late nacelleBOT
👋 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/1399387247232552980
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
stark vault
Hi, what does Charges without PaymentIntents mean? If there is a charge, there should be a PaymentIntent. Can you share the charge where you see this behavior?
opal coyote
Our understanding is that (especially for legacy integrations), Charges could be made without PaymentIntents. Stripe heavily suggests that people do not use direct Charges anymore, but because we do no control how users get the data in their accounts, we have to account for people with old integrations that use Charges in the absence of PaymentIntents.
This seems to be supported by the InvoicePayments API, because one of the payment property options for the InvoicePayment is "charge" and it says this:
ID of the successful charge for this payment when type is charge.Note: charge is only surfaced if the charge object is not associated with a payment intent. If the charge object does have a payment intent, the Invoice Payment surfaces the payment intent instead.
But, if this is the case for an InvoicePayment, we can't find a way to reverse the search and find the InvoicePayments associated with a given Charge.
stark vault
Yeah, that is legacy approach. Can you confirm why you have not fully migrated to PaymentIntents?
opal coyote
We do not control the way payments are processed. We're an accounting integration. We simply migrate the data we find in the user's account when they install our app.
Therefore we need to be maximally flexible to work with the widest array of possible customers and their Stripe accounts
Our integration works from mapping from Payouts -> BalanceTransactions -> Charges/PaymentIntents -> Invoices.
Using the new API, we can salvage the path including PaymentIntents, but the breaking change has broken our ability to follow this path for legacy Charges. We are seemingly now forced to examine every Invoice in the user's account and then retrieve all the InvoicePayments for all of those Invoices and then see if any of them include the Charge ID in question. This is prohibitively non-performant, and would prevent us from supporting anyone with a legacy integration.
We need to request that Charge be included alongside PaymentIntent as an allowed parameter in the InvoicePayments.List endpoint.
stark vault
I see, taking a look on my end
opal coyote
Alternatively, if the Stripe AI and my reading of the document is correct, there was no reason to remove the link directly from a Charge/PaymentIntent to an associated Invoice. Payments can only be applied to a single Invoice, even if a single Invoice might have multiple PaymentIntents/Charges (or even out of band payments). So, if it's possible to restore the reference link from Charge -> Invoice and/or PaymentIntent -> Invoice, that would also fix our issue.
stark vault
There is not a way to revert this. Typically, you just use the older API version to 'revert' this behavior until everyone is migrated to the PaymentIntents.
opal coyote
That's fine for the final suggestion, but for as long as Stripe supports charge as a payment option for InvoicePayments, it needs to be possible to use charge as a parameter for the InvoicePayments.List endpoint.
We simply must have a performant solution given a Charge (absent a PaymentIntent) to find the Invoice it pays (in-whole or in-part).
misty gust
Hi there 👋 I'm jumping in as my teammate needs to step away soon.
I can definitely see how being able to list payments by Charge ID would be beneficial, though offhand I'm not readily thinking of an integration that would allow you to use Charges with Invoices without also using Payment Intents. I'll file feedback with our team for them to consider expanding the list of supported filters to include charge as well.
Can you help me understand if this change in our newer API versions has impacted how you were handling this scenario previously? Is the approach you were using before no longer performant when continuing to use a previous API version?
opal coyote
I think I described it above, but yeah
Our integration works from mapping from Payouts -> BalanceTransactions -> Charges/PaymentIntents -> Invoices.
Using the new API, we can salvage the path including PaymentIntents, but the breaking change has broken our ability to follow this path for legacy Charges. We are seemingly now forced to examine every Invoice in the user's account and then retrieve all the InvoicePayments for all of those Invoices and then see if any of them include the Charge ID in question. This is prohibitively non-performant, and would prevent us from supporting anyone with a legacy integration.
misty gust
Yup, but the approach you were using before in previous API versions wasn't impacted, was it? Since the previous API versions are still available and interact with the same data, I want to ensure that the solution you had previously wasn't becoming less performant since a performant solution seems to be your key concern.
You control what API version you use when interacting with our API, so if the previous approach worked better for you, you can keep doing things that way.
opal coyote
So, we'd use the older version exclusively for fetching the Invoices associated with Charges, but then use the newer version for all other operations?
misty gust
Do you need the newer version for anything?
opal coyote
We're in the process of adding support for new upcoming Stripe features, so we have to be able to use the latest API for those things. We could use the old API for this particularly functionality, if that will continue to work.
misty gust
Yup, you can use an older API version for this path if that works better for you.
opal coyote
We'll take a look at that path. We would still strongly request the ability to retrieve InvoicePayments by Charge ID as well as PaymentIntent ID. For as long as Stripe supports Charge as a payment option in the InvoicePayment object itself, it would suggest we need to be able to retrieve those InvoicePayments by Charge ID as well as PaymentIntent ID, but we can try this workaround for the time being at least.
Our issue is just that we cannot assume people will cease having these legacy integrations, same as Stripe. We have to support people that have them, and it would be good to not have to support multiple API versions forever.
misty gust
Yup, totally get that, and will file that feedback for our teams to consider.
opal coyote
Thanks for the help!
misty gust
Any time!