#damienfa_api

1 messages · Page 1 of 1 (latest)

gleaming troutBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1250887086131642409

📝 Have more to share? Add details, code, screenshots, videos, etc. below.

neat stump
#

Here more details and steps to reproduce.

#

State before 1st of June :

I send a simple request (POST /v1/subscriptions) with "billing_cycle_anchor": "1717199999" (= UTC : 2024-05-31 23:59:59') to create a subscription starting on May 31th 2024.

Result :

  • When I visit the page of the created subscription, I can see "Current period:
    Jun 1 2024 to Jun 1 2025", so that is alright.

  • Also right, when I export the subscriptions csv, the columns "Current Period Start (UTC)" and "Current Period End (UTC)" have "31/05/2024 23:59" and "31/05/2025 23:59" respectively.

  • And when I retrieve this subscription with curl https://api.stripe.com/v1/subscriptions/sub_xxxx, I also find in the response "current_period_start": 1717199999, "current_period_end": 1748735999 (= UTC : "31/05/2024 23:59" and "31/05/2025 23:59").

🟢 So, it worked well and as expected !

Here some ids of my live subscriptions if it helps :

  • sub_1PM7xuFozK3SDFaCTaNvDg5G
  • sub_1P56SVFozK3SDFaCjgN3MshQ
  • sub_1OAxkHFozK3SDFaCmGdv6AcR
#

State sinc since 1st June 2024 :

=> I send the exact same request but for June, "billing_cycle_anchor": "1719791999" (= UTC : 2024-06-30 23:59:59') to create a subscription starting on June 30th 2024.

Result :

  • When I visit the page of the created subscription, I can see "Current period:
    Jun 12 2024 to July 1 2024"     , so that is different ! 🔴
    The start date is now the one the request have been sent, and the date of period end is the expected start date (2024-06-30 23:59:59).

  • Same, when I retrieve this new subscription with curl https://api.stripe.com/v1/subscriptions/sub_xxxx, in the response I have "current_period_start": 1718193764, "current_period_end": 1719791999 (= UTC : "2024-06-12 12:02:44" and "2024-06-30 23:59:59").

🔴 That not what is expected.

Here some ids of my live subscriptions (after June 1) if it helps :

  • sub_1PQpt2FozK3SDFaCVSmRFOnr
  • sub_1PPJVMFozK3SDFaCTdoUvVtO
  • sub_1PObIuFozK3SDFaCWUHXxn0d
ionic brook
#

What part of this is not what you expect, specifically?

#

Because all of this seems expected/normal to me so I want to understand where we are misaligned

neat stump
#

The behavior changed. The same request has not the same result.

ionic brook
#

Are you sure the behaviour changed? YOu're giving examples with fundamentally different characteristics (past s future renewal) so this is not a direct comparison

#

date of period end is the expected start date (2024-06-30 23:59:59).
It's worth being clear that this is not the start date you are setting, it is the billing cycle anchor, the renewal date.

#

The subscription starts with the creation request (though you can backdate this, too), and will have a prorated short period until the anchor date you picked (june 30)

neat stump
#

Summary :
When I created a subscription with the API with "billing_cycle_anchor": "1717199999" (date is end of month), it created a subscription with this date as current_period_start . See my logs !

Now, when I created a subscription with the API with "billing_cycle_anchor": "1719791999" (still end of current month), the created subscription has this date as current_period_end and the start is right now !

ionic brook
#

then will renew june 30 2024 to june 30 2025 for 1 year

#

it matters that for your initial "working" example were using a billing cycle anchor in the past vs future

#

that has different behaviour

neat stump
#

Sorry maybe we're misunderstood, I think i'm not giving examples with fundamentally different characteristics (past s future renewal), the May requests have been done in May and the billing_cycle_anchorwas "end of may". Now in June, I do the same (end of June), and it's not working the same.

ionic brook
#

Can you show me one of those requests from May to compare the results?

#

Running the same request using a may date now is not the same

#

Alternatively, you can try using Billing Test Clocks to set a virtual time in the past, if you want to recreate that

#

And see whether the "may" behaviour was different

neat stump
#

🤔 But what you say is impossible, I don't think I can create a subscription for a "past date", it makes no sense.
I want to create subscription where the billing period is "end of month", and it worked well.
Now, we have hundreds of customer asking why they are billed everyday.

#

I don't need to test with "Billing Test Clocks" because I have hundreds of examples / cases !

#

Do you need screenshots and examples ?

ionic brook
#

A request ID from May will do

neat stump
#

As you may see, the request is from May, and the billing anchor is set at "2024-05-31 23:59:59"

ionic brook
#

yes, and:

  current_period_end: 
1717199999
,
  current_period_start: 
1717071618
,
#

which is the same as what you're describing now for june

neat stump
#

(No, please 🙏 this is another problem I will talk later. The API response hasn't changed, but the behavior every where else is different !)

#

Or try to retrieve with curl the subscription, you will see that the current_period_end and current_period_start are not the same that is the logs/req above !

ionic brook
neat stump
#

Yes, the same subscription

ionic brook
#

Well yes, the subscription has renewed since we passed the anchor

#

Here is when the period start/end dates were updated to the new period

neat stump
#

You mean that initialy this subscription was May 30 to May 31, and it renewed on May 31, to become "May 31 to May 31 (next year)" ?

ionic brook
#

yes

#

That's expected based on how you're setting the billing_cycle_anchor

#

We invoice for the initial period from creation/start until the anchor, then renew for the full period (1 year in your case)

neat stump
#

🤔 so I would find a invoice for the period May 30 to May 31, isn't it ?

ionic brook
#

You've specified proration_behavior: "none", so the initial period is not prorated, there is nothing to invoice

neat stump
#

Ok ok 🤔

ionic brook
#

If you remove that to test, yes you'll find an initial inoice created for eg May 30 - 31, or today for June 13 - June 30

neat stump
#

One last thing, when I export my subscriptions in csv : you can see that, after June 1, the "Current Period Start (UTC)" is always different, but before June 1, it's always "end of month" …

image.png
#

It's because the May, Abril, March, has been renewed at end of their month ? (with no prorata)

ionic brook
#

Yes, if you expoerted this subscription data today, those "previous month" subscriptions would have all renewed at the specified anchor, assuming you;ve been doing the same thing

#

This is why i initially described the fundamental difference between past vs future renewals

neat stump
#

Ok. I thought my subscription will "start" in the future (at billing_cycle_anchor), I didn't think it starts "now" until "billing_cycle_anchor" and be renew for one year ! 👍

#

I thought the first renew will be next year, but the start I expect is, actually, the first renewal

ionic brook
neat stump
#

Then, what I do currently is a "hack" 🤦🏻‍♂️

#

Thanks for your help.

#

We have a lot of customers complaining about the invoice of those last days. So, we have a problem to resolve but what I describe in this Thread seems not to be related and is the expected behavior. I will look further.
Thanks