#kabob-schedules-update

1 messages · Page 1 of 1 (latest)

quartz pikeBOT
#

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.

umbral wharf
#

HI 👋

Taking a look

#

So, just so I'm clear, when you do this with a plain Subscription you get the behavior you expect?

lyric musk
#

Yes. The first subscription ID provided shows that

umbral wharf
#

And for the Subscrpition Schedule, can you share the ID for the API request you made to create this change?

lyric musk
#

Sure, one sec

#

req_r72FWGkJfncKEk

umbral wharf
#

I am seeing the phase you specified being added here

 {
      add_invoice_items: []
      application_fee_percent: null,
      billing_cycle_anchor: null,
      billing_thresholds: null,
      collection_method: null,
      coupon: null,
      currency: "usd",
      default_payment_method: null,
      default_tax_rates: []
      description: null,
      end_date: 
1711947600
,
      invoice_settings: null,
      metadata: {}
      on_behalf_of: null,
      plans: [
        {
          billing_thresholds: null,
          metadata: {}
          plan: "price_1OH6bgBIn9tGMHjLEjms2skd",
          price: "price_1OH6bgBIn9tGMHjLEjms2skd",
          quantity: 5000000,
          tax_rates: []
        },
      ],
      prorate: true,
      proration_behavior: "always_invoice",
      start_date: 
1707927600
,
      tax_percent: null,
      transfer_data: null,
      trial_end: null,
    },
#

But it is after an additional phase with a quantity of 0

lyric musk
#

So. when that schedule was created it was created with a quantity of 0.

umbral wharf
#

Right but you are also passing another phase with a quantity of 0 to run from 2/14 to 4/1

#

I know you have an end date of now but that's not how Sub Schedule phases work

lyric musk
umbral wharf
#

I think you will get the behavior you expect if you exclude the first phase

lyric musk
#

Let me try that

#

So, before I try the update, this is the ID of an example schedule that will require update: sub_sched_1OJfhWBIn9tGMHjL1PwXx0nV

#

I'm going to advance the time to an example future date that we'll look to update the quantity

#

Here is the most recent request ID: req_RxsqXbjxOlg5ET

#

The previous help person I spoke with stated that I needed to insert a phase that ended at the current time with a quantity of 0 to stop the 0 billing and create new phase from current to the start of the last phase with the quanity that we're wanting to set

umbral wharf
#

Did that get you the behavior you expected?

lyric musk
#

It did not: it created a pending invoice item instead of immediately charging and the amount is for the proated for 2/14 - 5/4 and not 2/14 - 4/1

umbral wharf
#

Sorry it's still hard to parse what exactly is the behavior you are trying to create here

lyric musk
#

I understand, it's a complex situation, I'll try to explain:

lyric musk
#

Scenario A: create a new 3 month subscription with quantity 0, starting on 12/4/23, and billing anchor of 1/1/24. Customer is charged $0 because of the pricing tier. 10 days later, update the subscription with a quantity of 5 and proration_behavior of invoice immediately. Expected and actual behavior: Stripe immediately charged the payment method on file for the amount of remaining subscription from 12/14/23 until 1/1/24.
Scenario B: customer is on an existing monthly subscription that renews on 12/10. We submit a request, today, to create a schedule from their current subscription. We then submit another request to update the schedule:

phase 0:{
  items: {
    end_date: 12/10/2023,
    price: old_price
  },
},
phase 1: {
  items: {
    start_date: 12/10/2023,
    end_date: 1/1/2024,
    price: new_price,
    quantity: 0
  },
},
phase 2: {
  billing_cycle_anchor: phase_start,
  items: {
    start_date: 1/1/2024,
    price: new_price,
    quantity: 0,
  }
}```
On 12/14/2023, we want to update the quantity to 5 so that like in scenario A, they are charged immediately for the time remaining in phase 1 (which their schedule is in) from 12/14/2023 to 1/1/2024 and when phase 2 starts, they will be charged the new price at quantity, 5
umbral wharf
#

Okay so you need to update both phase 1 and 2.

#

and ignore phase 0 in your API request

lyric musk
#

I'm trying that now.

#

Ok, when I attempt to ignore phase 0 in my request I get an error saying that an array with key 0 was expected: request ID req_gXWeKCRhR8aVMV

quartz pikeBOT
red girder
#

kabob-schedules-update

#

You are supposed to pass that phase 1 as 0

#

it doesn't make sense to skip 0

#

Whenever you update a SubscriptionSchedule you basically have to repass every active phase with the current one starting at 0

lyric musk
#

I shift the phases array, putting 2 in 1 and 1 in 0, it's ignoring the updated start/end dates: req_iJS62TWFnuUIeM

red girder
#

There is a gap between phase 0 (1704391193, 1707069593) and phase 1 (1708538340, 1711947600).
thee's a clear error returned though.

lyric musk
#

I supply the start_date and end_date for phase 0, those don't overwrite what is there?

#
-u sk_test_... \
-d "phases[0][items][0][price]"="price_1OH6bgBIn9tGMHjLEjms2skd" \
-d "phases[0][items][0][quantity]"="5000000" \
-d "phases[0][proration_behavior]"="always_invoice" \
-d "phases[0][start_date]"="now" \
-d "phases[0][end_date]"="1711947600" \
-d "phases[1][billing_cycle_anchor]"="phase_start" \
-d "phases[1][start_date]"="1711947600" \
-d "phases[1][items][0][price]"="price_1OH6bgBIn9tGMHjLEjms2skd" \
-d "phases[1][items][0][quantity]"="5000000"```
red girder
#

ah you're right the error message has timestamps that don't match the params at all. Looking

red girder
#

sorry still digging 😦

lyric musk
#

no worries, thank you for your help!

red girder
#

Okay so we can reproduce and this looks like a bug to us too, for some reason it really doesn't like the start_date: 'now' part

lyric musk
#

I would need to send the “current timestamp”?

red girder
#

we're not sure yet, we're trying to figure it out

quartz pikeBOT
brisk kite
#

Okay @lyric musk we do think this looks like a bug as far as we can tell. We are going to file a bug report internally so that this can get a deeper look. The best thing for you to do is to write into our Support team via https://support.stripe.com/contact/login and they can keep you updated on the progress of the issue.