#stripe_connect_platform-subscription

1 messages · Page 1 of 1 (latest)

red stone
#

For the error you're getting, you are passing in a Subscription ID (e.g. sub_abc123), but the Subscription Schedule API only accepts Subscription Schedule IDs (e.g. sub_sched_abc123)

frigid flame
#

ha. ok. that one is my error.

red stone
#

I just looked over the thread you had with koopajah

frigid flame
#

but the sub has "schedule": null,

#

SubSchedule is a new thing?

#

I am concerned that this is way too complex

#

We have hundreds of upgrades to make

red stone
frigid flame
#

Can you explain the simpler option of just updating the plan/price? And what exactly the problem is that can occcur.

#

Yes, I read that

#

And i found the relevant use case

#

I don't understand what it is doing

#

We are creating a schedule for an existing sub that clearly already has a schedule no? It is just not an object that exists. But it is on a billing cycle now and I want to just keep that existing billing cycle.

#

Creating a new schedule seems like it is likely to cause major issues in that SubscriptionSchedules do not make sense to me. Did you read that doc?

#

Very hard to understand.

#

I really don't want to change any of the existing billing_cycle behaviour at all

#

Starting from zero.
What is the start date?

#

I imagine it is subscription.current_period_end

#

But it is very confusing

#

And end_behavior: is ????
How do you say "do not ever end. just be a normal recurring sub and go on for infinity until cancelled"

#

And the example doesn't show an example where you pass in an existing sub id. it jus shows the customer being passed in. I am having a hard time with that API

#

There must be an easier way to update a price.
I may just want to do this in the dashboard 300 times

#

It might be faster

red stone
#

Okay, let's take this one question at a time. This barrage of messages is going to make it incredibly difficult to actually help you

frigid flame
#

Sorry, many confusing things

#

What is the easiest way to update a price?

#

That is all I want to do

#

Keep the billing cycle, just update the price. Easy peezy.

red stone
#

You mean add a new Price to an existing Subscription, correct?

frigid flame
#

Yes, let's start there

#

proration_behavior:none

#

And i imagine just this:
"items": {
"data": [
{
"price": {
"id": "new_price_id",
}
],

#

Do you understand what error koopajah says will occur if we do that - setting it to renew at the new price if the customer then upgrades let's say to an annual plan from the monthly plan?

red stone
#

Give me a few minutes to re-read over their thread

#

I think I understand the complication they mentioned, but I want to be sure

frigid flame
#

ok

#

that may be less of an issue then trying to figure out how to make 300 SubscriptionSchedules accurately.

#

i realize that koopajah is likely a genius but I am not that smart so need to keep it simple here. 😉

red stone
#

I think it's more that Schedules are only complicated the first time you use them, but nonetheless I think I understand the issue. Are all your customers on the same billing cycle? e.g. all subscriptions are paid on the 1st of the month?

frigid flame
#

haha

#

No

#

People just sign up when they sign up over time. Every customer has his/her own billing cycle that starts the day they sign up and pay

#

i can try to do this manually and just see what happens when I upgrade and if it creates a balance or proration weirdly but if you know that would save us time

#

When i switch the sub to the new price, then upgrade to an annual before that new priced sub billing cycle ends and charges the card

red stone
#

Are you also going from monthly to yearly on this migration?

frigid flame
#

I am just updating the price

#

People on monthly are still on monthly on the same cycle

#

People on annual are still on annual on the same cycle

#

But after we run that script, customers can do what they want in the wild. Customer A may choose to go to our website and upgrade to the annual plan, for example. So I want to mock that and see what happens but that is what the customer is doing, separate from the script we want to run that just updates the price of the existing sub

#

This is a very common use case no? We are simply updating a price. I am not clear why it is so complex to do this?

#

It's Ok. I will just try to do it and go through some common flows and see what it does and come up with a plan to clean it up if the billing is not accurate if the customer chooses to switch plan before the billing cycle ends. Unless you know and can explain what this issue would be. ?

red stone
#

I think the issue alluded to by koopajah was that you didn't want to create prorations. If you simply add a new Price to an existing Subscription without creating prorations, there will be a period of time where your customer's will not be billed. Similarly, they will see charges for different amounts show up in their bank statement, so Subscription Schedules was recommended because it was cleaner

frigid flame
#

sorry i don't understand

#

I am sending out an email that says "on your next billing cycle you will be charged at our current pricing. Your billing cycle won't change." So maybe they were paying $9.97 monthly and then the bill will be for $19.97 but yes, that is the price change we notified them of in the email right?

#

What would happen differently with the complex SubscriptionSchedule that does not happen with a simple Subscription.update?
That is what i do not grok.

red stone
#

Ah, okay. So if you just update the Price, then the change occurs immediately. Consider this situation:

  1. Customer has billing cycle on the 1st of the month. It is July 15th and they have already paid for the month of July.
  2. You run the migration on July 15th, which updates the Price on the customer's subscription from Price A ($10) to Price B ($30)
  3. Customer is immediately billed $15 for the time from July 15th to August 1st because Price B is now active
  4. No refund occurs for the time they already paid for on Price A
#

That is what happens if all you do is change the Price

frigid flame
#
  1. no
#

On the Subscription.update call we are setting:
proration_behavior:none

#

So no invoice occurs until the next scheduled billing cycle right?

#

Customer is billed $30 on the 1st right?
And a month prior, on the 1st, was billed $10.

#

Isn't that what proration_behavior:none does?

#

We run the script on July 15th. No billing occcurs until Aug 1

#

no?

red stone
#

Yeah, so the customer would be billed $30 on the 1st, but I think that they end up with a free period in that case. Let me dig a few minutes and test on my end

frigid flame
#

OK, i have to go try to code this. Thank you. No worries.