#anthonyg-subscriptions

1 messages · Page 1 of 1 (latest)

upper harbor
spice patrol
#

sub_sched_1Jpxd2K4OwuAC0l73kh1CkIW

#

I set this up to only bill 2 iterations and want to confirm that the date and time difference between the start date and what's showing as the end date won't cause a third installment to bill.

upper harbor
#

Hello! give me a few minutes and I can get to your question

spice patrol
#

Sure thing, thanks

upper harbor
#

Yes, I believe this subscription would bill when the subscription is created, and one more time when it's renewed. After that, it'll cancel itself

spice patrol
#

So when it says end date is July 3rd at the specific time, is that when it would cancel the sub, or will it cancel as soon as the second installment processes (I setup a second phase on the schedule to reset the anchor date to Feb 3rd)

upper harbor
#

It'll cancel as soon as the second phase is over - so on July 3rd

spice patrol
#

Reason I ask is because I also setup some sub schedules without a second phase reset anchor date and it's only set to bill once, but I'd prefer that it cancel the sub before the 1 year mark of Oct 29th, so what can I do there?

#

sub_sched_1JpxZkK4OwuAC0l7GYdxXoSy

stiff inlet
#

@spice patrol can you clarify why you want to do that?

#

why not end the period on the date you want it to end?

spice patrol
#

Well because the start date. It's set for today so if it is an annual subscription with one installment the schedule is set to cancel on Oct 29 next year.

#

I'm not using dates to start and end sub schedules, but iternations and the end date gets automatically set.

stiff inlet
#

Sure but that's the case where you have a schedule that bills for a year and stops. Earlier you said

Reason I ask is because I also setup some sub schedules without a second phase reset anchor date and it's only set to bill once, but I'd prefer that it cancel the sub before the 1 year mark of Oct 29th, so what can I do there?
doesn't that mean you want to cancel before Oct 29? If so, that's before a year is done, so you'd need to set the end of the period explicitly (and we'll prorate)

spice patrol
#

Right, which is actually the thing I'm trying to avoid--proration. We don't prorate anything. It's just an installment plan for our customers. So, I guess I need to modify the schedule to reset the anchor now (the sched / sub is active at this point) or how can I change when it ends?

#

I want it to cleanly just stop the billing at a certain point before we restart their billing for the next year. It's a school year program, so it gets stopped in like July and resumes in October.

#

I set the phases to not prorate fyi

stiff inlet
#

I'm sorry I do not get it at all 😦

#

If it's an installment plan, it charges monthly, right? so why did you talk about a year?

#

Can you give a concrete walkthrough of when you charge and when it stops exactly with exact amounts and dates?

spice patrol
#

We don't prorate our services. We have three "installment plans" for an annual tuition. They can choose to pay monthly, twice a year (or what we call seasonally) and annually (so all in one payment). I just wanted to set up the schedules so that the subscription for our annual installment people cancels the sub on July 3rd (which is when our monthly accounts also stop since we have a separate summer program that begins payments in July and August). We have a month off of billing anyone in Sept, so all accounts for the new school year begin in October. Let me know if any more detail needed.

I want to make sure that all subs cancel on July 3rd and don't prorate because of some time difference between when I started the schedule today and the end date. So this schedule sub_1JpyRNK4OwuAC0l7N8izCC7j ends at 11PM UTC on July 3rd, 2022 and started at 5PM UTC Oct 29th, 2021. Will it stop with no prorations left to the account in July 3rd. This schedule sub_1JpyRtK4OwuAC0l79h2JQxhb ends 5PM UTC Oct 29th, 2022 and started 5PM UTC on Oct 29th, 2021.

stiff inlet
#

So this schedule sub_1JpyRNK4OwuAC0l7N8izCC7j ends
That's a subscription id not a subscription schedule id

spice patrol
#

Sorry it converted to a sub since this chat started as the sub went live at 12PM CST. Same dating etc applies.

stiff inlet
#

I'm so sorry, lots of conversations in parallel so really hard to grasp yours and having to manually dig into every object and revert them in my head is a bit costly

#

Can you give me one concrete example, just one, of a payment flow. When it creates, which exact date it would charge, and when exactly it would cancel

#

Like

Oct 29: $100
Nov 29: $100
Dec 29: $100
Jan 3rd: cancel, no prorate

#

something like this

#

@spice patrol did what I ask make sense?

simple dust
#

Hi @spice patrol, just checking in, are you good or do you still have questions?

spice patrol
#

Yeah, I just had other things needing tended to here. So my questions are really about how stripe will handle the sub / sched in terms of the time diff between start and end. So here is the two examples above again, in the format that you just typed them:

Example 1: 2 Installments
Oct 29, 2021 5PM UTC: $100
Feb 3, 2022 11PM UTC: $100
Jul 3 2022 11PM UTC: cancel (will this prorate???)

Example 2: 1 Installment
Oct 29, 2021 5PM UTC: $100
Oct 29 2022 11PM UTC: cancel (will this prorate???, How best to change the cancel date to Jul 3, 2022???)

