GazalaM - subscripiton updates | Stripe Developers | Page 1

naive coyote Jul 8, 2022, 4:04 PM

#

HI 👋
That's a lot of text. Give me a sec

keen haven Jul 8, 2022, 4:07 PM

#

No problem. A bit more context about what I'm trying to achieve is here: https://discord.com/channels/841573134531821608/991690300529573970

naive coyote Jul 8, 2022, 4:07 PM

#

Okay, looking at that first invoice

#

Hmmm I'm having trouble identifying where that second Invoice Item is coming from. Did you have a one-off invoice item created for the customer?

#

A new invoice will sweep up outstanding invoice items for a specific customer

keen haven Jul 8, 2022, 4:15 PM

#

Nope, no one-off invoice items. It may just be a quirk of the test clock and the price which is not exclusively meant for test clocks?

naive coyote Jul 8, 2022, 4:16 PM

#

As long as the Customer and Subscription are Test Clock specific then the price shouldn't be an issue.

keen haven Jul 8, 2022, 4:17 PM

#

My basic concern is how the timestamps should be - I'm just using UTC timestamps, but my account is in CET. Should I be worried about Daylight savings time, or does stripe calculate billing only in epoch UTC time?

naive coyote Jul 8, 2022, 4:20 PM

#

Stripe billing is UTC. So you should be good there

#

All the invoices I am seeing are for the 2,008 total.

#

Except that first one with the one-off invoice item

keen haven Jul 8, 2022, 4:25 PM

#

Good point, the last one is still an upcoming invoice, let me try to advance the clock another month to make it a real invoice.

#

Yup, this last invoice is with a lower amount: in_1LJJzyHfRoBp5g8K8xTbj1Uk

keen haven Jul 8, 2022, 4:28 PM

#

naive coyote Stripe billing is UTC. So you should be good there

Thanks, then I think this might just be a clock issue. I'll test it with a non-clock test customer.

naive coyote Jul 8, 2022, 4:28 PM

#

keen haven Yup, this last invoice is with a lower amount: in_1LJJzyHfRoBp5g8K8xTbj1Uk

🤔

#

I'm seeing one field that suggests a credit note may have been generated and the price prorated. Still trying to track down how that happened.

keen haven Jul 8, 2022, 4:53 PM

#

Woah, this is also happening with a non-clock test customer: in_1LJKOoHfRoBp5g8KByaX1Vz1

naive coyote Jul 8, 2022, 5:00 PM

#

You mean the one-off charges?

#

Oh...it's a proration

#

kind proration

#

Okay so I think something wonky is going on with the timestamps being used here.

#

The extra invoice item is a proration on the recurring price object.

#

With the following attributes:

proration_end    2022-07-08 16:51:25 +0000 (1657299085.0, 9 minutes ago)
proration_start    2022-07-08 00:00:00 +0000 (1657238400.0, 17 hours ago)
time_fraction    0.02265718339307049

#

So during the initial creation it appears your user is getting a prorated bill for an additional ~17 hours of the service. High price for a fancy car.

keen haven Jul 8, 2022, 5:15 PM

#

Ah yes, and I cannot use proration=None since some of the backdates are weeks ago (which we want to charge them for).
I tried a workaround that I used before by setting the billing cycle anchor to the next month, and this avoids the extra few hours of prorations!

#

Thanks so much for your help! I'm happy with this workaround, we can close the thread here.
Fix for future readers: Use billing cycle anchor set to the next moth.
{ "backdate_start_date": "1657238400", "billing_cycle_anchor": "1659916800", "customer": "cus_LvDh95SJKwL9jD", "items": { "0": { "price": "price_1LJE80HfRoBp5g8KKaU64J6u" } }, "cancel_at": "1673136000" }

naive coyote Jul 8, 2022, 5:18 PM

#

Okay great! Honestly testing subscriptions with sub schedules, back dates and such is one of the most complex topics at Stripe.

#GazalaM - subscripiton updates