Hacker News new | comments | show | ask | jobs | submit login
Getting website registration completely wrong (reprog.wordpress.com)
65 points by ColinWright 1526 days ago | hide | past | web | favorite | 85 comments



I think there is a sequence of reasonable thoughts that would justify this design.

Anyone who has ever run a website with a signup form will know that a surprisingly large number of people are unable to type their own email address correctly. If the email address is wrong, there is no way to contact the user nor to verify their account. So there is some sense in forcing people to at least type the same thing twice, annoying though it is to the majority of us who have no trouble typing our email address.

If you don’t know your password, that is recoverable as long as your email address is correct in the system, because you can get a password reset link emailed to you.

So it is not entirely unreasonable to conclude that it is more important for the email address to be typed correctly than the password.


This is a genuine excerpt from the users table on a site I run, but with $$$ to obfuscate part of the address:

Mr Crosby (crosby$$$@btinternet.co)

MR Crosby (crosby$$$@btintenet.com)

Mr Crosby (crosby$$$@btinternet.compost)

MR Crosby (crosby$$$@btinternet.com)


As others have said, there are better ways to ensure you get a valid email address other than making the user type it twice.

In real life, there will ALWAYS be people who manage to typo the same thing twice, there will always be mailservers who respond with "250 Recipient Ok" for bad emails, there will always be domains with MX records but without a mailserver.

The difference with each of these validations is who performs the validations, keeping the validation automated and between YOU and the destination mail server administrators is a much better choice IMO.


If there are no MX records for a domain the mail should be delivered to the A-record.

If there are MX records for the domain, but mail delivery to it fails, it should not try to deliver to the A-record.

http://tools.ietf.org/html/rfc2821#section-5


There's really only one good way to validate email addresses: send a mail to it, and let the user respond to something in that mail. If you don't do that, it could still be someone else's email address, or an address nobody reads.

If it's really that important, use it to check that it works.


Yesterday I started getting someone else's K-Mart and Sears receipts.

Today I discovered I have an account on Roblox.com.

I'm going to guess that in both cases someone managed to enter not-their-email-address twice, correctly.

"Valid address" really means "the person who in fact gets mail at that address asked to get that mail."


> there will always be domains with MX records but without a mailserver.

Ouch, that sounds like a pain to deal with. But I will mention that MX records are not required, so don't forget about the opposite situation where they have a mailserver and no MX.


I have this exact issue as well.

We have just today changed our site to use this https://github.com/Kicksend/mailcheck , It will be interesting to see how well it works.


so do validation that the domain exists. Don't make the user solve a technical problem.


How about a website registration that looks like this:

"Send an email to register@example.com with the following code: ABC123"

Your registration process gets the email, you can deduce the person's name and email address without typos, and you can then reply with an activation link allowing a password to be set (that page could also allow verifying/editing their "real name").

This lets users register without typing anything except their password on the activation page.

A drawback of this is that it breaks the "flow" of your site by having the user switch over to their email app. But most sites send an "activation" email anyway, so I'm not sure it's a net negative.

Edit: you probably don't even need to ask them to copy/paste the code. The code could be embedded in the address (e.g. register+ABC123@example.com) or in the subject attribute of the mailto link) or you might not even need a "code" at all.


FWIW, curecos.com, IIRC has a signup process that goes like:

* enter password * get confirmation email with link to signup

The activation comes _before_ the signup, as in your example, minus the email reply.


I like the idea, but you can't deduce name from email address, or at least not often enough to use it even to prefill the field in the form.


I believe the suggestion is to use the "From:" field of the email, which for a significant fraction (perhaps even majority) of people includes their name. I think it's an interesting idea.


Yep, rather straight forward thought there.

If you are outside, it's late, you maybe had a drink and it's even raining this can happen. You can also accidentally cause a submit while entering your email address.

Of course when you autofill forms that's not a problem, but thinking that people don't mistype, which can be hard to see, depending on the mistake you made is kinda stupid and there is nothing more annoying then realizing your favorite login name is used in unaccessible just because the person programming the system thought it was impossible to ever enter your email address incorrectly.


You could also just ask the mail server directly like this: https://gist.github.com/poizan42/2731787

Sure this won't work for every SMTP server as some will just "OK" the mail first and send a bounce back later, but neither will the "ask for email twice" approach work every time, and at least it guarantees that the domain exists and has a functioning SMTP server.


A better alternative is to send an email for verification. If the email bounces, you can mark the account as unverified and ask them to verify their email again.