simple dust
#

I believe those will prorate if you configure them to, and they won't if you don't, but maybe I'm misunderstanding the question?

spice patrol
#

I set the phases in the schedule not to prorate, so I guess it's less of a question of will they prorate and more will there be a 3rd installment billed on Jul 3 given the time difference between start and finish? I used iterations to setup the schedule and put 2 in, wanting it to be Oct 29 and Feb 3 and stop, but will the time difference between the stop and the start date as shown above, given that the plan the subscription has on is set to every 5 months, cause a 3rd payment to charge on Jul 3, 2022. Is it no because the second phase started on Feb 3 11PM UTC?

With the second example, so how best to get the cancel date moved back at this point from Oct 29, 2022 to Jul 3, 2022 given that the sub is managed by a schedule?

simple dust
#

There are too many moving pieces there to say for sure without looking at an actual Subscription Schedule.

spice patrol
#

Is there a place in the dashboard to quickly grab the schedule id from the sub page?

simple dust
#

Yeah, if you scroll down to the bottom the Events section should have an event called "A subscription schedule was created" which you can click on to get the Subscription Schedule ID.

spice patrol
#

Example 1- 2 installments: sub_sched_1JpxdrK4OwuAC0l7BqqGyRmn

#

Example 2 - 1 Installment: "sub_sched_1JpxcAK4OwuAC0l7ibLAg1Tg",

simple dust
#

Looking at the first one...

#

Have you tried that approach?

spice patrol
#

I did use iterations, I thought!

#

Where are you seeing that I didn't? Or why?

simple dust
#

Let me check again...

#

Oh, sorry, I see it now.

spice patrol
#

I reset the anchor date on the second phase since we bill always on the 3rd of the month

simple dust
#

Second phase? I'm only seeing a single phase when you create the schedule.

#

Looking at just that creation request, that will only charge the Customer once since you have iterations set to 1.

#

I'm also not seeing anything about the billing cycle anchor there.

spice patrol
#

Oh if the second example sched then yeah that's right, just one payment so no second phase.

simple dust
#

No, I'm only looking at the first one right now.

#

sub_sched_1JpxdrK4OwuAC0l7BqqGyRmn

#

If you look at that request in your Dashboard using the link above it only shows you specified a single phase.

spice patrol
#

Ah ok, that must be example 2 then, not 1, sorry I grabbed the id's in reverse!

simple dust
#

So let's back up a bit and focus on only one single scenario. As I understand it you want this behavior/timeline:

On Oct 29, 2021 you create a Subscription Schedule that immediately creates a Subscription that bills your customer $100.

On Feb 3, 2022 you want to bill them again for another $100. This will be their final payment.

Is that correct, or am I missing anything?

spice patrol
#

Yeah, that's correct for the Example 1 scenario. Here's a sub id representing that "sub_sched_1JpxdgK4OwuAC0l7Wyc9yieH"

stiff inlet
#

I'm back, let me have a look, thanks for the detailed write up this really helped

#

for example the fact that you don't have what we call "natural boundaries" for phases is problematic

spice patrol
#

What are natural boundaries?

stiff inlet
#

You have a monthly plan and it charges every month on the same day/hour

#

like Oct 29, Nov 29, Dec 29, etc. You don't seem to do that at all, you have "random" intervals and random end dates not matching the duration of the price's recurring schedule

spice patrol
#

What interval are random that we have? Or can you explain what you mean by "random"?

stiff inlet
# 

On Feb 3, 2022 you want to bill them again for another $100.  This will be their final payment.

