Last post Oct 23, 2014 01:09 PM by AidyF
Oct 23, 2014 10:55 AM|Duc1960|LINK
Looking for best practices of implementing the following scenario - we would like to register users only after they have successfully completed an online purchase on our web site.
I.e. when anonymous user decides to purchase from the website, we would prompt to choose their username/password or associate FB/Google account for SSO, then initiate payment for service being offered. If the payment comes through, then the user account
is provisioned. If the payment fails or user quits payment workflow half way through (e.g. cancels or closes browser before submitting the payment), no user shall be provisioned.
We do not want to create "temporary"/disabled accounts via .NET and make sure to discard them later if the payment is not completed e.g. within 24 hours., but would rather keep registration information users entered, in a separate "potential accounts" table.
And if they entered their FB/Google account we would want to be able to validate that the user entered a valid FB/Google account, and save the info in the "potential accounts" table. After receiving payment confirmation, our system will provision actual user
account. A large number of new users is expected (thousands per year).
Are there built in services/providers or any best practices or examples of implementing such scenario?
Oct 23, 2014 11:12 AM|AidyF|LINK
Your "potential users" table will still need cleared out so what's the difference between clearing out a separate table and clearing out non-activated accounts from your user table? It's more work for no real benefit. I would just create non-activated
accounts and if they remain non-activated for a week (or whenever) delete them.
Oct 23, 2014 11:54 AM|Duc1960|LINK
this is because there could be hundred thousand users in the users table and the ones that need to be deleted on regular basis could be 80% of all users, resulting in a continuous "recycling" activity against the users table, i.e. a lot of deletions. Running
risk is that a large number of "useless" accounts will be created every day increasing the size and the "recycling" activity against .NET users table may affect performance of a high traffic web site.
Oct 23, 2014 12:20 PM|AidyF|LINK
Why is deleting from "Users" going to cause problems but deleting from "Potential_Users" not? SQL Server is quite a high performance database, I'm pretty sure it won't miss a beat over this. It's not like the users table is going to be constantly read
from and written to.
Oct 23, 2014 12:56 PM|Duc1960|LINK
because "potential users" is outside of the provider, its usage will not affect provider's performance.
Also, I don't know how well SqlMembershipProvider performs when you have a large number of users.
Oct 23, 2014 01:09 PM|AidyF|LINK
You could have a million users and you'll still get a user back instantly. You could try it yourself and see. If you're building something intended for lots of data and volumes then the best way to see if things are up for the job is to try them.