Thats what I do. But it might take time (graylisting for example). So instant feedback is not possible.


Like most rants in blog post format, the title is overly sensational. Claiming that Deviant Art's registration process is completely wrong just because it allegedly has one unnecessary field doesn't support the author's credibility. Didn't millions of users manage to register to a website despite the use of a "Retype your email" field? A completely broken process is one that fails to fulfill its objective at all. I don't think that's the case here.

To be more specific, the email is almost always used as the unique identifier of a user. Getting that information right is crucial to the perennity of your user base. Usernames and passwords can be and are often changed.

On a more general note, unsolicited advice is never well perceived when dealing in absolutes, especially when you are unaware of the context in which the website you're criticizing was designed.


> I wish I knew how this idiot trend of “Retype Email Address” got started (or CTRL-C, Tab. CTRL-V as I think of it).

Ancient mistypes of email addresses carried some mild risk.

User would mistype their email address, inadvertently entering a valid (but not their) email address.

The webmaster would send a confirmation email to that address. Stupid webmasters skipped the confirmation step and just sent to that address.

The person getting the email would report those emails as spam. Sometimes their reports would be effective and block email delivery for a while.

Someone ages ago had a nice website talking about this. They had a domain that often got email for other people from mistyped domain names.

Obviously allowing users to copy paste the email address is sub-optimal.

What's the better flow today? Send a confirmation email and allow the user to correct the address if they don't get the email?


Semi-relevent xkcd: http://xkcd.com/1279/


The whole point of that comic is that clueless people intentionally forget what their own email address is. I have that happen to me all the time, and it always happens in too many places to be a typo (or anything the user would ever catch by typing the address twice)


You can always use "Forgot Password" if you mistyped a password. You can't if you mistyped the e-mail address (the username you wanted is gone).


As he said, it's CTRL+C, Tab, CTRL+V. In case I make a typo it'll be in both fields anyway.


The principle of it is still valid anyway: the email is the one field you absolutely need to get right. The password can be recovered to that email later.


If the email is really that important, send a mail to it which the user has to do something with. That's the only way you can be sure it's the correct email address.


