Button to send email

[SaranacLake]

58 minutes ago, kicken said:

If your goal is ease of use for the end user to maximize sales, then you could reduce the friction some while still gaining most of the benefits.

As was mentioned before, don't make the verification required to process the transaction, but rather do it after the fact.  There's really no need for the user to enter a code, most places just send a link with a unique code in the URL.  User clicks the link and the email is verified.   Show the user a notice on login that their email needs to be verified still, and possibly lock out their account until verification is complete after some time.

If it were me, I'd probably have a process such as:

1. User selects a subscription type
2. Gather account & payment information
3. Create account, send verification email
4. Let the user access what they paid for.
5. After 3-7 days, restrict the account if the email is still unverified

 

I have to kick your idea around, but I have to say that your idea is looking better than mine!  🏆

58 minutes ago, kicken said:

That works around potential email delays and gets the user to their content the quickest.  You could do the double email field as an additional measure to try and catch people fat-fingering their email.  In most cases though the user will probably enter it correctly, get the verification email, and click the link on their own time without issue.

 

The idea about the 3-7 days thing is very interesting...

 

58 minutes ago, kicken said:

If the user does fat-finger their email (intentially enter an invalid one) they will get their content for a while, but then have to correct the problem.  Allow a user to change their email if their account is restricted due to no verification.  Depending on the level of security you want, maybe require the password as well to re-start the verification process.

Yeah, that is a bit trickier and I definitely have to think about that one.

Scenario #1: Phat-fingered registration email

In this case, the customer doesn't get the activation email.  And to make matters even more complicated, your email and password are how you log in.  So if a customer phat-fingers their email (e.g. "kikken@gmail.com") then when he/she goes to log in as "kicken@gmail.com" they won't be able to log in?!  And if they then send me an email explaining, I'm not going to trust that.  So now what do I do?  Do I have to call them at their billing tele #?  Even there, how do I know that I am speaking to "Kicken" and not you kid brother/sister??

See the problem?

 

Scenario #2: Entered fake email

Here, the person might be able to successfully log in as "screw_you@gmail.com", but since they didn't get the email, now I have to allow them to change their email to something legitimate.  I guess (??) because that fake email was used when they they log in after registration, that I can assume it is the same person who paid by credit card, but that sorta makes me nervous...

And if they made up a fake email and cannot remember it, then you have the same issues as scenario #1.

See what I am saying??

There is no "silver bullet" in any design.  My way has pros with security, but your way has pros with closing the deal.

I think we are getting closer to a solution, but I think it needs to be tweaked to address your concerns and my concerns.

 

 

58 minutes ago, kicken said:

A third option to minimize end-user friction would be to let them use something like google, facebook or twitter to login instead of creating an account.  A lot of people prefer that these days as it's one less account/password to have to remember.  I know I personally am far more likely to hit the 'Login with Google' button than I am the 'Create an account' button.

Actually that is horrible for security since all of these sites get hacked!!

Plus I think Facebook/Twitter/Google are scum....  😉

 

 

[SaranacLake]

1 hour ago, cyberRobot said:

That all depends on the person. Some will be fine, some won't, others will we be somewhere in between. To be honest, you'll never make everyone happy. The best you can do is try something and see how things go. If you're not getting the results you want, you can always adjust. Depending on how big your audience is and how much time you have for testing, you could develop 2 separate options of the sign-up process. One would require the users to validate the email address. The other would skip the validation. You could then use A/B testing to see which option results in more website signups. More information about A/B testing can be found here:
https://en.wikipedia.org/wiki/A/B_testing

Thanks to everyone for their ideas.  I think @kicken brought up some great points, and I'm sure there is a way to "have my cake and eat it too", we just aren't quite there yet...

But this is *exactly* the kind of mental exercise that I needed help with, so thanks everyone!!  👍

[kicken]

3 hours ago, SaranacLake said:

Yeah, that is a bit trickier and I definitely have to think about that one.

Scenario #1: Phat-fingered registration email

...

Scenario #2: Entered fake email

Everything is a trade off between security and usability. That's why things like cryptocurrencies haven't really caught on.  The security on them is generally pretty good, coins can only be accessed using praticaly impossible to break private key. The usability is awful for the average person. Didn't back up your key and your HDD caught fire?  Well, there goes your life savings up in smoke. 

The question is where do you want to draw the line, and that's usually determined by the risk and consequences of a breach.   If you were running a bank, a breach would be bad news.   In most sites though, a breach is both unlikely to occur and unlikely to cause major problems.  So the question is where do you want to draw that line?  I've known some companies that require you to email/fax a copy of a government issued ID to their support and they will only give you access to the account if the name on that matches the name on the account.   That'd always be an option.  Seems a bit overkill for a simple e-book store site imo though.

Again, if it were me I'd probably solve the above two scenarios by just using something like having the person verify their billing details or some other bit of information.  For example, "What's your First & Last name, and the last 4 of the card you used?"  If they can answer that, it'd probably be ok to just assume they are the owner of the account and change the email.  Practically, how likely is it that someone would contact support to try and break into a different account and actually know that info?  Fairly unlikely.  What's the worst that can happen if someone actually succeeds? They get access to someone else's books, and possibly inconvenience the real owner?  Not that big of a deal.

 

[SaranacLake]

10 hours ago, kicken said:

Everything is a trade off between security and usability. That's why things like cryptocurrencies haven't really caught on.  The security on them is generally pretty good, coins can only be accessed using praticaly impossible to break private key. The usability is awful for the average person. Didn't back up your key and your HDD caught fire?  Well, there goes your life savings up in smoke. 

