#PyroFiire

1 messages · Page 1 of 1 (latest)

wide templeBOT
tidal void
#

I buy a 3-month subscription on 11/10/2023, the end date is 11/01/2024.
I change offers several times and the next payment date is always 11/01/2024.
I finally decide to take out a 1-month subscription.
In the Stripe back-office, the new phase is created. The price change and the next direct debit are indicated.

#

I advance the time to 18/01/2024
Result:

  • The customer is debited on 11/01/2024 for 1 month. Perfect.
  • The payment_intent.succeeded and customer.subscription.updated events are triggered. Perfect.
  • The next debit date is therefore 11/02/2024. Perfect.

I change the offer again and there's an error:

When I select 3 months, the next debit date automatically becomes 18/07/2024.
When I select 6 months, the next debit date automatically becomes 18/10/2024.

The next debit date should not change when I change subscription again, it should be 11/02/2024.
I can see in the Stripe back office in the subscription summary that the next invoice is in "Immediate billing".
It looks like this has directly modified the current phase instead of creating a second phase.

thorn inlet
#

can you share the code you're using to create and update the SubscriptionSchedule that replicates this issue?

tidal void
#

What am I doing wrong? The code is the same in both cases. It's as if the subscription no longer had exactly the same parameters when the next phase began.

As I'm writing to you, I realize that for the second time I'm using the same Schedule associated with the subscription, which I'm modifying. Should I delete the Schedule associated with the subscription when it moves on to phase 2?

Thanks for your help

thorn inlet
#

It looks like this has directly modified the current phase instead of creating a second phase.
probably you don't realise that you need to continue to specify all the existing phases when calling the Update SubscriptionSchedule API, that is a common mistake.

tidal void
# thorn inlet can you share the code you're using to create and update the SubscriptionSchedul... 
        // Create subscriptionSchedules from subscription if not exist
        $schedule = $stripe_subscription->schedule;
        if (empty($schedule)) {
            $schedule = $this->stripeService->getClient()->subscriptionSchedules->create([
                'from_subscription' => $stripe_subscription->id
            ]);
        }
$phases[0] = [
            'items' => $current_phase_items,
            'start_date' => $schedule->phases[0]->start_date,
            'end_date' => $schedule->phases[0]->end_date,
            'proration_behavior' => 'none',
            'collection_method' => 'charge_automatically'
//            'billing_cycle_anchor' => 'phase_start'
        ];
$phases[1] = [
            'items' => $next_phase_items,
            'start_date' => $schedule->phases[0]->end_date,
//            'end_date' => $schedule->phases[0]->end_date,
            'iterations' => 1,
            'proration_behavior' => 'none',
            'collection_method' => 'charge_automatically',
            'billing_cycle_anchor' => 'phase_start',
        ];
        // Update the schedule with the new phase added or removed
        $this->stripeService->getClient()->subscriptionSchedules->update($schedule->id, [
            'phases' => $phases,
            'proration_behavior' => 'none',
        ]);
#

this is pretty much the code I use, I've removed some parts for easier reading

tidal void
thorn inlet
#

I still don't completely understand the issue. Do you have a sub_sched_xxx ID where this problem happened that I can look at?

tidal void
#

So the second time I have to specify phase 0, 1 and 2?

thorn inlet
#

every time you update a Schedule, you are "declaring" or "describing" exactly what phases exist. You're not adding new phases, you are "declaring" the entire set of all phases that now exist

tidal void
tidal void
thorn inlet
#

i.e. if you have a schedule like
phases:[
{price:A, iterations:1}
{price:B, iterations:2}
]

and you update like this:
phases:[
{price:C, iterations:3}
]

you are not making it so that A and B happen, and then C happens; instead you are saying that only C exists

#

I don't know what "And from the cup" means.

tidal void
tidal void
thorn inlet
#

I think so yes

tidal void
#

Otherwise, I had the idea of deleting the schedule once the next phase had passed. Is this a good idea?

thorn inlet
#