Which is a common pattern, however can easily be negated by the fact that the person may think their activation link is in their spam folder (when in fact they didn't type in their email address correctly). User gives up and moves along.


Show them the message "an email has been sent to mbesto@ycombinator.com. Please click on the link in that mail to verify your address". Below that, a link "change email address".

Now, when they realize they didn't get the email, they may notice the difference and they can fix it.

If they're unable to type their email address, and they're unable to recognize a mistake in it, then I don't see what hope there is for them.


And if the email has been mistyped user will never get it and will end up being even more pissed than one would be for having to re-type the email. No perfect solutions...


The people who are likely to mistype their email might not know about copy/paste.

Yes there are people who don't know about copy/paste.


Why not disable copy/pasting and display a notice? "Please manually type your email in, it could save you a headache in the future!"


"So we decided to give you a headache right now. Just in case."


Another comment says they do exactly this..

Have a read of the comments for a sample of just how much people hate this.


I was surprised over how much hate I received on my comment, even with this feature we get a ton non valid emails. I don't want to think of how many we would get without it.


"even with this feature"

Have you measured whether this feature actually helps anything? As the author said, people can see typos. But people who don't know their own email addresses will happily repeat errors.


and as someone with first.last@gmail.com I know that there are many people who give out wrong email addresses.


The tech guys at deviantart are constantly working to make the sign-up flow better and then to keep people coming back, and given the relatively large number of younger users they get it wouldn't surprise me in the slightest if they implemented that after finding a lot of people get their email addresses wrong.

As an aside, they also post fairly detailed blog posts about some of the challenges of working at the kind of scale dA faces (http://dt.deviantart.com/blog/)


The double email entry makes perfect sense if you accept the following base assumption:

The designer of this form is the Kwisatz Haderach! He sees all of your potential futures laid out before him, almost as if they were lines on a whiteboard. To him you are not a person filling out a form, you are a quantum of potential revenue in a treacherous maze of possible outcomes. He is afraid, because he sees many many futures in which you simply cease to exist - your potential collapses to $0. There are a precious few paths where you survive this peril, and every single one begins with you typing in your email address correctly. A password can be recovered, but you can not.

It other words, this form is for quanta of potential revenue, not people. Don't forget the quanta pay the bills though.


Back in the day, emails would take a long time to arrive, and would often end up in the junk mail folder.

Popular sites, that others copied, would drop your outbound email in their MTA, which was probably pretty busy, or on a not-so-fast computer. Might take five/ten minutes to arrive.

And prior to DKIM/SPF, a high proportion of emails would land in your junk box.

Nowadays, you can just ask for an email addy, and it hits the user's inbox in a few seconds, and you can take them to step B from there. But that was harder back then, so you had to ask for the email twice.

I like the "show password" option, instead of asking for it twice. You need to obfuscate it though for desktop computers, as you can't assume a private audience.


If you make "show password" a checkbox defaulting to off then it shouldn't need obfuscation. It's on the user to decide if their surroundings are private enough, and actually I think one is more likely to have an audience when using a mobile (such as on public transport) than on a desktop computer.


I have a sign-up page with one email field. I get many errors because people (mostly younger people that probably don't use email regularly) type in incorrect email addresses (leave out the '@', use : instead of . and so on).

I wonder if this double entry would make them think twice? And probably these people don't know about CTRL-C/CTRL-V so they have to enter the address twice.


Some very basic client side validation would be your friend. Just check for the existence of an @ symbol, at least.


> Just check for the existence of an @ symbol, at least.

"At least"? That's pretty much all the client-side validation you can do. The next step is sending an email to it.

The specification of what kind of email address is valid or invalid is horrendously complex. I've seen too many sites reject perfectly valid email addresses. Don't do this. If it contains an @, try mailing to it. Let the user respond to that email somehow, and you've got the only reliable email validation and verification that's possible.


This. Another experiment worth conducting is displaying their email address as a checkbox near the submit button:

(x) foobar@example.com is my email address where I can confirm my account

[Create account button]


Checking for @ (and some other basic stuff) would be ok.

I don't want to confuse users with more checkboxes/displays than necessary. Interesting experiment? Yes probably, but I would need more data than I have now to get meaningful results.


or use HTML5 <input type="email">


I get many errors because people (mostly younger people that probably don't use email regularly) type in incorrect email addresses (leave out the '@', use : instead of . and so on).

While I've heard of this trend, I find it quite surprising.

Registration for almost any website/app/service needs a valid email address. And. although IM/Twitter/FB take care of informal communication [can you get a Twitter account without email?], there are plenty of cases where email still works better than the alternatives. How old are these younger people?


They are mostly in 9th grade. I don't know their age, but perhaps around 14-15?


Someone doesn't know what an email address is supposed to look like. They fill the first email field. Now they still don't know what an email address is supposed to look like, but they do know that the "confirm email address" field is supposed to look exactly like the "email address" field.


I disagree with this post. What if the user types in their email and doesn't 'see' that they've mispelt their email address, then they'll think the site is crap when it doesn't deliver their signup verification or even worse order confirmation email to their inbox, because they were crap and got their own email wrong? By forcing users to retype the email address, it ensures that it is 100% correct and important emails will definitely get delivered...


Good call about typing the password twice being a good idea.

One thing that I find infuriating are sign up forms that include two password inputs alongside a sea of other fields.

What normally happens is that I have some validation issue upon submission, I forget to tick a box or something, the password fields are then cleared and I have to enter them both again. And so on.


I like that 'Rules of Usability'[1] that the article links to. It could be used as a great checklist for your apps.

1: http://www.catb.org/esr/writings/taouu/html/ch01s03.html#rul...


Password field doesn't need a confirmation.

In an off chance that the user mistypes the password when registering, there's an over-email password reset option. But if he manages to mistype the password and the email, then it's just the natural selection.


It's easy to criticise something imperfect that exists and just claim it shouldn't be that way. It's far more challenging to understand why things are the way they are and propose something better that addresses the same problems.


This seems like good practice to me. It's saved me a few times. If the email is entered incorrectly the user can't log in, you can't contact them, they'll probably blame you (as they don't know why they can't login) and never use the site. Asking them to re-enter it is a good way to catch this mistake. The same applies to passwords.

This is something I've noticed a lot in mobile apps. Because they know you hate typing on a touch keyboard they don't ask you to re-enter your password. It's bad practice in my opinion and it's something I've noticed in some major apps.


I just disagree with this article in general. Other people have mentioned the same point. I've run online stores for a long time and written a few e commerce platforms. People type their email wrong a lot. They will call and complain if they don't get their confirmation emails and shipping notifications. One quick look at the order inevitably shows a typo in the email field. The confirmation box fixes this 99% of the time. So I will continue to use it.


Retyping email is much better than retyping the password. One time I had typed both password and confirmation wrong. Both were equal, but it wasn't what I thought I typed, I must had my hands in wrong place at the keyboard or something. If it was my email I would see it immediately and avoid a major 'wtf happened' later. Getting the email wrong is WAY WORST than getting the password wrong, after all the password recovery is made through it and nowadays. And it's also your login.

As for the copying n pasting just adding 'onpaste="return false;"' to the confirmation textbox would prevent on the majority of the browsers.

“Every time you require a human user to tell a computer things that it already knows or can deduce, you are making a human serve the machine“. Jesus, isn't this one pretty obvious? It's not a matter of ease of use, it's a matter of correctness of the user input. That's why is a freaking confirmation. This statement is completely out of place in the article, IMO.


I wager the demographic who type their email wrong don't think to copy and past like that. Don't hamper the users who are trying to beat the system, it's not for them.


This is the exact same flow that facebook uses. The benefits are that if you have the right email address you can reset your password easily.

I think we have become slightly conditioned to repeat passwords. It feels strangely "dangerous" whenever I sign up without repeating a password.


For the password, I prefer the 'show password temporarily' option, like I did here for mySimpleAds... https://use.mysimpleads.com/account/register


Is this a better workflow?

1) user form consist of a) username b) e-mail c) password d) retype password

