#raffi_invoice-questions
round bobcatBOT
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- raffi23_docs, 8 hours ago, 8 messages
vocal larkBOT
👋 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/1238169459173363732
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
frigid crypt
@lean ibex do you have an example Invoice id I can look at?
lean ibex
invoice id: in_1PEWzUL53dUV0i9Yzvk23ctC
I also have multiple other questions
-
do i need to update the charge object from inoice webhook envents if i am already getting the lateset invoice from payment intent webhook events?
-
is it better in general to store the line_items on the invoice model in my db or should i store them on the subscription model or both?
frigid crypt
That Invoice was already paid successfully via Checkout though so there is not next payment attempt. Sorry can you clarify your first question?
do i need to update the charge object from inoice webhook envents if i am already getting the lateset invoice from payment intent webhook events?
I'm not sure what that could mean either. What do you mean by "update"?
lean ibex
> do i need to update the charge object from inoice webhook envents if i am alre...
i mean sync it with my database
frigid crypt
is it better in general to store the line_items on the invoice model in my db or should i store them on the subscription model or both?
That's up to you and depends what you want to keep track of. A Subscription and an Invoice are separate objects. A Subscription is a contract of you charging me $10/month for example. An Invoice is a representation of you charging me $10 on April 1st, or May 1st, or June 1st, etc. So a Subscription will have multiple Invoices over its lifetime. And a Subscription can change "line items" as in what you bill me for, so you likely want to separate what line items are on a specific Invoice from what line items are on a Subscription
lean ibex
That Invoice was already paid successfully via Checkout though so there is not n...
with webhooks i am listening to invoices so i can sync them in my database, so for me to store the date when the invoice was paid i was not able to find a payment date key on the invoice object returned from stripe api
frigid crypt
Ah so you mean the date the payment happened. That would be the Charge's created in that case
raffi_invoice-questions
lean ibex
> is it better in general to store the line_items on the invoice model in my db ...
got it
frigid crypt
and for the "update your database", I would say that if you handle Events related to the Invoice like invoice.paid and invoice.payment_failed you don't have to listen to other Charge Events. That's up to you really on how much information you want to store
lean ibex
and for the "update your database", I would say that if you handle Events relate...
i am trying to store as much information as possible so i don't need to make fetch requests to stripe's api each time i need some information
lean ibex
Ah so you mean the date the payment happened. That would be the Charge's `create...
but what if i am also listening to invoice.created ? at this stage the created field is not the paid date but also populated anyway
frigid crypt
when you get invoice.created the payment has not happened yet, so you have no way to store that information
lean ibex
so in other words you are saying i need to store invoice.created only when invoice.paid event is fired is that correct?
frigid crypt
Not really I'm not saying that. You get invoice.created, you store details about the Invoice that you care about.
And later, you get invoice.paid and then you update your database to add new information such as the time it was paid, the Charge id associated with, etc.
lean ibex
okay i think now i understand
lean ibex
and for the "update your database", I would say that if you handle Events relate...
in case of a refund i do still need to listen for charge.refunded or charge.refund.updated though right?
apologies if my questions might not sound very clear, please lmk if something is not.
frigid crypt
You should listen to charge.refunded to know when a Charge is refunded yes. If you create the Refund via the API you also get the response synchronously though.
The charge.refund.updated is important to catch failed Refunds. They are rare but can happen, see https://docs.stripe.com/refunds#failed-refunds
frigid crypt
Sure thing! Let me know if anything else is unclear!
lean ibex
one more question that popped in mind,
to make it more clear first, i am handling one_time and recurring payments my initial implementation is that i am listening to all these events
"checkout.session.completed"
"payment_intent.canceled"
"payment_intent.processing"
"payment_intent.payment_failed"
"payment_intent.succeeded"
"customer.subscription.created"
"customer.subscription.updated"
"customer.subscription.deleted"
"invoice.updated"
"invoice.paid"
"invoice.payment_succeeded"
"invoice.payment_failed"
"invoice.upcoming"
"invoice.marked_uncollectible"
"invoice.payment_action_required"
"charge.refunded"
"charge.refund.updated"
currently on pyament_intent events i am storing
a payment db model that attaches either a subscription or order in the database payment model alongside the charge that has been made
and each of subscription or order have products purchased attached to them
now do i need to also store the charge from the invoice.paid or invoice.payment_failed events or this will cause too much duplication in my database?
frigid crypt
Really it's up to you on what you want to store. We (Stripe) don't really have any preference.
If it was me I would check what information you care about on Charge and if there is none ignore it.
lean ibex
I am asking you these questions because i am trying to build a general purpose solution.. what i can understand from you is that there is no right way to do these things and it only depends on preference and business model
frigid crypt
correct
lean ibex
thanks again 👍
frigid crypt
If I was building it I would have a table for subscription, a table for payments and that second table would have an Invoice id, a Charge id (most recent when previous ones failed) and some high level info about the Invoice amount, when it was paid, etc. And similarly info about Refunds on that same table
but you are welcome to have separate tables for everything to match our exact API. It really depends what you plan to do with that data later. If in 3 months you want to analyze your churn rate or decline rate or customer country breakdown, you'll want to have that information stored already.
lean ibex
Aha!, that's all the information I was trying to get your opinion on. now its clear what to do next
Awesome mate appreciate it 🙌
frigid crypt
yeah sorry I was trying to be non-commital because you won't be happy in 6 months if that model doesn't work for you :p
lean ibex
haha, I understand. no worries at all i am just starting out and trying to figure things out.
If it doesn't work its just an opportunity to learn.
frigid crypt
🙂