#Nick (CS)-invoices
vague trellis
Hello! GIve me a minute and I'll take a look
The orders API is a good solution when physical goods are involved because you can set up a product catalog - if you don't need that then one-off Invoice should be fine
knotty sierra
OK cool. Thx for that clarification. I had another question related to the invoices API. I'm in a situation where my client wants to take payment with Paypal as well as with Stripe. For the Paypal integration I'm creating an invoice in stripe, taking payment in Paypal, then marking the invoice as paid out of band; however, I'm not sure about the best way to handle tax recalculation on the invoice when a user changes their address in Paypal. Is there a specific way to do this using an update subscription API call?
vague trellis
Are you planning on using Stripe Tax?
knotty sierra
sorry I said update subscription, but I meant update invoice.
Actually, it's being looked into, but I think we may be using the Avalera Stripe integration. Not confirmed because we haven't had a chance to chat with the Avalera rep, but I'm assuming that's the solution for now.
When a user changes their address in Paypal a callback is executed that allows me to update a Stripe customer's address. Would I simply need to retrieve the previously created invoices information using the retrieve invoice API to see the proper tax and new total based on the new address?
vague trellis
It really depends on how you're implementing taxes - If you're using Avalara, then you'd need to check with them about whether this would be sufficient. The issue is that if the Invoice has already been finalized then there's no way to update it after that point - you'd need to generate a credit note correct the tax. But if the Invoice is still a draft you can still change the tax
I need to head out, but @modern stone can answer any other question you have
knotty sierra
ok thx!
Hi @modern stone, I'm bouncing around a bit on topics, but I'd like to go back to the best option between orders vs invoices API. karbi mentioned that the orders API may be a good option if selling physical products and keeping the product catalog in Stripe. I assume the same logic applies if selling digital goods when these have corresponding items in the product catalog within Stripe? Is the orders API a more streamlined process than the invoices API? At the moment, I'm making quite a few API calls to facilitate a paid invoice,
- Create invoice item
- Create invoice
- Finalize Invoice
- Retrieve the payment intent
- Take payment using Stripe Elements
All of this is to take advantage of the stripe coupons and automatic tax calculation. The one wrinkle is the need to mark an invoice/order paid out of band if the customer pays through Paypal.
modern stone
I assume the same logic applies if selling digital goods when these have corresponding items in the product catalog within Stripe? Is the orders API a more streamlined process than the invoices API?
These questions are a bit nebulous, as I don't really know what you mean buy 'streamlined'. What are you hoping to achieve over your current integration? Less API calls overall?
knotty sierra
Exactly. Although my question is really why should I chose the orders over invoices API given the scenario I mentioned above. We're in early stages so I'd like to make an informed decision.
modern stone
I think the biggest trade-off is tech-debt VS. customizability. Orders is going to be easier to use for most common use-cases, whereas the Invoice flow you referenced above is going to be better for creating custom logic. I see Orders as a singular trail to a singular destination, whereas I see Invoices + Payment Intents as a network of trails to a few different destinations.
You can mark payment as out-of-band (https://stripe.com/docs/invoicing/overview#paid) and also charge tax for both of the payment flows. It just depends on if it's worth it to you to do a lot of work upfront in order to make it easier to make edge-case customizations later down the line.