2) if all of the above is ok, and not already in use, allow user access to site

3) if running an e-commerce site, or something that depends massively on their e-mail address actually belonging to the user. a) allow user to see e-mail they specified at login somewhere (my account) b) make user retype e-mail at point of purchase c) make user confirm e-mail before purchase, and change e-mail if no confirmation has been sent (obviously a,b and c are either/or type statements)

alternatively, if older users are the problem... first 1/2 of Logans Run anyone?


We have disabled CTRL+C, CTRL+V on our site, just due to this, so users really need to validate there email.

EDIT: Just to clarify since someone took up a example with no paste on password. We just have this function on the email-field.


I hate you.

It's a lazy naive "solution" that makes my life harder for no good reason. Take effort to implement good validation and recovery:

1. Use client-side validation (HTML5 field ideally) and look up the domain part. Offer "did you mean" suggestion for typos of very popular domains.

2. As long as user is signed in allow them to change e-mail post registration (e.g. "We've sent e-mail to xxtypo@geemail.com and haven't received confirmation. [Change e-mail address]")


That is certainly ONE way of making me hate your site (and never use it if I can avoid it).

Arguably even worse is TalkTalk's login form, which disables pasting into the password field. So I can't just copy my password there from a locket, I have to retype it. As a result I have chosen a stupidly easy-to-break password, just so I have a chance of typing it correctly, unlike the "gr2@tGig^monE"-stype passwords I otherwise use.


And yes, I know, Correct Horse Battery Staple. That's all very well until you have to register on a web-site that restricts passwords to 8-12 characters.


A surprising number of websites explicitly require easy passwords (though they call it something different). If you want a mix of uppercase, lowercase and numbers, with a length of 8-12, you're going to get Welcome01.


A pox upon you. I have Greasemonkey scripts for this kind of annoyance, as well as the autocomplete=off bullshit that prevents my perfectly safe password manager from improving security by not having to go through the clipboard. Despite my workarounds, every time I see this kind of misbehaviour, I hate you, your website and your company a little more.


Did I say I did it on password field or at login?

EDIT: Edited my main commented due to a comment regarding password fields blocking CTRL+V


More than once I have completely lost interest in a product/service firmly on the base of these kinds of 'fixes'.

It seems like if I'm restricted by this right now (hell, I type my email in roughly 6-7 times a day, with 100% success!) what level of 'fixes' will I experience when I am inside?


So glad this pref exists in Firefox, for just this reason:

https://developer.mozilla.org/en-US/docs/Mozilla/Preferences...


Thanks, useful. I'm sure it'll break copy/paste in Google Docs, but that's a small price to way.


I hope at the very least that you're at least doing it for the specific email fields rather than messing with password copy-and-paste.

Here's a discussion of disabling paste on passwords and usernames:

http://stackoverflow.com/questions/4760132/improving-login-s...


Yes, just the e-mail field, to do it on password field is just annoyance.


This is awful - Almost as bad as breaking the "back button".