Is that correct, or am I missing anything?```
#

This is not a monthly, weekly, yearly, bi-monthly, or anything like that, schedule right?

spice patrol
#

No you're missing something.

stiff inlet
#

You are trying to fit "recurring periods" into "ad-hoc/sporadic one-off charges"

#

ah okay

spice patrol
#

Our payment schedule is super rigid. We bill only on the 3rd day of the month for any of our 3 instalment plan options to customers. The start date though is sometimes not that date. If we're ready to bill them between installments we run them the day it is and then reset the billing anchor to the 3rd.

#

One of the big challenges we've had with Stripe, and what's problematic, is that Stripe doesn't really fully support our billing model, which isn't so much subscription based but payment plan based, which is another issue. Hoping one day this is improved.

stiff inlet
#

we do support payment plans though

spice patrol
#

There's some wonkiness to it for us, but that's for another day. The options for setting up product plans is more geared towards each sub being on it's own time frame, and not on a template so to speak.

#

Would be great for us to be able to create a sub sub schedule template that simply says bill this many installments on this date at this time, and be able to add customers to it and select the product(s) that go on that schedule.

stiff inlet
#

Sorry, I know it can be exhausting to repeat things, but you're also quite far down a rabbit hole/approach I don't understand at all

#

Usually when you want installments on the 3rd of the month, but charge upfront without proration for the current month, you use backdate_start_date for example

#

But anyways, I digress and I should try to help you fix the flow you want. So waht is blocking you/what do you need me to confirm exactly?

spice patrol
#

Man, it would be nice to be able to share the screen to show things. Would save so much time.

#

I wasn't aware of a backdate_start_date. From what I read in the api guides the way to handle starting at a date that's not what you want the ahcnor date to be was to start the sub right away and then just update the anchor date or create a secon phase. I've tried to follow the Stripe guides as best as possible for how we need to do billing for our clients.

stiff inlet
#

there are thousands of params and APIs so we can't really document all of them everywhere

#

but it does look like what you want is backdate_start_date right?

spice patrol
#

I don't know I'd have to look at it.

#

No not really. that param doesn't help us. Because we don't prorate stuff like Stripe has it setup. We have our own method or proration that hasn't been easy to see how to setup in the Stripe construct. Anyway, we also couldn't use this if setting up on a schedule either it seems, unless it can be applied to a schedule.

#

Stripe prorates by time essentially, and we do it by class credit essentially.

#

So having to work around Stripes tendency to prorate subs that don't start or end at exactly the same time internal has been really tough for us.

stiff inlet
#

(sorry talking to rubeus on my end to align, give us a bit of time)

#

@spice patrol Let me write another example because I still don't really get it.

My read of your plan is this: someone owes you $100 a month, for multiple months sequentially, until it stops. If they start mid-month for the first payment, you want the full payment, and then you start charging next month on the 3rd.

Oct 29: $100 for October even if only 4 days left
Nov 3: $100 for November
Dec 3: $100 for December
... repeat ...
May 3: $100 for May, last month to pay
June 3: cancel automatically

But Rubeus says you are charging yearly and instead you want this
someone owes you $100 a year, for multiple years/forever. If they start mid-year for the first payment, you want the full payment, and then you start charging next year on the same anchor for everyone, say February 3rd
Oct 29 2021: $100 for 2021+
Feb 3 2022: $100 for 2022
Feb 3 2023: $100 for 2023
Feb 3 2024: $100 for 2024

spice patrol
#

Totally correct on the Monthly installment plan scenario. On the Annual installment plan scenario, we do not bill them forever. We need the sub to stop at the end of the school year, which aligns with the Monthly installment scenario date of Jul 3, even if the sub starts Oct 29 or whenever and one payment is made. Does this make sense?

#

WE have one other Seasonal installment plan that is two payments, works the same as the above though, just that the first payment is due whenever we confirm we can start billing them and then again on Feb 3rd, and then cancel Jul 3.

#

Everybody regardless of installment plan stops on Jul 3

stiff inlet
#

yep let me mull it over for a bit (sorry lots happening)

spice patrol
#

No problem, working on a million things here myself!

stiff inlet
#

@spice patrol okay really sorry, things got busy and I assume you're out now! Here's what I would do for the first example if it were me

1/ Create a Subscription to the $100 monthly price today but with backdate_start_date set to the 3rd of this current month and also pass billing_cycle_anchor to the 3rd of next months. That way we charge for the full amount now.
2/ Create a Subscription schedule from that existing Subscription
3/ Change the Subscription schedule's phase to control the number of iterations you want, which maps to the number of months left until the end of your "season"
4/ This will automatically charge the customer on the 3rd of every month for X months and then cancel at the end.

That seems to map exactly what you wanted for the first part. This is a lot more steps, because the Schedule API doesn't support backdating today.

#

For the second example, it's basically the same except your Price has a different interval. It's 5 months long for Feb 3rd - Jul 3rd. So I think you could do the same logic, just backdate_start_date is 5 months ago maybe?

#

Lastly: you need to handle the horrible edge-case of someone paying on November 2nd at 6pm, and literally paying $100 now and $100 6 hours later on the 3rd

spice patrol
#

It's sad, but these days, I'm always at my desk! Thanks for this further info about another way to set things up. I will definitely look at this to see about using it. Currently we run the setup manually using a script, as opposed to allowing customers to get signed up when they submit a registration form or something, but soon we are going to start billing out the first payment at the point of signup, so this approach may come in real handy.

So is the backdate_start_date going to eventually be available directly on sub schedules? Any time frame? I guess the extra steps are really just creating the subscription first to get the backdating right? Otherwise it's pretty much what we're doing now I think.

So, this leaves the question of whether right now for any of my subs that don't have the date aligned properly whether I need to adjust them in some way to make them only charge either the one payment already made, or the two payments.

stiff inlet
#

So is the backdate_start_date going to eventually be available directly on sub schedules? Any time frame
Candidly, I'd say no, not any time soon. I will file it though but that is a pretty advanced feature on top of subscription schedules which are quite advanced.

#

So, this leaves the question of whether right now for any of my subs that don't have the date aligned properly whether I need to adjust them in some way to make them only charge either the one payment already made, or the two payments.
I think your subs are set up right, but the best option is to test this in Test mode, you shift the date, you wait for the renewal to confirm for sure and you confirm it charges the amounts you want.