locked
Provisioning only users who paid RRS feed

  • Question

  • User1112138234 posted

    Greetings,

    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?

    Thanks!

    Thursday, October 23, 2014 10:55 AM

Answers

  • User-760709272 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, October 23, 2014 1:09 PM

All replies

  • User-760709272 posted

    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.

    Thursday, October 23, 2014 11:12 AM
  • User1112138234 posted

    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. 

    Thursday, October 23, 2014 11:54 AM
  • User-760709272 posted

    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.

    Thursday, October 23, 2014 12:20 PM
  • User1112138234 posted

    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.

    Thursday, October 23, 2014 12:56 PM
  • User-760709272 posted

    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.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, October 23, 2014 1:09 PM