#mufa117-subscription

1 messages · Page 1 of 1 (latest)

humble axle
#

Hi there, looking

tired crown
#

I was testing on test clocks on our test environment, customer cus_MG0u1JXvl39nLA

humble axle
#

Gimme some times for triaging

tired crown
#

Sub settings:

  • 4 smart retries over 2 weeks
  • If all retries fails - cancel the subscription

Create sub with 4242 card, cost $200
createSubscription {
customer: 'cus_MG0u1JXvl39nLA',
items: [ { plan: 'plan_EehV9fhXy1c0Xw' } ],
expand: [ 'latest_invoice.payment_intent' ],
payment_behavior: 'allow_incomplete',
coupon: '8vBQ6ktD'
}

Update card to 4000 0000 0000 0341

Advance time of 1 year and 1 week

Annual sub is Past due


Going on the site to downgrade the subscription to a monthly plan (cheaper) - $25

UpdateSub {
  items: [ { id: 'si_MGWASmw8TiaB32', plan: 'plan_DZn0aaksgPLFA8' } ],
  expand: [ 'latest_invoice.payment_intent' ],
  paymentBehavior: 'pending_if_incomplete',
  prorationDate: 2036-12-20T00:00:00.000Z,
  prorationBehavior: 'always_invoice'
}

I pay $0, and have credit of ~$175

I advance the time for another two weeks - my subscription is cancelled, but the credit persists.
#

Times - events from the last 17 minutes only. I cancelled previous and tried to reproduce it in the following steps

#

no, wrong. I made a mistake and updated that card. Let me recreate the same steps with no updating to the right card

======= Go from this

#

Sub settings:

  • 4 smart retries over 2 weeks
  • If all retries fails - cancel the subscription

Create sub with 4242 card, cost $200
createSubscription {
customer: 'cus_MG0u1JXvl39nLA',
items: [ { plan: 'plan_EehV9fhXy1c0Xw' } ],
expand: [ 'latest_invoice.payment_intent' ],
payment_behavior: 'allow_incomplete',
coupon: '8vBQ6ktD'
}

Update card to 4000 0000 0000 0341

Advance time of 1 year and 1 week

Annual sub is Past due

Going on the site to downgrade the subscription to a monthly plan (cheaper) - $25

UpdateSub {
items: [ { id: 'si_MGWASmw8TiaB32', plan: 'plan_DZn0aaksgPLFA8' } ],
expand: [ 'latest_invoice.payment_intent' ],
paymentBehavior: 'pending_if_incomplete',
prorationDate: 2038-01-07T00:00:00.000Z,
prorationBehavior: 'always_invoice'
}

I pay $0, and have credit of ~$175 (even with 4000 ... 0341 card)

I advance the time for another two weeks - my subscription is cancelled, but the credit persists.

#

okay, last 3 minutes, reproduced the entire flow

humble axle
#

Sorry these are long paragraphs and I am not following unfortunately. Can you summarize your issue? with one example Id to look into?

tired crown
#

Sub settings:

  • 4 smart retries over 2 weeks
  • If all retries fails - cancel the subscription

Have two subscriptions - annual for $200 plan_EehV9fhXy1c0Xw, and monthly for $25 plan_DZn0aaksgPLFA8

  1. Create sub with 4242 card, cost $200
# Request's props:
createSubscription {
  customer: 'cus_MG0u1JXvl39nLA',
  items: [ { plan: 'plan_EehV9fhXy1c0Xw' } ],
  expand: [ 'latest_invoice.payment_intent' ],
  payment_behavior: 'allow_incomplete',
}
  1. Update card to 4000 0000 0000 0341
  2. Advance time on Stripe's time clock, of 1 year and 1 week (annual sub's status is past_due)
  3. Going on the platform to downgrade the subscription to a monthly plan
# Request's props:
UpdateSub {
  items: [ { id: 'si_MGWASmw8TiaB32', plan: 'plan_DZn0aaksgPLFA8' } ],
  expand: [ 'latest_invoice.payment_intent' ],
  paymentBehavior: 'pending_if_incomplete',
  prorationDate: 2038-01-07T00:00:00.000Z,
  prorationBehavior: 'always_invoice'
}

Results

Immediate: I pay $0, and have credit of ~$175
I advance the time for another two weeks - my subscription is cancelled, but the credit of $175 persists, even it was never paid.

What I would expect is that at the time of (4) when I downgraded to the cheaper plan, I would not receive any credits and I would be charged the full amount ($25) immediately

#

Hope that's more clear. Thank you for looking into this!~

#

SubscriptionID to look at: sub_1LXzHPDXCLTgWj3aEYa3ZF9A

humble axle
#

Thanks, looking...

#

I notice the proration date is 2038-01-07T00:00:00.000Z which is super weird. Maybe the unix timestamp format is messed up?

tired crown
#

I'm using the time clocks, which moved the dates to 2038 already

humble axle
#

ah okie so it's intended

tired crown
#

and yes, that's the request

humble axle
#

This is prorated Invoice

tired crown
#

yes, but the previous invoice was never paid, therefore I'm not sure why it gives the balance at this point

#

Year 1 - paid $200
Year 2 - failed to charge and downgraded to $25/month.

I would assume the credit would not get issued of the $175 given it was never paid.

#

