#Becca
hasty lance
heavy creek
Hi, could you elaborate a bit more on your usage? Why do you set a Subscription expiration within 1 hour of its Invoice's finalization?
hidden bear
let me clarify, don't think we're on the same page
create a subscription 1/1/2023 01:00:00. invoice.finalized fires immediately and tells us the end period on the line item is 2/1/2023 01:00:00. we store 2/1/2023 01:00:00 in our database as the expiration date
using a test clock to advance time, at 2/1/2023 01:00:00 an invoice is drafted but not finalized until 2/1/2023 02:00:00.
so during that hour, the "are we currently before the expiration" test fails
heavy creek
Ah I think "expiration" is confusing. It's simply the billing cycle renewal
hidden bear
I have this in my notes taken from the documentation: "For typical integrations, you store customers’ credentials and a mapped timestamp value that represents the access expiration date for that customer on your site when a customer subscribes. When the customer logs in, you check whether the timestamp is still in the future. If the timestamp is in the future when the customer logs in, the account is active and the customer should still have access to the service."
heavy creek
That means "expiration" on your system. Anyway
hidden bear
so that's not meant to be the end period of the billing cycle?
heavy creek
It's the period_end indeed.
create a subscription 1/1/2023 01:00:00. invoice.finalized fires immediately and tells us the end period on the line item is 2/1/2023 01:00:00. we store 2/1/2023 01:00:00 in our database as the expiration date
using a test clock to advance time, at 2/1/2023 01:00:00 an invoice is drafted but not finalized until 2/1/2023 02:00:00.
This is expected and it's how Subscription Invoices work
hidden bear
sure, I understand that, I guess I'm just a bit confused on what the recommended handling is.
I'm using billing cycle end and period end and expiration date interchangeably.
I understand the draft period is an hour
I'm just trying to reconcile that with the guidance to store the expiration / cycle end timestamp
heavy creek
I think you can treat that 1 hour of "customer is out of access, but in 1 hour when we can charge them we should be fine, so let's be cool and give them continuous service". It really depends on your business stance IMO
You can store the cycle renewal as starting of the 1 hour aka 2/1/2023 01:00:00
hidden bear
just hard-coding adding an hour to the timestamp felt hacky so I just to make sure I wasn't steering off course
heavy creek
You can listen to invoice.created instead of invoice.finalized
invoice.created should be sent in the exact timing of billing cycle renewal
hidden bear
I thought of that but I thought it was recommended to use finalized over created
heavy creek
Um why?
hidden bear
the documentation saying finalized is when it's ready to be paid and sent to the customer and the customer is charged
heavy creek
But you need the billing cycle time 🙂
hidden bear
do customers see draft invoices in the portal? we currently have a flag based on "invoice finalized but not paid" to direct users to the customer portal to review/resolve (aka failed payment)
if I use invoice.created instead of invoice.paid, then that flag would be shown during that hour and it'd be confusing if the user goes to the portal but everything looks fine there
I guess I was thinking they wouldn't since the draft is still editable so it'd be kinda weird for them to see it hrm
(nope, draft invoice not shown in portal)
heavy creek
No draft invoices does not show. The 1 hour gap is more for you as a merchant if you want to somehow modify the Invoice.
The best approach would be splitting your logic:
- Save the billing cycle renewal from
invoice.created - Flag and send your customer to their customer portal from
invoice.finalized
They are 2 different logics and should occur as 2 different timing
hidden bear
ok, makes sense
one last question with invoices: with finalization there's the invoice.finalization_failed event. the documentation for that is all about tax errors. if weren't not doing anything with automatic tax calculations, do I need to be concerned with listening for and handling this event?
heavy creek
Tax is just one of the possible reason. There can be other reason too. Yes you should be listening to them and handle. https://stripe.com/docs/api/invoices/object#invoice_object-last_finalization_error
hidden bear
ah hmm ok
so basically just note the error for our support team? doesn't seem like there'd be anything to automatically be done?
heavy creek
Yeah I think so. Aggregate and review
hidden bear
noted