#kabobbob

1 messages · Page 1 of 1 (latest)

austere stagBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

maiden cove
#

Is there some reason "initial_billing_cycle_anchor" is not allowed through the API?

woeful void
#

The parameters used in Dashboard and API are different. With API, the correct parameter should be billing_cycle_anchor

maiden cove
#

That failed as well

#

I think subscription schedules may not be what I need, I will continue to experiment

#

Thank you

woeful void
#

Oh sorry, my bad! I forgot this is subscription schedule. Can you share what you would like to achieve here?

#

So that I can advise the solution accordingly

maiden cove
#

I am trying to design my code that I could have one method that depending on arguments will create a subscription starting either now or at some future date (argument dependent) and set the billing_cycle_anchor to a future date. We're looking to have customers on a calendar quarter schedule: 1/1, 4/1, etc

woeful void
#

Thanks for sharing! This will work differently in API integration.

With Subscription Schedule, you will create two phases. The first phase will be the start of the subscription and the second phase will be when the billing_cycle_anchor will be set. In second phase, you will have the start date with the expected billing cycle anchor timestamp and have billing_cycle_anchor: 'phase_start'. You may refer to the guide here: https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#resetting-anchor

Learn how to use subscription schedules.

maiden cove
#

Ok, that creates the schedule as I need, however, we're experiencing a billing issue. We create the subscription with quantity of 0 (using volume pricing) . After some period of time, we're going to update the quantity and we want Stripe to calculate the proration. The issue we're seeing is that the proration is not taking into account that the subscription will have the billing cycle anchor reset. Like this example: (the test clock object date is Feb 19th)

woeful void
#

This channel is for technical integration via API. For Dashboard preview / summary on the proration details, I'd recommend reaching out to our Support https://support.stripe.com/contact as Dashboard can work differently from API

maiden cove
#

I think when I attempt to update the quantity through the api I get the same results. Let me verify

woeful void
#

Sure! After you you create the subscription via API, please share the example subscription ID (sub_xxx)

maiden cove
#

Ok, this is the id of the subscription schedule: sub_sched_1OIMZBBIn9tGMHjLrWXBz5Ee

#

The ID of the subscription is sub_1OIMaOBIn9tGMHjLxPchuzzL

woeful void
#

This looks correct to me. Why do you expect proration to happen on the first day of April 1? Since you have reset the billing cycle cycle, it will charge the amount from Apr 1 to July 1 with the full usage

maiden cove
#

That part is fine and expected.

#

The proration I'm talking about is if we update the quantity in March

#

I'm trying that out now

#

To verify results

woeful void
#

Sure! Do share the new subscription ID (sub_xxx) and your expected behaviour, so that I can check

maiden cove
#

It's the same subscription ID: sub_1OIMaOBIn9tGMHjLxPchuzzL.

woeful void
#

When the quantity was updated on the subscription itself in https://dashboard.stripe.com/test/logs/req_2OuODy5IBMZ2ch, it will be updated to immediately and prorated the amount based on the usage from 2024-03-02 01:43:00 UTC (at the time when the clock was frozen when making the quantity change) to 2024-04-01 05:00:00 UTC. Prorated amount will be billed in the next billing cycle: https://dashboard.stripe.com/test/customers/cus_P6ZVQ1Myis02V0/upcoming_invoice/sub_1OIMaOBIn9tGMHjLxPchuzzL

However, you have a subscription schedule that reduces quantity to 0 on 2024-04-01 05:00:00 in https://dashboard.stripe.com/test/logs/req_711zTx2qrxfntq (initial subscription schedule creation request), so quantity will revert back to 0.

#

This behaviour is expected

#

Can you explain what you would like to achieve here?

maiden cove
#

Yes. I created this subscription (sub_1OINKMBIn9tGMHjLnhDjXQUk) to start immediately (test clock date of Dec 7) with the billing_cycle_anchor of 1/1. I advanced the clock to Dec 14 and updated the subscription quantity with the proration_behavior of always_invoice this did what I expected of immediately invoicing the customer for the pro-rated amount and will next invoice the customer on 1/1 for $37.50.

#

What I'm looking to achieve is the exact same results with subscriptions that are scheduled in the future.

#

Your previous response made it appear that this is possible and I just didn't submit the correct parameters

woeful void
#

I see what you're trying to do with Subscription Schedule now. It's indeed possible on Subscription Schedule, but the difference is that the quantity update should be made on the Subscription Schedule instead of Subscription itself. Let me verify / test myself on the correct parameters to be set for this scenario

maiden cove
#

Ah! I'm in the middle of another test scenario as well

woeful void
#

Okie! The ways to do about this is to introduce a new phase for updating the quantity on the subscription schedule. So it'll be:

{
  phases: {
    // Current phase and set the end date to current timestamp to end the quantity of 0
    0: {
      end_date: 
"1701561600"
,
      start_date: 
"1701475200"
,
      items: {
        0: {
          quantity: "0",
          price: "price_xxx",
        },
      },
    },

    // Update the new quantity and set proration_behavior: "always_invoice" to invoice immediately
    1: {
      end_date: 
"1702598400"
,
      proration_behavior: "always_invoice",
      items: {
        0: {
          quantity: "2",
          price: "price_xxx",
        },
      },
    },

    // The billing cycle anchor with the newly updated quantity
    2: {
      billing_cycle_anchor: "phase_start",
      items: {
        0: {
          quantity: "2",
          price: "price_xxx",
        },
      },
    },
  },
}
maiden cove
#

Ok, let's give this a whirl

austere stagBOT
maiden cove
#

Ok, this was my request: req_zr84pTPQcuXrIo

#

This is the subscription ID

#

sub_1OIO3OBIn9tGMHjLtWqJQqPH

naive forge
#

Hi @maiden cove I'm taking over this thread

maiden cove
#

👍

naive forge
#

Can you tell me the problem that you want to solve?

maiden cove
#

Yes. I created this subscription (sub_1OINKMBIn9tGMHjLnhDjXQUk) to start immediately (test clock date of Dec 7) with the billing_cycle_anchor of 1/1. I advanced the clock to Dec 14 and updated the subscription quantity with the proration_behavior of always_invoice this did what I expected of immediately invoicing the customer for the pro-rated amount and will next invoice the customer on 1/1 for $37.50.
What I'm looking to achieve is the exact same results with subscriptions that are scheduled in the future.

naive forge
#

OK, have you tested it out with the schedule that you created?

maiden cove
#

I did try the example that river posted, but that didn't work, I'm not sure if my timestamps were correct

naive forge
#

What didnt work?

maiden cove
#

I was expecting the proration to charge immediately, however it did not

#

Customer ID: cus_P6bCkEVZNcf4TL

naive forge
#

Based on the schedule that you created, the first phase should ends at 2024-03-01 04:06:00 UTC and when the 2nd phase kicks in, you want the subscription to generate an invoice immeidately, is it what you want to achieve?

maiden cove
#

Part of it. If we update the quantity before the end of the first phase, I would like an invoice generated for the prorated charges from the update timestamp to the end of the phase

#

Like with this subscription: sub_1OINKMBIn9tGMHjLnhDjXQUk

naive forge
#

Isn't this the changes that you want to make?

#

It's also reflected in your Dashboard

maiden cove
#

Yes. The quanity did update, however the proration charges are not for the time of Feb 19th - Apr 1 and they didn't charge immediately

naive forge
#

Ok, you made a few updates to the schdule

maiden cove
#

I'm going to have to tackle this in the morning. I'll reach out tomorrow if I'm stuck