0xbenzy

[icy blade]

hello! gimme a while to get back to you!

[lavish parcel]

Hey @icy blade thanks

[icy blade]

The timestamp and date the customer is paying (billed) for will always be the same. However, when the invoice itself is generated / paid might differ slightly depending on our queue load.

https://stripe.com/docs/billing/subscriptions/billing-cycle

If a month doesn’t have the anchor day, the subscription will be billed on the last day of the month. For example, a subscription starting on January 31 bills on February 28 (or February 29 in a leap year), then March 31, April 30, and so on.

[lavish parcel]

awesome, ok. So if that payment fails, there will definitely be a invoice.payment_failed trigger, right?

[icy blade]

yep, that's right

in case you haven't seen this yet, you can use test clocks to mimic the passing of time : https://stripe.com/docs/billing/testing/test-clocks

[lavish parcel]

Yeah I have actually seen that, but I am taking over from a developer in my team that has created a bit of a nightmare for me to deal with. He has replicated the billing cycle locally and if we use the clocks we'd end up out of sync with what we have in our local database

So we essentially create subscription objects in our DB with fixed dates and check against those dates whenever a change comes in from Stripe

[icy blade]

aaah, maybe that was done before we implemented test clocks

testing subscriptions was a huge pain before we had test clocks

[lavish parcel]

could be

one more question actually

in the Stripe.Invoice object, can I get the planId?

I mean the price_ thing

[icy blade]

yep, it should be there within lines : https://stripe.com/docs/api/invoices/object

[lavish parcel]

Ah got it, thanks

line item

https://stripe.com/docs/api/invoices/object

Minor feedback point: I use CMD+F to search within a page but that always opens the global search box on that page which is a bit unintuitive for me