#mufa117
crystal flame
echo depot
Hello! Can you provide more specific details? When did the complains start? How long was it working as expected before that? Did anything about your integration change recently?
long cave
It seems it started today. We haven't really made any changes besides rotating the secret keys - but we're still trying to find if the integration was affected by maybe not related change.
It was working for a few months now fine
Particular users: cus_HWJQ08vkfBaxmI - this one failed the payment, but the subscription is active.
Other one: cus_KQjq20iObAAYo9
User failed to purchase an annual subscription, but because the sub turned active, they re-tried with a cheaper subscription ($25) and were able to proceed with no pay, and the $25 was deducted from their annual payment that failed.
not sure if you have access to preview them, but these are the two use cases we've been able to identify
echo depot
Why did you rotate your keys? And can you provide more details about the "but we're still trying to find if the integration was affected by maybe not related change" part?
long cave
Because of the CircleCi incident.
What I meant, we're did not update anything directly on our billing integration other then rotating the keys. However, we're still trying to find out if there is anything we've updated on our end that might have affected the billing
this one is also a very weird example from today
This screenshot would probably be even better with the dates visible:
user: cus_NCGMczsAyWwNLO
but overall we have multiple users with these use cases, all from today
actually, I found also one from yesterday cus_J0dzomib9KZ0ow
echo depot
I'm not familiar with "the CircleCi incident". I'm also not sure what I'm looking for in those screenshots. You're saying those Subscription creation and update payments are unexpected?
long cave
so you could see the payments for the subscription/invoice failed in both cases, however the associated subscription turned into Active
the behaviour so far was if the creating subscription payment failed, the subscription was Expired/Cancelled
As per CircleCI, apologies, thought it was wide spread: https://circleci.com/blog/jan-4-2023-incident-report/
echo depot
Looking...
echo depot
Wanted to let you know that we're still investigating, haven't forgotten about you!
long cave
no worries, thank you for looking at it!
echo depot
After further investigation it does look like something is amiss. How long will you be around?
long cave
however long it will take
echo depot
We've got several people on it, I'll keep you updated as we know more.
long cave
awesome, thank you!
echo depot
We believe we've identified the change responsible and are working on reverting it now, so this should be fixed going forward shortly. As one of the impacted accounts you should receive further details via email as we determine next steps beyond that.
long cave
Great to hear, thank you Rubeus!
echo depot
Sorry for the trouble, and thank you for letting us know!
long cave
For sure. Do you know if there would be any actions from Stripe, regarding the accounts that got credited through that?
echo depot
It's too soon to say, we're still investigating the specifics. The comms you'll receive later should provide details about that though.
long cave
This is the use case. User tried to upgrade to $240, which failed. But because the sub turned into active, once user wanted to downgrade right away, the credit for unused $240 was applied
okay, sounds good, thank you Rubeus
echo depot
If you're still around, do you have the Customer ID for the $240 situation you described above handy?
echo depot
Thanks!
long cave
if you're still around, do you think Stripe will be trying to do some recovery/revert action on these use cases, or should we start manually cancelling these active not-paid subscriptions? We have a problem with some users who tries to proceed, as Stripe has a subscription, but our database has them still on a free version which causes issues on price preview.
echo depot
I don't think we'll revert them ourselves, I recommend you cancel them.
long cave
okay, thanks
echo depot
Reverting them would be too dangerous and lead to a lot of unexpected behavior.
long cave
and the same comes with the credited customers, right?
echo depot
You should check to confirm no payment was made and cancel if not.
long cave
the use case from the above, where they were able to use money credited from unpaid subscription
echo depot
I think that situation is our normal proration behavior; we don't take into account the paid or unpaid status when calculating prorations (we assume an outstanding payment will succeed when calculating prorations).
long cave
yes, I am aware of that, and we made some precaution steps for that based on the subscription's status. That being said, I am still surprised the calculated prorations are not taking into account sub's status, because it is updating the same subscription
in any case, we will adjust that on our end, now that I know what to expect from Stripe
echo depot
Yeah, our proration behavior doesn't take the Subscription status into account unfortunately. I think we're investigating changing that, but that's how it works today.
long cave
Just to confirm - has this been now reverted and addressed? May I know the specific time, so I can verify on my end? 🙂
echo depot
Looks like the change was fully reverted 13 minutes ago.
long cave
Great, thank you.