#idfk_subs-migration-long-billing-cycle

1 messages ยท Page 1 of 1 (latest)

hollow quarryBOT
#

๐Ÿ‘‹ Welcome to your new thread!

โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

๐Ÿ”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1313968986995560468

๐Ÿ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

forest cypress
#
    [
        "items" => [
            [
                "price" => $currentPrice->id,
                "quantity" => 1,
            ],
            "description" => $emailOrDomain,
            "metadata" => $metadata,
            "end_date" => strtotime('+1 years'),
            "proration_behavior" => "none",
            "collection_method" => $collectionMethod,
        ]
    ],
    [
        "items" => [
            [
                "price" => $currentPrice->id,
                "quantity" => 1,
            ],
            "description" => $emailOrDomain,
            "metadata" => $metadata,
            "end_date" => strtotime('+2 years'),
            "proration_behavior" => "none",
            "collection_method" => $collectionMethod,
        ]
    ],
    [
        "items" => [
            [
                "price" => $currentPrice->id,
                "quantity" => 1,
            ],
            "description" => $emailOrDomain,
            "metadata" => $metadata,
            "end_date" => strtotime('+3 years'),
            "proration_behavior" => "none",
            "collection_method" => $collectionMethod,
            "billing_cycle_anchor" => "phase_start", 
        ]
    ]
]
tulip fiber
#

Hello, just to make sure I understand your ask, are you basically trying to set it so that these new subscriptions cycle when your old subscriptions from your other processor would cycle? Or something else?

forest cypress
#

I was thinking of using phases to allow a subscription to run until a specific date before it sends an invoice or charges automatically.
Our system relies on the subscription existing and beign active in order to operate. So I was thinking of using Phases to show their tier until that date.

#

Since I cannot set the end_date beyond the natural interval of the price, I planned on creating phases to show that they have been paid for until an a date set in the future, say 2029-01-01

tulip fiber
#

Gotcha, I ask because it is possible to backdate our standard Subscriptions without using a schedule, which can be less overhead. So if the goal is to start a subscription for someone who is 6 months in to their subscription and not bill them for another 2.5 years, then that is possible though avoiding the first payment might be a bit tricky.
Otherwise, can you explain to me what the first two pages of that schedule are doing? I am not quite getting it when reading your description

forest cypress
#

req_Q4VbkJwxhXjznI
In this case, we have a 3 year interval on stripe. We have them prepaid until 2030-05-23. It appeared as if we'd need a phase to handle this case

tulip fiber
#

Ah gotcha, so in that case you would need a subscription schedule. So do you basically want the first phrase to be until 2025-05-23, then go to three year billing, and then not actually charge them until 2030-05-23?

forest cypress
#

yes

#

I guess it would be
Present (or backdated) - 2027-05-23
2027-05-23 - 2030-05-23

tulip fiber
#

