#patricia
1 messages · Page 1 of 1 (latest)
Hi 👋
Can you provide the Subscription ID so I can review it?

This is one I created where I didn't see the proration_behavior on the object itself.
sub_1MIEUeEnqwDARn15tb5DUu3U
I will dig up the test clock example with the final amount prorated
Proration behavior isn't something you set on a Subscription itself. You have to specify it every time you make a change to the Subscription
Oh
That makes sense then why I'm seeing that
Is there a way to pass in an option to cancel a subscription in the future and not prorate it?
Do you have the API request ID where you canceled the Subscription?
Here's how you can find a request ID: https://support.stripe.com/questions/finding-the-id-for-an-api-request
The backstory here is that I'm looking to use Billing to set up a BNPL-like system, where someone can make a donation that is paid over a certain number of months
I will have to get back to you later today with the ID of the test clock subscription that was cancelled, apologies
Generally you would include both proration_behavior and cacel_at. However, for your scenario you might try using Subscription Schedules. They add a bit more complexity but the use cases available make them worth it IMO.
I think this one fits your description pretty well: https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#installment-plans
Thank you! I didn't know about this
It can be pretty useful because you can set up your subscription to cancel after a specific number of iterations
@scenic laurel I have the ID with the test clock example. This had 2 charges of $400 and then a 3rd charge of less than that
sub_1MHKqTIiH3UU5fnQx7AG7dRm
The subscription schedules do look interesting though and it may be what we need after all. My memory of them is that they introduced too much complexity, but it looks like we could reduce that complexity by not making any changes once it's created. Still, I would have expected proration_behavior to pass on to the moment of cancellation as well
It sounds like the two options are:
- Create the subscriptions as we're doing currently, and then have a job that cancels the subscription on the required day with the cancellation behavior set during that call
- Use subscription schedules with installments set
I can't find the API request where you canceled the Subscription. I see you provided proration_behavior: "none" at the time of Subscription creation but that would not do anything. Requests that change the billing cycle are the ones that need to specify the proration behavior
Sorry, this example passes in cancel_at so it canceled automatically
AH, yes. And that was slightly not in line with the recurring period
It sounds like the subscription schedules are what we need then. Just to clarify, do you know if subscription schedules are also limited to be created within 30 days (just as regular subscriptions cannot be created more than 30 days in advance)?
I would want to test that because we don't explicitly state how far in the future a Subscription would be created here: https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#start-subscription-future
However, I know you can use a phase for a free trial period and have that extend longer than 1 month in the future.
Thank you very much!