#ilyoTheHorrid (Endstream)
tall dirge
keen wren
Can you elaborate a bit on the scenario that you're working through?
Subscriptions bill at the beginning of billing periods rather than at the end (unless you're using a metered price), so avoiding prorations may not be needed.
Are you setting the Subscription to cancel before the Subscription is in what will effectively be its last billing period? If so, can you confirm how you're doing that?
paper otter
yes, I want to make sure that the last billing period can be canceled at any time within that cycle, but the customer will still pay full price
It is not metered
but Recurring usage
but if the start cycle is on the 1st and I cancel on the 15th, they get charged 50%
keen wren
Can you share the ID of the Subscription that you used for testing where you saw that behavior? The customer would have paid the full amount at the beginning of that billing period, so I'd like to take a closer look at what you did to see what led you to the behavior you're experiencing.
paper otter
sure, a few minutes
test mode
as you see it should be $1000 (yearly) but charges $13.70
keen wren
Thank you, taking a look.
Ah I see, you're passing the cancel_at parameter during Subscription creation, which might be playing a factor here since then we'll know when the Subscription will cancel. If you remove the cancel_at parameter from your request, does the upcoming Invoice then show the amount you're expecting?
paper otter
I didn't try it, but I need the cancel_at to set a cancelation date. what's the alternative?
I tried making the cancel_at exactly one year in the future, but then I'm not sure if it will charge the next cycle or not
keen wren
Gotcha, before we go too much farther down that path, is there a particular reason you're trying to use Subscriptions instead of the other path that I suggested (an off-session Payment Intent) to you here and on your Stack Overflow post?
paper otter
yes, because I'm close to finish it and I have a deadline:) I will rework it into the future payments later
keen wren
I don't think it's possible to create a Subscription that does everything you're looking for.
I will need to run through some testing to see if I can find a specific combination of parameters that give you that behavior.
paper otter
that would be great, thank you
The main issue is to make sure it cancels before the next cycle, but charges the full amount
keen wren
That is easy to do by itself, but you still need to this to all be delayed as well, right?
paper otter
yes!
keen wren
That's the part that makes it complicated. I would recommend using cancel_at_period_end but that won't work in conjuction with billing_cycle_anchor.
paper otter
is there a way to verify that the cancel date I put is charging next cycle or not?
keen wren
Trying to set cancel_at is can be tricky, because you need to be second-precise to avoid creating prorations. If you set cancel_at to the exact end of the billing period, then the Subscription will cancel before progressing to the next billing period and won't charge the Customer again.
paper otter
can I see it in the UI, for example here https://dashboard.stripe.com/test/subscriptions/sub_1MK6ZCDvJEUYbQTxGStpRL9Z
keen wren
You can use Test Clocks to test all of these flows, they allow you to create Subscriptions in sandboxed areas where you can control the progressing of the clock for the sandbox. It let's you test annually recurring Subscriptions in minutes:
https://stripe.com/docs/billing/testing/test-clocks
paper otter
I am adding exactly a year with date-fns
sour turret
That sounds like it should work though test clock testing should be able to help you see that for sure
paper otter
@keen wren can I see it in the UI? for example here https://dashboard.stripe.com/test/subscriptions/sub_1MK6ZCDvJEUYbQTxGStpRL9Z
@sour turret what do you refer to?
keen wren
See what exactly?
sour turret
I was talking about the think that toby mentioned. You can make a test clock, create a subscription on it, set the cancelation via date-fns, and fast forward the test clock to see if the date you calculated lines up with when the end of the subscription cycle properly. https://stripe.com/docs/billing/testing/test-clocks
paper otter
It is not visible in the UI?
keen wren
If you're referring to the cancel_at data that you specified, I see that beside the title of the Subscription inside of the Cancels tag. Please let me know if that isn't the detail you're looking for.
We spend most of our time working on API integrations, so we typically aren't too familiar with dashboard features.
paper otter
No, I meant the number of future payments scheduled
keen wren
No, as far as I know that is not possible to see a visual representation of future payments beyond the current estimate of the next Invoice, but you can use a Test Clock to simulate this entire process beginning to end and see exactly how the system will behave at each point.
paper otter
ok thank you