Gotcha, so I think the easiest way to do this would be to define a $0 price with a 3 year interval, then create a subscription schedule where the phases are:

  1. $0 price - end_date=2027-05-23
  2. $0 price - iterations=1 (iterations tells us to go one full cycle and then transition to the next phase, it means you don't have to calculate leap days and seconds and such)
  3. Your normal 3 year price
    And you can set the schedule's end_behavior to release which tells the schedule to detatch itself from the subscription when it gets to that last phase
#

Is that helpful? Or did I misunderstand what you are looking for help with?

forest cypress
#

Is there a way to do this without creating another price object?

#

I only ask because we have features tied to the lookup_keys as well and about 178 products

tulip fiber
#

Gotcha. The two ways that I know of would be to apply a 1 time 100% off coupon to the first two phases or to add credit notes for the amounts that the user would be charged. Calculating the amount to credit for the first phase might be a bit tricky, I think the typical way to do it is to use our upcoming invoice API I can go in to more detail if you are considering that route.
https://docs.stripe.com/api/invoices/upcoming
Though now that I think about it, the easiest way to do this could be to just not start the subscription until 2030. You could set the start_date and then have your provisioning logic check for subscription schedules as well as active subscriptions. If the customer has a subscription that hasn't started yet you can provision access
https://docs.stripe.com/billing/subscriptions/subscription-schedules/use-cases#start-subscription-future

forest cypress
#

full dollar discounts or 100% discounts wouldn't really work either as we offer the ability to upgrade/downgrade, and if they move up or down a tier they would essentially get the upgrade for free

tulip fiber
#

Gotcha, in that case I think the $0 price or the 2030 start date could be viable for you here, though it sounds like none of these options is especially stellar.

forest cypress
#

Yeah sales team kind of shot ourselves in the foot here

#

I think the future subscription is best bet though, thanks.

#

Though it does add a complication of how we charge prorated upgrades/downgrades

tulip fiber
#

That is a good point. I will consult my colleagues on if there is a better way to do this that I am not thinking of and will get back to you.

forest cypress
#

Thanks

heady oasis
#

Hi ๐Ÿ‘‹

I'm stepping in as my colleague has to go.

#

I'm trying to think through how we could model the upgrades/downgrades.

#

3 years is a long time over which things can change

forest cypress
#

We also do have monthly and annual subscriptions

heady oasis
#

So you could represent the current (paid) billing cycle as a trial and have Stripe begin invoicing your customers at the end of that phase.

#

As for the upgrade/downgrade.

forest cypress
#

so a 5.5 year trial

heady oasis
#

I agree it's not ideal. Another, more convoluted and dangerous, approach might be to create Subscriptions that should bill the customer. But, prior to that, you generate Customer Credit notes that reduce their liability

forest cypress
#

what makes it dangerous? Miscalculating the credit amounts?

heady oasis
#

The fact that, if you get the credit piece wrong, it would charge the customer for the full amount they already paid

forest cypress
#

Ah i understand

#

Yeah i'm thinking trial days, then a webhook to just alert us if someone upgraded on trialing with a future subscription set..

heady oasis
#

That is why I strongly encourage building end-to-end test scenarios to verify expected behaviors

#

Our Test mode lets you build complete billing integrations and simulate advancing time so you can be sure the subscription will behave as you expect

forest cypress
#

Yeah been monkeying around in there

forest cypress
#

Thanks - i think the trial period will work to our use case

heady oasis
#

Okay. As for prorations, do you want those applied to the invoice in 5.5 years or billed immediately?

#

I was thinking you could use Customer credits for downgrades but we also allow you to add one-off InvoiceItems to the next Invoice that the Subscription generates and that might be a good way to capture upgrades

forest cypress
#

Ideally we would collect immediately, otherwise we would potentially lose on collecting it

heady oasis
#

Hmmm... In that case would it make sense to end the trial and use a custom price to represent the prorated amount?

forest cypress
#

we rely on the price objects to determine service and upgrade paths with metadata. We cannot rely on that with our design

heady oasis
#

Okay so that wouldn't work.

forest cypress
#

oh interesting

#

yeah that would be good to use

heady oasis
#

It might allow you more freedom in terms of adjusting Prices to match what you need to charge your customers

forest cypress
#

Yes, it would remove the rigidity we put on ourselves with the prices

heady oasis
#

I realize it's a significant shift so not something that would get implemented over night but it might be worth investigating.

forest cypress
#

Yeah it's pretty handy - we'd need to handle the price lookups somehow though

heady oasis
#

Yes that makes sense. Could you possibly use Stripe Prices to set/track what you are charging (prorations and such) and track the actual prices through metadata on either the Stripe Price or Subscription?

#

I'm just trying to think through all potential ways to address this

forest cypress
#

I think so

#

I think for the time being i'll just put them on trial basis -- anyone who upgrades in that time will be handled by hand until we sort out entitlements and prorations

heady oasis
#

Okay, I think that sounds like the most straight forward way to handle this