ninjesus-schedule

[neon pier]

hi! let me think about it/test for a while. Do you happen to have the code you're using to create the schedule or the ID sub_sched_xxx of one of you created too so I can compare?

[wise frigate]

here is the sub schedule sub_sched_1LHxfqQ69qZCyjRMrBx0ncor

and with the post request : req_vnehpYd8HebHC8

It is a sub sched I created to reproduce my client problem, I might also find the sub schedule of my client in production

here is the schedule in production
sub_sched_1KxMwwPiPEoGsbqwviHk9Ks2
req_20VYvnN5Wl8a6j

[neon pier]

that might help. I'd have to test this with some test clocks to see what actually happens. I know coupons and schedule phases have some edge cases; will take a look and come back to you

[wise frigate]

ok thanks I'll stay online you can tag me here

I'm thinking that maybe the fact that it is a "once" coupon, and that the transition between consecutive phases is flagged as "no change" to the subscription, as the same coupon is applied in next phase, it just considers that the coupon has already been applied on a payment since previous change and it is ignored ?
maybe my phrase is not clear ahah

[neon pier]

yeah I do think that is it, to be clear.

but then the question is how to accomplish what you want.

which I suppose would just be to use a coupon with no duration limit, apply it within one phase, and then in a subsequent phase ,pass coupon:"" to remove that coupon.

like I'm fairly sure that's the answer, just it will take a bit of time to set up a test

[wise frigate]

yes I understand that trick would technically do the job, but one the UX end for my users, it will be a mess, I don't want to make them understand that they should set an unlimited coupon with a time limit.

even if it seems pretty easy to understand for an engineer or a developper, my clients are sports club managers, and it is wayyyy more natural for them to choose a coupon they already have created, and to repeat it for several months

[wise frigate]

no problem 🙂

[neon pier]

to be clear, don't you control the UX? you're calling the API for them but you can likely present this on the frontend in a way that make sense for them.

sorry for the delay, I'm basically at the point of confirming your hypothesis using clocks, even if I pass my coupon on each phase only the first one gets discounted, yep. So I guess what I have to try to figure out now is what your alternatives are

[wise frigate]

no worries for the delay, it was quite fast 🙂

[wise frigate]

I guess my main alternative is the one you discussed above.
but I have to prevent them to try to repeat the same "once" coupon for consecutive subscription periods. and this will be kind of messy, UX wise.

is Stripe likely to fix the bug ?

or another way is to create a new coupon with exactly the same settings, it should work

I mean, automatically duplicate the coupon in the backend so the user thinks he is using his original coupon, and stripe think it is a new coupon so it applies on the next phase

you can test with a testclock if you still have your setup ready ?

I saw that if I do so, I see the removal and the replacement of coupon in the phase transition in the stripe dashboard UI

[neon pier]

I'm not convinced it's a bug really.

In any case, what works for me is what I mentioned, using an always-coupon and then unsetting it later :

    [
      "start_date" => $subscription->current_period_start,
      "end_date" => $subscription->current_period_end,
      'coupon' => 'Ojzihwhl', // 25% off, added here, applies to next invoice
      'proration_behavior'=>"none",
      'items' => [
        [
          'plan' => $silver->id,
          'quantity' => 1,
        ],
      ],
    ],
    [
      "start_date" => $subscription->current_period_end,
      "end_date" => 1669381871,
      'coupon' => 'Ojzihwhl', // re-state we are still using it
      'proration_behavior'=>"none",
      'items' => [
        [
          'plan' => $silver->id,
          'quantity' => 1,
        ],
      ],
    ],
    [
      "start_date" => 1669381871,
      "end_date" => 1669381871 + 2592000,
      'proration_behavior'=>"none",
      'coupon' => 'Ojzihwhl',
      'items' => [
        [
          'plan' => $silver->id,
          'quantity' => 1,
        ],
      ],
    ],
    [
      "start_date" => 1669381871 + 2592000,
      'proration_behavior'=>"none",
      // remove coupon by omitting it here
      'items' => [
        [
          'plan' => $silver->id,
          'quantity' => 1,
        ],
      ],
    ],
  ],

[wise frigate]

yes of course that works in this way, but setting the same "duration=once" coupon to two different phases should work as intended IMO

[neon pier]

maybe! I honestly don't know, this is a complicated area and I don't know what the intended behaviour would be

we did have a number of bugs with coupons and phases that have been fixed when schedules were being launched in the first couple of years, there might be something off here but I don't think I know enough to say for sure without having more eyes on it

[wise frigate]

ok thanks for your honesty 🙂
and do you think putting two differents coupons with the same settings (duration=once, same percentage) on two successive phases would work ?

(it is easier for me to just detect that the coupon is the same as previous phase and to duplicate it so it has a different stripe id)

[neon pier]

I tried it quickly just now and it seems to work

[wise frigate]

ok thanks 🙏 I'll do this way