I believe the theory is if you make users type it twice you can spot if they're likely to get it wrong and force them to get it right - for many signups it can be a vital piece of information, after all. Since email addresses are generally autocompleted by my browser, I can't remember not simply copying/pasting between the fields.

I like the idea of verifying the password, this is how password programs usually work.


How about instead of two email input fields you do this:

One email field, when it loses focus (or you submit the form) a pop-up displays the email you entered and asks you if this is correct (Y/N). If you hit no then it focuses onto the email field for the user to make changes, and repeat.

The second field is just about forcing a user to be careful so why not make it a bit easier with a simple 'Yes' click instead?


Based on everything I've read about how often people actually read pop-ups, that sounds like it would make things more annoying and help nothing.


well if you have a question blocking the submission of a form the user would have to acknowledge it and surely click 'yes' is less annoying (and time consuming) than having to re-type the whole address?


Not for people who were happily navigating with their keyboard. Not for people who were going to copy/paste anyway. Not for people who wanted to look at something in another tab before finishing your aggressively self-important webform. Not for people who will inevitably accidentally hit something in the dialog before even seeing it because they were typing too fast and it accepted their keyboard input. Not for people who will resent you on principle for stealing their focus to stop the proceedings with idiocy (google it). And certainly not for the people who are so tired of dialog boxes that they've given up on reading them altogether.

What you want: User reads your dialog box notifying them to double-check their email address.

What actually happens: User maybe looks at your dialog box just long enough to figure out what it is before clicking whatever they think will make it go away. A tiny proportion of anal-retentive users who would have never gotten it wrong in the first place actually do what you asked them to do.

http://arstechnica.com/security/2008/09/study-confirms-users...

> Follow-up questions revealed that the students seemed to find any dialog box a distraction from their assigned task; nearly half said that all they cared about was getting rid of these dialogs. The results suggest that a familiarity with Windows dialogs have bred a degree of contempt and that users simply don't care what the boxes say anymore.

http://mikepope.com/blog/DisplayBlog.aspx?permalink=480

> It's not that users are morons or that they "forget" to think. Its that users are trained to not think... dialog boxes usually say "If you want to tech the tech, you need to tech the tech with the teching tech tech. Tech the tech? Yes / No" If you press one of those buttons, something happens. If you press the other one, nothing happens. Very few users want nothing to happen -- in the majority of cases, whatever happens is what the user wanted to happen. Only in rare cases does something bad happen.

http://blogs.msdn.com/b/oldnewthing/archive/2003/09/01/54734...

> If you are trying to accomplish task A, and in the process of doing it, an unexpected dialog box B appears, you aren't going to stop and read and consider B carefully. You're going to try to find the quickest path to getting rid of dialog B. For most people, this means minimizing it or clicking "Cancel" or just plain ignoring it.

http://www.joelonsoftware.com/uibook/chapters/fog0000000062....

> This may sound a little harsh, but you'll see, when you do usability tests, that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it. This may be disconcerting to you as a programmer, because you imagine yourself as conducting a dialog with the user. Hey, user! You can't open that file, we don't support that file format! Still, experience shows that the more words you put on that dialog box, the fewer people will actually read it.

http://alistapart.com/article/neveruseawarning

> What about making the warning harder to ignore? A subtle warning will get passed by, so let’s pull out all the stops: we’ll blink the screen and play a loud stretching noise to ensure that the user is paying attention. Try as we might, it still won’t work. The more in-your-face the warning is, the faster we’ll want to get away from it (by clicking “Okay”) and the more mistakes we’ll make. The thing is, no matter how fully in-your-face the computer presents the warning, we’ll still make the same mistake—clicking “Okay” when we don’t mean to.

http://ignorethecode.net/blog/2008/10/31/nobody-reads/

> We all know that people don’t read dialog boxes, yet when there’s a problem with our UI, when people don’t understand what they’re supposed to do or when they do something wrong, we tend to try to solve the problem by adding more text to more dialog boxes.


I take your points but I still think dialogue boxes are important additions to interfaces when used right. What about a delete function, which is genuinely accidentally clicked upon? Should we go ahead with a damaging delete instead of issuing a warning? Adding duplicate fields to fill out is a massive pain to all users, that cannot be denied.

My idea wasn't to invoke a dialogue pop-up but rather a visual light-boxed div pop-up in that tab, which wouldn't take control of the browser. They click no then they don't get to continue, yes next time they might just hit yes to proceed without reading. But as with duplicate field entry this is just about making an attempt to get accurate data from the user with the minimum of hassle.