I think deleting the schedule and creating a whole new one would make this more complicated and introduce more oppurtunity for problems/bugs

tidal void
#

the difference between the first change of plan and the second is that in the first, the schedule has not yet been used and is created from the subscription, then in the second change, the schedule associated with the subscription is reused.

thorn inlet
tidal void
#

You can see the difference in the two screenshots I sent you above. In the summary tab on the right.

#

I think it's because this box is checked the second time.

thorn inlet
#

I don't speak French unfortunately so it's really hard for me to understand

thorn inlet
tidal void
#

yes I do use the api, I'm trying to show you what changes in the dashboard.

#

It's best to look at the difference between the first two screens.

#

In fact, the second time around, the next phase is not created. I'll try to understand why

thorn inlet
#

can you share the two Subscription IDs sub_xxx that correspond to the two screenshots?

tidal void
thorn inlet
#

but then I don't understand, how do you get two different screenshots from the same subscription? did you update it once, take a screenshot, then update again, and take a new screenshot?

tidal void
#

Yes, that's it. I changed my offer once, moved forward in time, then changed my offer again and I don't have the same result.

#

Take a look at my example. I've tried to be as detailed as possible.

#

At the beginning of this conversation

thorn inlet
#

I know, and I appreciate that. Unfortuantely I just don't understand

tidal void
#

I'd say it's the next payment attempt (next_payment_attempt). The first time it stays the same, but the second time it changes when I change the offer.
The next payment date shouldn't change when I change offer. (It does the first time, but not the second).

thorn inlet
#

there's no such thing as next_payment_attempt on the Subscription or SubscriptionSchedule.

I think what you mean is the billing_cycle_anchor ? The date that the subscription will process its next charge?

tidal void
#

yes it is

thorn inlet
#

if so, in your code above you can see you are explicitly passing 'billing_cycle_anchor' => 'phase_start'

That means, when that phase starts, the subscription immediately bills, and then this date(the time the phase starts) becomes the billing date for future months on the Subscription.

is that the issue?

tidal void
#

Yes, I think so, the way you describe it. I'll do the full test again without it and I'll tell you right now 🙂

thorn inlet
tidal void
#

Yes, because what I'd like is for the billing date not to change, but to correspond to the end of the previous period.

#

what's strange is that the first time it works well despite this parameter. I'll test it and let you know.

#

Thanks

wide templeBOT
tidal void
#

ok I put a stop point on the SubscriptionSchedule object the second time before modifying it. And what I notice is that phase 0 and 1 exist. There are always 2. Whereas in the back office there's only one. I thought that phase 1 had become phase 0 and that phase 1 no longer existed, but that's not the case.

#

You said that:
You probably don't realize that you have to keep specifying all the existing phases when you call the Update SubscriptionSchedule API, it's a common mistake.

And that seems to be my mistake.

thorn inlet
#

yeah, it's a very confusing API unfortuantely

tidal void
#

What's really misleading is the fact that phase 0 is no longer visible in the back office, even though it still exists in the object, and that you have to fill in all the phases again when you modify it.

#

Is there a quick way to find out what the current phase is without having to go through all the phases and make conditions with the dates?

dense ravine
#

Hello 👋

tidal void
dense ravine
#

My understanding is that phase 0 is always the current phase

tidal void
#

I've just tested it and it turns out it's not. I recovered the Object Schedule after switching to the second phase. I still have two phases in the object and the current one is phases[1] and not phases[0].

dense ravine
#

Interesting. Let me double check

tidal void
#

So, in my case, I'm going to pay close attention to whether the last phase of the table has already passed or not, and add a new one if it's the current one, otherwise replace it.

#

i have the id if you want

#

sub_sched_1O01vZIXNywFBsoWRerTGcw7

dense ravine
#

Yeah I believe you're right, i must be thinking about something else

tidal void
#

Ah great, thank you very much! I hadn't seen that I could retrieve schedule.current_phase directly.

I was going to go through all the phases and compare with today's date 😅