#ZakMcKraken
1 messages · Page 1 of 1 (latest)
It's my understanding that to get the full integration, one needs to use Payment Links and Checkout.
This isn't correct. Those are 2 separate products that do roughly the same thing.
However, we have a hosted checkout process using Card Elements. My goal is to show taxes to people before they buy. Upon chatting with the support, it doesn't appear that there is a way to do that.
That is correct. There's no integration path for Card Elements
Yeah, I meant OR Checkout, my bad 🙂
To work around this, I got the idea of using draft invoices to get the tax calculations (through total_tax_amounts in the object). Would that be the only way?
We generally don't recommend this path, as it gets really messy really fast, but it seems to have worked for other users to do it this way.
Is the Invoice from that object finalized and paid?
It's finalized but not paid. But if they need to be paid, that defeats the purpose of the solution.
Which is to display taxes pre-payment. (Just to be extra clear)
Right, I totally understand. The paid part shouldn't matter. Do you have the Invoice that the above total_tax_amounts came from? Specifically the ID
For example in_1Ln4j4JxoGEJplZe6xejmqhJ
I've been toying with changing account and customer location and things like that to see if that was changing the outcome
Is the Payment Method you're attempting located in the Tax Rate jurisdiction? There are a ton of Payment Methods on the Customer, so I'm unsure which is being used to generate the above total_tax_amounts
I was just using 4242
I'm guessing you are saying that meaning that I should update the PM billing details first?
Yeah, the PMs billing details are ultimately what will dictate the billing jurisdiction
Currently I was just updating the customer and then adding the PM
Good to know!
So based on what you said earlier, the only way to get taxes displayed on a card elements integration is to create a draft invoice in the background?
Hi there. Yes that's correct
I'm not caught up on this thread yet, but Upcoming Invoice endpoint might also work for you: https://stripe.com/docs/api/invoices/upcoming
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
How do you mean?
We sort of have a “cart” system where people can add a subscription and one or more one time product so I think I’ll have to continuously update a draft invoice.
That upcoming invoice endpoint just shows a hypothetical invoice given the parameters that you provide, so it's a good way to preview changes
But yeah it might not work for you
the only thing with the upcoming endpoint I guess is that it may contain an active subscription?
Like say my user is on an active subscription and they go and buy a one time product
the upcoming invoice would contain the subscription renewal?
Yes that's true