sukatoa-subscription | Stripe Developers | Page 1

patent oxide Jul 5, 2022, 4:33 AM

#

👋 Can you share the subscription ID (sub_xxx) with situation you faced?

pearl silo Jul 5, 2022, 4:33 AM

#

sure, Thanks River. Hold on

#

sub_1LI2CkHxUYbY7mq5UUea6z4o

#

here

patent oxide Jul 5, 2022, 4:42 AM

#

Stripe follows monthly billing cycle instead of 30 days:

For example, a customer with a monthly subscription set to cycle on the 2nd of the month will always be billed on the 2nd.

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.

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

#

In the sample subscription, the backdate is set to 30 June (which is one month + one day in total for first invoice), so it's prorated to 330 (month of Jul) + 330/30*1 (30 Jun) = 341

pearl silo Jul 5, 2022, 4:46 AM

#

oh, hhmmmmm

#

you're pointing to this right? i got it from here https://dashboard.stripe.com/test/events/evt_1LI2CnHxUYbY7mq5EKy4a0hM

#

which is

#

does this mean Stripe uses GMT to compute?

patent oxide Jul 5, 2022, 4:49 AM

#

Let me double confirm the timezone that is used

#

The epoch timestamp are in UTC format

#

1656604800 here = 2022-06-30 16:00:00 UTC

pearl silo Jul 5, 2022, 4:56 AM

#

And so Stripe will look for the UTC one, to compute its Monthly concept - and it detects the July 31st is an extra day because the startdate in UTC is set on June 30, 4PM UTC

patent oxide Jul 5, 2022, 4:58 AM

#

To correct it, you'll need to set the backstart date to epoch timestamp of 1 Jul in UTC

pearl silo Jul 5, 2022, 4:59 AM

#

Ahhh, so In order for this to be resolved and follow the logic we wanted. The first attempt of backdateStartDate is we must set its value that is inline with UTC/GMT at least July 1, 2022 00:00:00 for the Stripe to compute its monthly concept and land its next billing cycle to Aug1,

but then its fine to override its via setting its nextBillingCycleAnchor in GMT+9 to get it to normalize on our timezone

#

Will try this one and test, will get back to this to give feedback. Thanks much River

restive siren Jul 5, 2022, 5:04 AM

#

@pearl silo I'm taking over this thread, let me know if you have a follow-up question

pearl silo Jul 5, 2022, 5:05 AM

#

Thanks Jack Tan 🙇‍♂️

#

will provide feedback here soonest

restive siren Jul 5, 2022, 8:00 AM

#

I need to step away so I’m going to archive this thread. If you need help with anything else please ask in #dev-help or contact Stripe Support: https://support.stripe.com/contact

Stripe: Help & Support

Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

near lily Jul 5, 2022, 11:14 AM

#

@pearl silo 👋

pearl silo Jul 5, 2022, 11:14 AM

#

Thanks Jonny 😄

near lily Jul 5, 2022, 11:14 AM

#

Hey! Can you summarise the issue?

pearl silo Jul 5, 2022, 11:14 AM

#

So I'm back to give feedback - it was advised to set the backdateStartDate into July 1, 12:00:00AM UTC so that Stripe will do the correct computation to end up charging 330 instead of 341

#

To summarize, we are charging the user of whole month even if the user started the monthly subscription in the middle of the month

#

We use backdateStartDate to point it to July 1 and start the billing cycle anchor to next Month Aug1 so we charge them 330 upfront

#

unfortunately it charges 341

#

only to find out that the backdatestartdate we used is referencing on localtime of july 1, 12:00:00am, but the UTC/GMT is June 30, 4PM

near lily Jul 5, 2022, 11:17 AM

#

pearl silo only to find out that the backdatestartdate we used is referencing on localtime ...

Yes, the API uses UTC and all your values should reflect that

pearl silo Jul 5, 2022, 11:17 AM

#

And now we try to adjust the backdate startdate to have the local time equivalent to July 1, 2022 12:00:00AM UTC/GMT

#

but it charges 326, not 330

near lily Jul 5, 2022, 11:18 AM

#

Can you share the ID of a recent API request to attempt this? req_xxx

pearl silo Jul 5, 2022, 11:18 AM

#

subscription ID: sub_1LI9X0HxUYbY7mq5NA0XkWKA

#

hold on

#

hhhmmmm I'm confused where to find it on the Stripe dashboard, unfortunately, we're not logging that id on the app. May I know where specifically we can get that id

near lily Jul 5, 2022, 11:21 AM

#

Let me check that sub_xxx

#

https://dashboard.stripe.com/test/logs/req_mtXgkdAj0ZYx54

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

#

billing_cycle_anchor: "1659283200" (Sun Jul 31 2022 16:00:00 GMT+0000)
backdate_start_date: "1656633600" (Fri Jul 01 2022 00:00:00 GMT+0000)

#

Looks like your billing_cycle_anchor timestamp isn't the correct UTC value

#

you're 8 hours short

#

Thus the invoice is prorated to 326

pearl silo Jul 5, 2022, 11:42 AM

#

ohh, that part. So the backdateStartdate now is correct. It such that the billingCycleAnchor is incorrect this time that's why it got short

near lily Jul 5, 2022, 11:44 AM

#

Seems that way if the intention is to use August 1st!

pearl silo Jul 5, 2022, 11:45 AM

#

alrights, I'll get back to this thread for further feedback on the experiments

#

thanks so much Jonny!

near lily Jul 5, 2022, 11:47 AM

#

np!

pearl silo Jul 5, 2022, 12:10 PM

#

Hey Jonny, it works! you guys River, Jack Tan and Jonny are awesome!

#

10/5 stars for you guys

near lily Jul 5, 2022, 12:12 PM

#

🎉

#sukatoa-subscription