#nerder-subscription-upcominginvoice
1 messages ยท Page 1 of 1 (latest)
Hello! We'll be with you shortly. 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.
- _nerder, 7 hours ago, 12 messages
- nerder-discounts, 3 days ago, 25 messages
Hey @timber pine ! I'm sorry but I don't really know what that could mean. Can you try and provide a bit more details?
Hey sorry for my bad explaination
practically i want to mimic this behaviour in my app:
the price is 99EUR, but has an applied coupon of -30%
right now, when a subscription.created webhook event is triggered, i'm saving that subscription object in my DB
but for the amount i'm using this:
amount: subscription.items.data[0].price.unit_amount,
and this causes a bug since it will not take into account the actual discount and just shows the original price amount
That's expected, a Subscription doesn't really have that information. The associated Invoice would. For example the most recent Invoice would be in latest_invoice.
The next Invoice can be previewed using the Retrieve Upcoming Invoice API: https://stripe.com/docs/api/invoices/upcoming
nerder-subscription-upcominginvoice
oh ok, it means that in my webhook i need to fetch the upcoming invoice?
yes
it doesn't really make sense to "cache" this information in my eyes since things can change in the future. You really should use that API when you render the UI/info instead to your customer
i'm not really caching it anyway, since i'm keeping it in sync with a customer.subscription.updated
sure but many other things can change that Invoice such as having a credit balance, a coupon on the Customer, additional InvoiceItems, etc.
Definitely not something I'd do at least if I were building this
umm, ok that's interesting
even if i'm able to fix this right now I might encounter more bugs
It's quite expensive tho to fetch this all the time
but I'll totally consider refactor this entirely
๐
one question then
the period_start and period_end of the upcoming invoice
are the same of current_period_start and current_period_end of the sub?
yes because the upcoming Invoice would bill "for the past" which is the current period so in that case they would usually match. They can differ if your Customer has a pending Invoice Item that was created earlier. So mostly while they can match it's usually not something you need to know or should care about
ok understood
so to recap, right now my subscription "object" it's a merge between the informations of the sub and the next upcoming invoice
what should I do is to keep this 2 information separates
If it were me I'd never store "upcoming invoices" at all and just fetch it when I really need it
but yes
yes, understood
trialEnd and cancelAt are informations of the upcoming invoices or subscriptions?
id: subscription.id,
subscriptionPlanName: //from subscription metadata
amount: // from upcoming invoice
currency: // from upcoming invoice
currentPeriodStart: // from upcoming invoice
currentPeriodEnd: // from upcoming invoice
trialEnd: // from subscription
cancelAt: // from subscription
status: // from subscription
hasScheduledUpdate: // from subscription
should be something like this?
Maybe? Sorry I don't really know what you're trying to do. Like the period is on the Subscription so I don't get your intent
basically i'm trying to understand what can be "cached" and what shouldn't
that is my current Subscription model basically
I think i've understood tho
๐