#Royi-subscriptions

1 messages Β· Page 1 of 1 (latest)

valid kernel
#

πŸ‘‹ happy to help

tame anchor
#

@valid kernel Do you need more data in order to help ?

#

I can send the subscription id if needed

valid kernel
#

yes that would really help, thanks πŸ™‚

#

I was about to ask you for it

magic ivy
#

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

tame anchor
#

sub_1KvI1SEaahQGILqqERFj5Vi6

#

So proration is happening even if the subscription is paused?

#

and the invoice is uncollectible?

magic ivy
#

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.

tame anchor
#

"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 ?

magic ivy
tame anchor
# magic ivy 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...]
}
magic ivy
#

I think so

tame anchor
#

Testing

tame anchor
#

I was left with a draft invoice in_1KvfRkEaahQGILqqpeqB2gyN
Will it be collected ?

#

This is the newly created invoice in_1KvfXYEaahQGILqqpHG5dJoY

magic ivy
magic ivy
echo totem
#

Hey @tame anchor you said: "should I invalidate previous invoices manually?
"

#

Catchin up on the thread

echo totem
#

So you are asking what to do with the invoices generated while the Sub was paused?

tame anchor
#

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

echo totem
#

Right, when you pause you dictate what happens with these invoices

tame anchor
#

instead of one

echo totem
#

How are you triggering payment?

echo totem
#

That update shouldn't trigger payment on past invoices from when the sub was paused? Are you seeing otherwise in testing?

tame anchor
#

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 πŸ˜…

echo totem
#

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

tame anchor
#

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

echo totem
#

Yeah looking at an example would be helpful, thanks

tame anchor
#

cus_LczAATCH7j6ZVp

#

This is the customer

echo totem
#

Great, give me a moment to look

tame anchor
#

awesome

echo totem
#

So are you talking about in_1KvjKFEaahQGILqqPLS2MixU being paid?

tame anchor
#

I'm actually not sure which one now... Where can I see the status changes of that invoice?

echo totem
#

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

tame anchor
#

oh wait, you're right

#

that was a test

#

One sec again sorry

#

cus_LcvAGntMpmoKF0

#

Maybe that one

echo totem
#

Looking!

tame anchor
#

You awesome you πŸ™‚

echo totem
#

Huh that invoice was finalized like 2 hours later

#

I'm still looking for why... would not have expected that

echo totem
#

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

silent ravine
#

@tame anchor the invoice was created before the subscription was put in "pause_collection" right?

tame anchor
#

I think so

#

There should be another invoice with 0$. Which is the "trial" invoice

silent ravine
#

yes there is, but it was before

tame anchor
#

Another invoice for the time between trial end and pause, and the other after the checkout

#

So 3 in total

#

Did you find anything? 😭

silent ravine
#

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

tame anchor
#

We're taking about the same one.
The invoice before pause collection

#

What do you mean by normal?

silent ravine
#

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

tame anchor
#

So it means I have 2 edge cases:

  1. 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.
  2. 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 ?

silent ravine
#

I don't understand what those 2 sentences mean unfortunately

tame anchor
#

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

silent ravine
#

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

tame anchor
silent ravine
#

what does "the customer checks out" mean?

#

why not realize there's already an open invoice? That seems a pretty subpar solution/flow

tame anchor
#

Cause the service that we give to the paying customer starts at the payment moment and not when the trial ends

silent ravine
#

but an invoice is already created, wy would you create another invoice and another payment?

tame anchor
#

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.

silent ravine
#

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

tame anchor
#

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

silent ravine
#

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

tame anchor
#

OK. So assuming the following flow, what would you suggest I do ?

  1. user signs up -> a customer is being created + subscription in trial mode
  2. After 30 days, the trial ends and goes to active mode (in stripe)
  3. we wish to pause the subscription since the trial has ended.
  4. a customer can pay at any point after that.
  5. the billing cycle will start at the moment of payment
silent ravine
#

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

tame anchor
#

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

silent ravine
#

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

tame anchor
#

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 ?

silent ravine
#

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

tame anchor
#

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 πŸ™‚

deft escarp
#

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?

tame anchor
#

It's a "no payment method needed" sign up. So we're not taking any payment information

deft escarp
#

Got it

tame anchor
#

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

deft escarp
#

Okay, thanks for referencing the docs section

tame anchor
#

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

deft escarp
#

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?

tame anchor
#

No I haven't I just signup in our test env and updated the trial_end time

deft escarp
#

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

tame anchor
#

I will. Thank you for the suggestion

deft escarp
#

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

tame anchor
#

kk. I'll test it out.
How would you guys suggest I continue? manually voiding the previous invoices for now?

tame anchor
#

Do you mind updating the docs for the expected behavior for the case that resumes_at is not given ?

deft escarp
#

If you don’t set a resumes_at date, the subscription remains paused until you unset pause_collection.
You mean this?

tame anchor
#

I mean the expected behavior for invoices when resumes at is not given

deft escarp
#

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

tame anchor
#

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

heady lark
#

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!

tame anchor
#

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 ?

keen oak
#

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?

tame anchor
#

I'm confirming how unpausing it impacts draft invoices that have been created before the pause action

keen oak
#

Ah gotcha, thank you for that clarification and apologies for missing that.

tame anchor
#

all good

#

πŸ™‚

keen oak
#

Agreed that this is a very nuanced scenario, and it does sound like our docs don't do a great job covering it.

tame anchor
#

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...

true carbon
#

Hi there πŸ‘‹ taking over for @keen oak. Give me a few minutes to get caught up