https://descope.com logo
Join Slack
Powered by
:ring_buoy::grey_question:Stripe subscription stat...
# ask-a-descoper
t
🛟❔Stripe subscription states and Descope user creation and state management Edge case of concern: User cancels subscription to our club, then buys a new subscription. See sub thread…
message has been deleted
We are setting up the webhooks between our stripe instance and Descope for user creation and management.
We use phone number for our OTP. Phone number is the id
Copy code
[
	{
		"identifier": "+19015799974",
		"displayName": "Thor Von Priestly",
		"phonenumber": "+19015799974",
		"verifiedPhone": true,
		"status": "enabled"
	  }
	]
Question: Given that we are setting canceled users to inactive rather than deleting them, are we headed for an issue if a user cancels a membership, then buys a new one on the same phone number where we have an inactive user already using that phone number as their id?
b
Yes Laura. LoginID is unique, so that will create a problem. Best would be to re-enable them and then activate their subscription. Otherwise you'll need to delete them, which i guess is not ideal.
t
Depends on our position about what cancelation means.
Given that stripe has a paused state which can be triggered by: • Payment processing failure • CC information exp • User choice • Merchant choice We are in the position to support a temp condition where the user has access revoked but then programmatically reinstated.
If a customer is in a canceled state the following has happened: • Voluntary cancelation of membership • We canceled them for: ◦ Non Payment ◦ Violations of our TOS or Member Code of Conduct
My leaning presently is to treat canceled as a delete of the user in Descope.
The log of the user will exist for auditing, and the ID will get freed.
Thank you for your answer — That will help me with policy creation for membership
b
Sure thing! Do you have any estimation of scale of such scenarios?
remember that the new user will be generated with a new user ID as well.
t
None at this point
👍 1
Currently user ID and phone number match
The json payload we are using currently injects the phone number as the userID rather than a random ID
Are we making a poor life choice?
Our Auth use case is OTP via SMS
b
think you mean LoginID. which can be phone or email. In that case - that's a good life choice. I was talking about the Descope User ID
t
birthday party parrotYey for good life choices.
😂 3
Open in Slack
PreviousNext
Powered by