Also, if I switch to proration_behaviour: none in the step 4 it leaves me with an active subscription, but with no immediate charge (it's getting charged at the next billing cycle).

#

and I need to use pending_if_incomplete for payment_behavior because we have 3D Secure implemented

humble axle
#

qq where do you see the balance of $175 issued?

tired crown
#

it's $171.62, sorry for not being accurate

#

also, it's this invoice: in_1LXzInDXCLTgWj3a6LxVH26r

humble axle
#

I don't think it's the result of proration

#

that $171.62

tired crown
#

but it's from Unused time on StreamYard Basic Annual (with $40.00 off) after 07 Jan 2038

#

so I thought it's a result of downgrading the subscription

#

but at that time, it is Year 2, when the annual charge failed

humble axle
#

It's from Dashboard

tired crown
#

yes, that was before I performed the test. I made a "reset" to 0

#

so right after that, I performed the steps from the above

humble axle
tired crown
#

I was basically trying to make these steps before, but I made a mistake, so I made a reset - adjusted my credit to 0, and cancelled the subscription

humble axle
#

Okie there is something called "Invoice too small" here, looking

tired crown
humble axle
#

So here is the prorated amount back of $196.62

#

Unused time on StreamYard Basic Annual (with $40.00 off) after 07 Jan 2038

tired crown
#

yes, and there is another $25 deducted from that (because I'm downgrading to the cheaper ($25) plan)

#

but at this time, I don't really understand that deduction, given the charge for that time period has failed and is not paid

humble axle
#

I get what you mean, the question is why a failed payment still allow the proration giving back credit to customer

tired crown
#

yes

humble axle
#

Okie thanks for accompanying with me. I finally found some similar ask in the past

tired crown
#

thank you for looking into it!

humble axle
#

To summarize, yes it's a known limitation. At Subscription update we do not check the status of the Subscription’s latest Invoice. So regardless it was a failed payment, we still update and prorate as if the payment was successful

#

There are some workarounds

tired crown
#

I tried to run a workaround in the way to change proration_behavior: none and mark the failed invoice as uncollectible, but that was giving me some other issues (if the plan was more expensive, it still activated the new plan, and did not charge immediatelly but was expecting to charge at the next billing cycle)

#

would be awesome if you could refer me to the workarounds you had in mind 🙂

humble axle
#

Yes what you mentioned is one workaround actually. You can consider generating an one-off Invoice yourself, charge for any price different immediately

#

In your case, it would be charging fully $25 monthly plan, for 2038 Jan 7 to 2038 Feb 7

tired crown
#

so that would be a single invoice, and I would still need to updateSubscription with a starting date of 2038, Feb 7th?

#

and would still need to void/uncollectible the previous Failed invoice (so my subscription won't get automatically cancelled)

#

are there any other workarounds you can think of? I was considering creating another subscription, and once succeeded - remove the failed one. That would only "cost" us updating subscription.deleted webhook to ensure not to cancel the product if there is a new one created

humble axle
#

so that would be a single invoice, and I would still need to updateSubscription with a starting date of 2038, Feb 7th?
and would still need to void/uncollectible the previous Failed invoice (so my subscription won't get automatically cancelled)
Yes! And I think it's cleaner than messing with another Subscription. You would lost in managing relations between multiple Subscriptions

#

Another workaround is setting both proration_behavior: none and billing_cycle_anchor: now. I believe in this case it would immediately generate a new Invoice

tired crown
#

So I should also bind the one-off invoice with the existing subscription, right?

tired crown
#

but I will try that again, just in case, as it does look better to me personally

#

Thank you for now, really appreciate your help.

If I test it out, and run into some issues, can I still reply here, or should I start a new thread?

humble axle
#

I could be stepping down in next 30 mins. Feel free to ask in the channel if you returns after that. In that case please include link to this conversation because it has pretty deep context

tired crown
#

sounds good, thank you very much!

humble axle
#

Np and good luck!

tired crown
#

okay, so I found what was wrong with billing_cycle_anchor: now. If I try to downgrade, and my payment fails - even the invoice gets voided/cancelled - the subscription changes to the status: active and it won't change to past_due until the next failed payment on it 😦 is that also a known limitation?

#

(We have a system to manually void failed invoice, so maybe voiding it switches the sub to active ?)

humble axle
#

If I try to downgrade, and my payment fails - even the invoice gets voided/cancelled
Does this mean the new payment for $25 failed, or the previous payment for $200 failed?

tired crown
#

Previous payment was failing. So I try to downgrade (but I did not update my faulty credit card), so my $25 also fails at this point

#

because we have pending_if_incomplete we have a fallback mechanism to void the open invoice if 3D Secure is not required - but I'm guessing that voiding the invoice transistions the subscription status from past_due to active until the next retry from $200 happens

humble axle
#

Sorry wrong url

#

one moment

#

I don't think pending_if_incomplete has something to do with keeping the Subscription as active instead of past_due

tired crown
#

it keeps the invoice open - thus, I need to manually void it

#

so I think voiding it transitions that status

humble axle
#

And when you void it, the Subscription changed back from past_due to active

#

yes that's what I observed

tired crown
#

is that also intented? I'm guessing it's status is based on the latest invoice/payment then?

humble axle
#

It only look at newer Invoices, and because it see no "invalid" Invoice anymore, it assume safe to move back Subscription to active

#

I think the limitation here is it ignores the previous failed $200 Invoice

tired crown
#

right. But at this point, if I would not void the invoice it would increase the "owing" amount, as now there are two charges that failed -> $200 and $25, right?

#

and my understanding would be that smart retries would try to charge both (when only $200 is still valid, until the change)

#

in any case, I don't want to take more of your time today, I will try something else, and eventually reach out here or on the main thread tomorrow. You already helped me a lot

humble axle
#

Np and thanks because you help me challenging my own brain xD

#

I agree it's a bit weird for billing_cycle_anchor: now. Will try to report internally

tired crown
#

haha, thanks! I was worried I was missing something super obvious, but I'm glad I did my research relatively well

#

thank you, and have a great rest of your day/night!

humble axle
#

But let's put that aside and only use the other workaround with only proration_behavior: none