#john-a_unexpected
finite otterBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1308126854024265761
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
deep wind
Hi 👋
Do you have example subscriptions for both of those two scenarios?
eager wedge
If you mean actual users who are in these situations, yes
deep wind
Okay, sure can you share the Customer IDs for those two scenarios? They will start with cus_
eager wedge
I can, yes. Seems a little unsecure to via discord but yes I have them
deep wind
Only Stripe staff and people with access to your account can make use of those ID values.
eager wedge
Yeah, still 🙂 But here ya go:
Refunded/canceled:
[redacted]
Failed/past due:
[redacted]
lilac badger
Question
eager wedge
(please copy those down, I'll delete them in a minute. I understand someone would need api secret and whatnot but still, I like to be as secure as possible)
finite otterBOT
@lilac badger looks like you're in the wrong place, this thread is for someone else's question.
- If you have your own thread please chat there.
- If you have a question or a followup to a closed thread use one of the buttons in https://discord.com/channels/841573134531821608/842637025524842496 to get help (we don't reopen closed threads).
Note that posting inappropriate messages in other people's threads is against the rules. No worries if this was just an honest mistake, but anyone who violates the rules multiple times will be removed from this server.
deep wind
Okay nope, missed them
eager wedge
No worries:
deep wind
I'm helping multiple people here on this server so I can't always respond right away
deep wind
Okay, got 'em
For the canceled sub, I can see the active entitlements for this customer were updated on 9/22 and the subscription was then deleted on 9/27
But unfortunately our detailed logs for these actions are only retained for 15 days so i don't have more information than that.
For the failed/past due, I have more information there so still looking
eager wedge
For the canceled sub, we did this via the console:
- Refunded the user's payment
- Canceled their subscription
Step #2 should have definitely removed the entitlement, I can't imagine any counter use cases
For the failed/past due payments, they're still in a state of "retrying payment"; an argument could be made that the user's entitlement should remain during that period. It's a matter of opinion/use case, but I'd think most companies would not want users to be entitled to xyz if they didn't pay
(also, I've confirmed that once the "retry" period ends, the entitlement is automatically removed)
deep wind
Yes, entitlements are a very new API for us and we don't offer customizations in their behavior currently.
So I think the retry behavior is expected. However, I agree that deletion should remove the entitlement immdeiately
Do you have a more recent example of that scenario? I'd like to be able to review the internal logs for more details
eager wedge
No, unfortunately that's the only one. Other than the unexpected behavior we have the problem of not being able to remove the entitlement manually, at least no way I see of doing so
I could use my own card/payment to recreate that scenario (I'm the owner of the company) but I've read that's against Stripe's terms. If you folks don't mind though for testing purposes I can do that now
deep wind
You mean remove it from the Customer, right?
deep wind
You should be able to reproduce the behavior in Test mode, which would allow you to test this end-to-end
eager wedge
Ah yes, well I can do that later and send you folks the details. Any thoughts on removing the entitlement would be helpful, we're using entitlements in production so this user has had access when they shouldn't
deep wind
I will also file a ticket internally to investigate this. Can you confirm that, for the customer whose Sub was canceled, their entitlement originated from this Subscription: sub_1Q1ufLCYufzy4qbXCoT73szq?
eager wedge
Yes that's correct
In test mode, I just refunded/canceled a few users subscriptions and the entitlements were correctly removed. So maybe a bug you guys already fixed
deep wind
Hmmmm ... 🤔
eager wedge
I personally did the refund/cancel on that customer so I know for sure, we refunded then canceled in the same way I just did in test mode
deep wind
Yeah I'm looking for any internal tickets that suggest this error was fixed
deep wind
Okay, I think this was resolved
eager wedge
Sounds good. Only question remaining is how we can get that one user's entitlement state back to what it should be
deep wind
Unfortunately I cannot help with that. I recommend you write in to Support here; https://support.stripe.com/contact and request that the customer's enrollment in that entitlement be revoked. I can also file a feature request to expose an API method to allow you to take this action yourself.
eager wedge
No worries, I'll open a ticket there. Manually changing entitlements is probably not a good idea imo
Thanks for the help
deep wind
I'm happy to shed what 💡 I can 🙂
Because of the complexity of our billing integrations, since merchants want so many different ways to configure their subscriptions, I generally recommend having complete end-to-end simulations of each billing flow in Test mode. This allows you to confirm expected behavior before going live with a feature.
I know it's a lot of work but I think it saveds on headache in the end
eager wedge
Yeah makes sense