#Royi-subscriptions
1 messages Β· Page 1 of 1 (latest)
@valid kernel Do you need more data in order to help ?
I can send the subscription id if needed
An invoice always happens when you change the billing cycle (like setting it to 'now'). https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#immediate-payment
and also you pass always_invoice so that would also result in an invoice, charging a prorated amount. That's why 3 and 4 happen
sub_1KvI1SEaahQGILqqERFj5Vi6
So proration is happening even if the subscription is paused?
and the invoice is uncollectible?
looking..
basically there's proration because on May 3, in in_1KvIUlEaahQGILqqK44TpYhS, the customer 'pays' for the upcoming month. On May 4 you reset the billing cycle to produce in_1Kvcm0EaahQGILqqURah7MGZ. Resetting the anchor changes the billing dates from the 3rd of the month to the 4th. So the customer pays the $250 for the 4th->4th up front, minus a prorated amount for what they already "paid" in the invoice the day before.
"paid the day before" - you mean the uncollectible invoice?
How should I change the code to support a new invoice with no proration in new billing cycle ?
I think the same update call but pass proration_behavior:"none" instead
so just to see I understand correctly:
If paused collection
{
cancel_at_period_end: false,
proration_behavior: 'none',
default_payment_method: somePaymentMethodId,
billing_cycle_anchor: 'now',
pause_collection: null,
...(currentSubscription.status === SubscriptionStatus.TRIALING ? { trial_end: 'now' } : {}),
items: [item1,item2...]
}
else
{
cancel_at_period_end: false,
proration_behavior: 'always_invoice',
default_payment_method: somePaymentMethodId,
billing_cycle_anchor: 'now',
...(currentSubscription.status === SubscriptionStatus.TRIALING ? { trial_end: 'now' } : {}),
items: [item1,item2...]
}
I think so
Testing
I was left with a draft invoice in_1KvfRkEaahQGILqqpeqB2gyN
Will it be collected ?
This is the newly created invoice in_1KvfXYEaahQGILqqpHG5dJoY
that's the recurring invoice invoice for the new billing cycle that started at the end of the trial period you set in https://dashboard.stripe.com/test/logs/req_ziDI0ZO5nDArRK to end a few minutes after that request
that's the invoice generated by resetting the billing cycle to 'now' in your update request to unpause things. As discussed, it doesn't contain proration since that was disabled.
Hey @tame anchor you said: "should I invalidate previous invoices manually?
"
Catchin up on the thread
Yes I did π
So you are asking what to do with the invoices generated while the Sub was paused?
more or less
After the subscription was paused there's a draft invoice that is not marked as uncollectible for 1 hour
that will happen over and over due to the billing cycle
So if a customer decides to pay during that time, 2 invoices will be paid
Right, when you pause you dictate what happens with these invoices
instead of one
How are you triggering payment?
Just like I mentioned here
That update shouldn't trigger payment on past invoices from when the sub was paused? Are you seeing otherwise in testing?
Yes
So the timeline goes like this:
Trial ends -> active -> webhook to our service -> trigger pause collection -> a draft invoice is created (and waits 1 hour until it should be marked as uncollectible)
then a customer pays -> I use the request mentioned above -> another invoice is created since it changes the billing cycle -> the new invoice is paid, the previous draft invoice is now NOT waiting to be marked as uncollectible but rather is able to be paid.
hope I was clear π
Oh okay so yeah you aren't seeing the past draft paid, but it is sitting in draft
So that invoice is set to auto_advance: false due to being created during the pause. This means the invoice won't move forward without your action
So it is up to you
You can void the invoice if you don't expect to collect payment
Or you can just leave it be if you want to charge later
No action was made to pay for that draft invoice, but it was marked as paid 1 hr later
Let me maybe find the subscription i was talking about
Yeah looking at an example would be helpful, thanks
Great, give me a moment to look
awesome
So are you talking about in_1KvjKFEaahQGILqqPLS2MixU being paid?
I'm actually not sure which one now... Where can I see the status changes of that invoice?
You look a the Events associated with the Invoice
That is the invoice that was created after the trial when the Sub was paused
However, that invoice was finalized via yourself explicitly. See: req_2hjNPv5CCbvxsP
If that wasn't finalized, then it should just remain in draft
oh wait, you're right
that was a test
One sec again sorry
cus_LcvAGntMpmoKF0
Maybe that one
Looking!
You awesome you π
Huh that invoice was finalized like 2 hours later
I'm still looking for why... would not have expected that
Sorry, server is busy
But I'm coming back around in a sec
Alright feel like I'm missing something here... let me double check with a colleague
@tame anchor the invoice was created before the subscription was put in "pause_collection" right?
yes there is, but it was before
Another invoice for the time between trial end and pause, and the other after the checkout
So 3 in total
Did you find anything? π
sorry I'm not entirely following all of that
I was looking with bismarck at the one invoice you mentioned, it was created before pause collection so it's all normal
I'm happy to look further if you have a specific question about an exact invoice, what you see and what confuses you
We're taking about the same one.
The invoice before pause collection
What do you mean by normal?
I guess I don't understand what the issue is with that invoice?
If you have an invoice created at 00:00 UTC and then you pause the subscription at 00:05 UTC it will not change the first invoice, that one will be finalized and paid as expected
So it means I have 2 edge cases:
- checkout between 00:00 -> 00:05 - with the request I send a billing cycle will be created, with a new invoice, and 2 invoices will be paid.
- checkout after 00:05 before the invoice was marked as uncollectible - the invoice was marked as draft, then waiting to get marked as uncollectible but before it did, the customer paid. so I have 2 invoices
am I right ?
I don't understand what those 2 sentences mean unfortunately
In the timeline I described in the quoted message,
There's a time between the draft invoice was finalized, till the time a customer checked out. The checkout operation will create a new invoice, in addition to the draft one that was created when the subscription went from trial to active
A pause operation can happen between the time of the draft invoice creation (AKA the trial->active change), and the checkout operation
in both cases, (pause, or not) the draft invoice is still waiting to be paid, and since I set a default payment method on the subscription, it will be used to pay for that draft invoice, even though not needed
I'm sorry, why do you have so many invoices, a checkout experience, a pause
like how does all of this make sense together?
Ultimately: when you pause collection on a subscription it affects only future invoices. If you want to stop all collections you have to handle previous unpaid invoices
On our product, a subscription starts in trial (1st invoice), then when the trial ends it goes automatically to active (which is just how stripe works - 2nd invoice), then webhook to our service, and we pause the subscription.
Then a customer checks out and we start a new billing cycle from the checkout out time (3rd invoice)
what does "the customer checks out" mean?
why not realize there's already an open invoice? That seems a pretty subpar solution/flow
a customer wants to pay for our services
Cause the service that we give to the paying customer starts at the payment moment and not when the trial ends
but an invoice is already created, wy would you create another invoice and another payment?
Not sure I follow. I'm not creating a new invoice. I'm just starting a new billing cycle. the new invoice is created because of that.
but why start a new billing cycle, that doesn't really make sense, you already have a billing cycle, you already have an invoice waiting to be paid
Cause the customer didn't pay. There's no payment method yet but the billing cycle starts automatically after the trial ends.
We "extend the trial" by just pausing the collection
I'm sorry but I really think you're using Billing quite incorrectly here by doing that
but that explains all of the confusion here
OK. So assuming the following flow, what would you suggest I do ?
- user signs up -> a customer is being created + subscription in trial mode
- After 30 days, the trial ends and goes to active mode (in stripe)
- we wish to pause the subscription since the trial has ended.
- a customer can pay at any point after that.
- the billing cycle will start at the moment of payment
mostly get rid of 1/2/3 and never create a subscription in a trial since it's absolutely not a trial IMO
if it were me I'd handle "trials" myself and create the subscription at step #4 when the customer is ready to pay
and when would you use trial in stripe? Or pause collection? The docs clearly states that I can stop collection when we "give our services for free" and mark them as uncollectible.
I mean... they are a feature in stripe and I'm following the docs
I would use neither of this at all, there's no reason to pause anything if you create the subscription once the customer is ready to pay
I'm sorry, I'm not sure how to explain this, I have never seen anyone try to do what you are describing and it really doesn't make sense to me
if you give someone days of trials, why does it matter to pause the subscription right at the second the trial ends? They were already not paying for it
I'm sorry, it really doesn't work this way and you should ensure to collect card details during the trial really and keep the subscription active and all that
Thnx for the input. It might be that we miss used stripe, and we'll definitely take it into consideration. I'll gladly explain everything once again in a f2f video conference, cause I do feel that I might have explained something wrong.
I do think that if no-one should use trial, or pause collection in stripe as you said, that's a really weird feature to document and add to the system.
But just to be practical with my use case...
All invoices that will be created after the pause action will not advance automatically. So this is good.
After pausing, I need to check if a draft invoice exists, and cancel it
Am I right ?
I've never said no one uses trials
I've said no one does what you are doing really where you have a trial, and at the end of the trial, for some reason, you consider the subscription completely paused. They exhausted their trial, they haven't paid yet, you don't want the subscription to be active until after they pay, and you get a fake invoice and all of that
that overall flow doesn't make sense to me. You already gave them days of trial, why does it matter that they have a few extra hours on a trial until they pay their invoice?
And yes you would void the previous invoices in that case
That's a product decision actually. When you first introduce payment to your system as a startup, you can't just block whomever you want.
There's a gradual "we're going to block you" sessions until we actually do that.
So the customer can actually use the system, but didn't pay.
Also there's a value in monitoring trial ending business wise
in regards to whether or not implement it using stripe... you most definitely more suited to answer that question π
Hi π I'm stepping in for @silent ravine. There's lots going on here so give me a second.
So you are not collecting payment information from the customer during the initial creation of the subscription?
You want to pause the subscription, bring the user back on-session, and collect payment information at that time?
It's a "no payment method needed" sign up. So we're not taking any payment information
yeap
Got it
And so I'm guessing you are looking at this feature: https://stripe.com/docs/billing/subscriptions/pause#collect-payment-later
no
I want to mark it as uncollectible. cause I'm not going to make the customer pay for the "so-called-extended-trial"
I'm using the "offer services as free" part
Okay, thanks for referencing the docs section
I would assume that the "mark uncollectible" would mark existing draft as uncollectible as well. But I guess that's not the case
Since no "resumes_at" is being passed, all invoices should be marked as uncollectible
I think that interpretation is correct. However, I prefer to test these scenarios thoroughly so I can be sure of the expected behavior. Have you tried using our Test Clocks feature to simulate this for your customers?
No I haven't I just signup in our test env and updated the trial_end time
It's a pretty useful tool when it comes to testing subscriptions. I have found using it helps clarify how different setting configurations impact the behavior of your subscriptions
I will. Thank you for the suggestion
I haven't tested out your specific use case which is why I'm suggesting it as a way to get clarity. It may also allow you to figure out the impacts of other settings changes to better optimize your users experience
Also test sunny day scenarios & edge cases
kk. I'll test it out.
How would you guys suggest I continue? manually voiding the previous invoices for now?
I'll definitely test this case obviously.
Do you mind updating the docs for the expected behavior for the case that resumes_at is not given ?
If you donβt set a resumes_at date, the subscription remains paused until you unset pause_collection.
You mean this?
I mean the expected behavior for invoices when resumes at is not given
Ah yes that is a recommendation I can pass on. It would make a logical follow up to the sentence I referenced.
e.g. All invoices are marked uncollectable until you unset pause_collection. <- I don't know if this is true but an hours' testing should reveal it
Anyway, we'll test this case once again with the test clock.
And for now we'll manually make sure that no draft invoice exists
sounds reasonable ?
Using the test clocks:
Draft invoice will be marked uncollectible in the future
updated the subscription with the same request, and I got a different message now
This last image shows that the draft invoice is now paid
Hi, stepping in here. I'm trying to get caught up on this thread. While I do this, are you able to summarize the open ask? Thank you!
Hi @heady lark
I feel like the only practical thing for me to do now, is to manually set the "unwanted invoice" as uncollectible, or void. Just wanted to ask for your opinion.
I guess, as a result from the screenshots I sent, where I simulated the problem I have, that marking the invoices as uncollectible is an async process. that's why it is being paid lated on.
This was very confusing and not trivial since the documentation is not stating that.
I'm not sure if it is a bug, or an expected behavior.
I suggest updating the docs stating it will "take some time" to invalidate the invoices, and that the invoice will be finalized according to the latest available status of the subscription
WDYT ?
Just making sure I've wrapped my head around this correctly.
You have a subscription that you're updating with pause_collection.behavior set to mark_uncollectible and confirming how that impacts draft invoices that have already been created but are pending finalization?
I'm confirming how unpausing it impacts draft invoices that have been created before the pause action
Ah gotcha, thank you for that clarification and apologies for missing that.
Agreed that this is a very nuanced scenario, and it does sound like our docs don't do a great job covering it.
Not sure it is such a nuance. What happens when a billing cycle switches to a new one? A new draft invoice is created and we're at the point again...
Hi there π taking over for @keen oak. Give me a few minutes to get caught up