The question is where do you want to draw the line, and that's usually determined by the risk and consequences of a breach.   If you were running a bank, a breach would be bad news.   In most sites though, a breach is both unlikely to occur and unlikely to cause major problems.  So the question is where do you want to draw that line?  I've known some companies that require you to email/fax a copy of a government issued ID to their support and they will only give you access to the account if the name on that matches the name on the account.   That'd always be an option.  Seems a bit overkill for a simple e-book store site imo though.

Again, if it were me I'd probably solve the above two scenarios by just using something like having the person verify their billing details or some other bit of information.  For example, "What's your First & Last name, and the last 4 of the card you used?"  If they can answer that, it'd probably be ok to just assume they are the owner of the account and change the email.  Practically, how likely is it that someone would contact support to try and break into a different account and actually know that info?  Fairly unlikely.  What's the worst that can happen if someone actually succeeds? They get access to someone else's books, and possibly inconvenience the real owner?  Not that big of a deal.

 

Let's see if I can remember what I formulated last night...

	Step 1: Review Cart
	 
	Step 2: Enter Account Details
	Username: ______________
	Email: _________________
	**Note: Make sure this email is valid, because you will need to respond to the activation email in order to use this account.
	Password: ______________
	Confirm Password: _________________
	 
	Step 3: Enter Payment Details
	And son on....
	 
	<< Process Order>>
	

 

When the form is submitted...

- The data above in inserted into the database.

- Payment details are sent to the processor.

- An activation email is sent to the email listed above.

- Money goes into my bank account!  🙂

 

As stated, in order to start using the account, the user will need to click on a link in the activation email.

They will be prompted to do so at log in if this hasn't been done, and cannot use their account until it is done.

If the user never received the email, I could resend it.

If the user used a bogus email, then they would need to call me.  At that time I would require them to create a new account using a valid email and pay a 2nd time, and after they activated the new account, I would credit them for the first charge and close out the bogus account.  If they contested this, I would refund their money, however there wouldn't be a chargeback since they have to accept my TOS in the checkout and I will spell out that lying is no grounds for a chargeback.

If the user made a type-o in their email, I would require the same process as above.

This may seem harsh, but people need to follow rules and use common-sense.  And I want the account creation, validation and payment to happen on one transaction to protect myself and the customer.

I could allow the user to log in with a bogus email and charge it and then resend the code, but that is too much extra logic to have to add to accommodate dumb asses!!

 

I *think* this applies the wisdom that @kicken and @cyberRobot provided above, but let me know your thoughts!

 

Edited September 6, 2019 by SaranacLake

[Psycho]

OK, I'll admit I stopped reading the responses after a while.

If your stated goal is to prevent cart abandonment, then don't add unnecessary steps to the process! I say go ahead and let them complete the checkout process with an unconfirmed email address. After they have completed the payment process, display the order confirmation details along with a warning that their email has not been confirmed. It should warn them that until it is verified that being able to look up order status, change orders, whatever may not be possible. That should give them a call to action to verify it.

Also, one problem with your plan that I didn't see stated. If a user enters an email address and you have the system send a code, what is to prevent the user from changing the email address in the form before the final submission?

Quote

 

When they click that button, I would...

- Save the Username and Email to the $_SESSION

- Generate a Security Code

- INSERT the Username, Email, and Security Code into the Member table

- Email the Security Code

- Reload Checkout.php displaying the prepopulated Username and Email fields, PLUS all of the other fields (e.g. Password, Credit Card details, etc.)

 

>> user then decides they want to use a different email and changes the value before the final submission.

So, you can't assume that the email address at the final submission is the same as the one previously provided. You would have to do a check to make sure it wasn't changed and, if so, do another email validation. This is all overly complicated.

Plus, you should never re-populate sensitive fields such as passwords and CC numbers. This is a bad approach on many levels as far as I'm concerned.

Edited September 6, 2019 by Psycho

[SaranacLake]

2 hours ago, Psycho said:

OK, I'll admit I stopped reading the responses after a while.

Ouch!  😛

 

2 hours ago, Psycho said:

If your stated goal is to prevent cart abandonment, then don't add unnecessary steps to the process! I say go ahead and let them complete the checkout process with an unconfirmed email address. After they have completed the payment process, display the order confirmation details along with a warning that their email has not been confirmed. It should warn them that until it is verified that being able to look up order status, change orders, whatever may not be possible. That should give them a call to action to verify it.

Okay.

 

2 hours ago, Psycho said:

Also, one problem with your plan that I didn't see stated. If a user enters an email address and you have the system send a code, what is to prevent the user from changing the email address in the form before the final submission?

>> user then decides they want to use a different email and changes the value before the final submission.

So, you can't assume that the email address at the final submission is the same as the one previously provided. You would have to do a check to make sure it wasn't changed and, if so, do another email validation. This is all overly complicated.

Good catch!!!  Yes, I missed that fact!

 

2 hours ago, Psycho said:

Plus, you should never re-populate sensitive fields such as passwords and CC numbers. This is a bad approach on many levels as far as I'm concerned.

In my proposal above, all I would be re-populating would be the username and email.  The password and cc details fields would not appear until AFTER the form re-loads after the email was sent.

As I said in my last post that you didn't completely read, I think @kicken and @cyberRobot (and you) are right in that maybe it is better to confirm the email after I get their money.

However, to my point, if the user provides a bogus email or cannot type, then I will make it difficult for them to fix things.  Not to be a jerk, but to ensure the person registering and paying is the same person talking to me via email.

I'm sure some people would find the policy I proposed to be too draconian, but it seems like the only reasonable way to address those exceptions.

Feel free to suggest a better way!  🙂