#bumbzor-subscriptions

1 messages · Page 1 of 1 (latest)

waxen field
#

Hi there!

#

Is the issue that the customer ends up with 2 active subscriptions?

idle patio
#

yes that is correct.

#

when they manuall renew in our APP that automatically adds a new valid card to their Customer profile in Stripe which in turns automatically renews the old failing subscription

waxen field
idle patio
#

That's the big issue cause we already have the code in place for your 2'nd option

#

If i provide you with the subscription info and customer could you please look to see if there was API attempt made to cancel the old failing one?

#

perhaps there is another scenario that we are unaware of

#
  • What our code does is retrieves the old failing subscription.
  • Get all invoices for that subscription
  • loop throught them and for any Unpaid ones , Void them.
#

Is it possible that in this scenario there were no actual Invoices or perhaps something else in the API response that we should also check

#

that's my confusion here. We have the code in check for scenarios like this but I am guessing in this particular scenario with the card being reported as stolen it might be a different approach we should take

waxen field
#

Can you share the subscription ID?

idle patio
#

the failing one?

#

sub_Jfy6ta5Ns5AUdB

#

I looked in the code and there should be a "Subscription Retrieve" call. If the status of the subscription is Failing then there should be a new API call to updte it and set the cancel_at_period_end to true for it

#

and then a call to get all invoices and void any unpaid ones

waxen field
#

Is your goal to cancel all subscriptions as soon as a payment fails?

idle patio
#

Our goal and what our code is doing (should be doing) is that if a customer attempts a manual renewal, the old failing subscriptions should be cancelled to avoid duplicate subs

#

and that is what the code is built to do. But for this particular user he still ended up with 2 subscription.

#

so I am trying to understand if perhaps in this scenario there is something else we should check as the Cancel might not have worked on the failing one

waxen field
#

If the status of the subscription is Failing then there should be a new API call to updte it and set the cancel_at_period_end to true for it
That seems correct to me.

idle patio
#

yes that is exactly what our code does. But for some reason it appears that the subscruption in Stripe (the old one that was failing) was not cancelled.

waxen field
#

Did your code actually send a request to cancel that subscription?

#

If so, can you share the request ID?

idle patio
#

that I don't know. I was hoping you guys could check. We don't log the requests going out

waxen field
#

So yes it looks like your code didn't send any event to Stripe to set the cancel_at_period_end.

idle patio
#

I think that was the customer canceling it on its own when he saw the duplicate.

#

Can you please tell me if that subscription (the one that failed to renew) did had the status as failing in Stripe?

#

Im trying to understand our code

#

because we do something else if the status in Stripe was not failing when we attepmted the cancel

waxen field
idle patio
#

ah sorry my bad. If the Subscription has the status of "failing" in our system end

#

Is it possible for you to tell me what was the exact status of the subscription in Stripe after the renewal attempts failed?

waxen field
#

on 2022-06-15 at 14:20:48 UTC, it moved from active to past_due
on 2022-06-19 at 20:01:17 UTC, it moved from past_due to active
on 2022-06-19 at 20:02:47 UTC, it moved from active to canceled

idle patio
#

So based on that and the info I have here:

  • On June 15, payment started (for the renewal)

  • June 15 4:20 PM Payment failed (card is reported as stolen)

  • June 15 14:20UTC The Subscription status at Stripe was changed to past_due

  • June 19 9:22AM Payment failed again (card is the same as before so still reported as stolen)

  • June 19 10:02PM Customer renews manually with a new card and this payment is good and a new subscription is created.

  • June 19 10:01PM The old payment that was failing is also completed with the new card details.
    At this point since the original failing payment has been processed too the old past_due Subscription in Stripe was also reactivated: on 2022-06-19 at 20:01:17 UTC, it moved from past_due to active

#

times might be off cause of different time zone in the account. That pretty much is corect you think?
So this can happen again any time an old Subscription is past_due in Stripe and the customer renews manually via our integration?

#

Maybe when handling cases like this we should also check for past_due subscriptions in Stripe and Cancel them?

waxen field
#

times might be off cause of different time zone in the account. That pretty much is corect you think?
Yes that looks consistent with what I see

#

Maybe when handling cases like this we should also check for past_due subscriptions in Stripe and Cancel them?
Yes I think that makes sense. Or like I said at the very beginning, do not create a new subscription and instead simply update the payment method of the past due subscription.

idle patio
#

we have to make new subscription. is how our system works. y

#

one other thing that is puzling me.
We send a request to return all invoices for the old subscription and void any of them that are unpaid. Is it possible that the old subscription did not had any Invoices created that were failing to be paid?

waxen field
idle patio
#

got it. Ok thanks for the assistance here. really helpful

#

so there were no requests sent from our app to Stripe for that subscription to cancel it (before the final cancellation) or to set the cancel_at_period_end true?

waxen field
#

I don't see any update to cancel_at_period_end

idle patio
#

ok thank you