Ah. First let me apologize for incorrectly assuming you meant "popup" as in "JavaScript `alert`." Technically speaking, the thing you describe is no longer obnoxious.

In your hypothetical case of a delete feature, if it's something the user doesn't click on a regular basis, and if you can't offer an Undo feature (as explained in one of those links above), then it could be fine. Even if it's a focus-stealing JavaScript popup. You have to be careful not to put it on common tasks, though; if the user sees it all the time, they'll train themselves to blindly click through. That's explained in one of the links above.

In this specific case, I think it's still useless. You can't ask a user a question you just asked them and expect the answer to change. Even if the user looks at your dialog, they're usually going to interpret the question as asking "Are you an idiot?" and the answer is "No!" Even when it's "Yes."

It's analogous to the situation in tech support where the solution is something silly like "the battery is in backwards." Nearly no one will believe you thanks to the Dunning-Kreuger effect, so you have to ask them to open the battery cover and blow the dust out, hoping that they put it back in correctly (and yes, there are various reasons why they'll often be more careful than when they first made the mistake)

Someone else already mentioned the correct answer, which is finding an excuse to repeat their email address elsewhere in a context other than "Are you sure you said what you just said?" Imagine having an email address field near the top, then near the bottom of the form having a field labeled "password recovery email" with their already-typed email already filled in. Or maybe have a list of checkboxes saying "send the following types of communications to email address". And if they finish, have a confirmation page saying "Your activation email has been sent to address. If this is incorrect, click this link to fix it."


I really like the idea of 'sneaking' in a confirmation surreptitiously somewhere where they might take more notice. I do agree with your idea that if you confirm right at the point of initial data entry, the user could question if the program is itself an idiot. This is the problem with double address entry on the same form as well (is this program deaf or something?!).

In thinking through this problem I was actually applying it to a real-world scenario I am dealing with right now; Shipping / email address entry for a checkout. Barrier to entry (to making a sale) has to be very low and easy enough to complete an impulse purchase quickly. (No user accounts or registration - just let me buy the damn thing already!)

In this scenario I figured having a pop-up upon submission would not usually be expected (i.e. this is not an account registration) and so would maybe surprise the user into reading it.

However, I definitely agree when confirmation boxes are situated in well-trodden interface routes, they are pointless and annoying.


Interesting. You got me thinking how to apply "Undo not warning" to this kind of situation and this is what I came up with as a first pass. It's purely speculative but maybe you'll find some inspiration:

Automatically verify everything you can. (billing ZIP matches credit card provider, email at least vaguely resembles an email address, all required fields are filled, etc). Raise a warning only if something is obviously wrong.

If the user hasn't yet chosen something like shipping options, consider making it a second step. Then you can have a pageflow along the lines of:

-User inputs basic information (name, address, email, financial details, everything necessary to know what they ordered and how they will pay for it) -User is taken to a page where it asks for shipping options, with user's stated mailing address printed right next to the form. Have an obvious way to fix the address from this page. -Print the user's email address near the mailing address for the same reason (if you feel the need to justify it, you can have a checkbox that says "send a receipt to email address" or "use email address for package tracking)

After an order is complete, take the user to a page that says "Your confirmation number is foo. Please save this page for your records. We will also send a receipt to email_address." The most visible thing on the page besides that message is their order, with the shipping address in bold. The next obvious is a link on this page they can click if something is wrong. Even if you never use the confirmation number for anything, it gives the customer an excuse to be observant without making them feel stupid.

Have a generous cancellation policy. If someone contacts you saying an order is wrong and you're positive which order they're talking about, let them cancel it. Worry about malicious cancellations only if they prove to be a real problem.


Nice ideas! Some of them I had already implemented the same way in fact. Currently I have shipping and billing in one step - the only reason I could see for not splitting them up is that they can be different people / addresses so making them repeat an email address there might be confusing.

Right now an order number is displayed on completetion as you have described (and also emailed to them) so it's not fatal if the email address was wrong as they have a chance to note the order number down by other means. I do like the idea of telling them where the information has been emailed and giving them the option of re-sending it to a corrected address.


In the olden days, when we trusted each other, (and had to send our mail uphill, in the snow, both ways), we had the VRFY command, and you could connect to an SMTP server and ask it to verify a username.

Most admins disable VRFY these days, and rightly so.


Has anyone tried Mailgun's email address validation service?

http://blog.mailgun.com/post/free-email-validation-api-for-w...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: