It is ultimately the responsibility of the client's user to check the validity of the certificate.
As a service provider, apart from educating the user if you can, there is not much you can do on your side:
you don't control which certificates are trusted by the user's browser and you can't know whether the users
have verified they using SSL/TLS properly and have not ignored potential warnings.
What you need to try to assess is how your user is going to react and check your certificate.
I'm assuming the target audience for your website isn't necessarily technical or PKI expert.
How your users are going to react will depend on what they've learnt about certificates.
Unfortunately, there is a lot of conflicting or vague information on this topic out there, even coming from CA themselves
(remember that CAs have a vested interest in making their customers want to purchase more expensive certificates).
Validation modes
The general purpose of a (public key) certificate is to bind an identity to a public key (therefore binding the identity to the server using the corresponding private key in the SSL/TLS handhsake).
Lucas Kauffman has already written an answer detailing the difference between domain-validated certs, organisation-validated certs and extended-validation certs.
The real question you need to ask yourself is what you are trying to prove to the user.
The difference between these types of certificates is how that identity itself is defined.
The domain-validated certificates guarantee you that the certificate was issued to the owner of that domain. No more, but no less (I'm assuming the validation procedure was correct here). In many cases, this is sufficient. It all depends on whether the website you are promoting needs to be linked to an institution that is already well known off-line. Certificates that are validated against an organisation (OV and EV certs) are mainly useful when you need to tie the domain to a physical organisation too.
For example, it's useful for a institution that was initially known via its building (e.g. Bank of America) to be able to say that a certificate for bankofamerica.com is indeed for the place where you've given your physical money. In this case, it makes sense to use an OV or EV certificate. This can also be useful is there is ambiguity regarding which institution is behind the domain name (e.g. apple.com and apple.co.uk), which is even more important is the similar domain name is owned by a rival/attacker using the name similarity for bad purposes.
In contrast, www.google.com is what defines Google to the public; Google has no need to prove that google.com belongs to the real Google. As a result, it's using a domain-validated certificate (same for amazon.com).
Again, this is really useful if the user knows how to check this. Browsers don't really help here. Firefox just says "which is run by (unknown)" if you want more details about the cert at www.google.com, without really saying what is meant by this.
Extended-validation certificates are an attempt to improve this, by making the organisation-validation procedure more strict, and by making the result more visible: green bar and more visible organisation.
Unfortunately, this is sometimes used in a way that increases confusion, I think. Here is an example that you can check by yourself: one of the large UK banks (NatWest) uses the https://www.nwolb.com/ for its on-line banking services. It's far from obvious that the domain name belongs to NatWest (who also own the more logical natwest.co.uk name, by the way). Worse, the extended validation (if you check the name next to the green bar) is done against "Royal Bank of Scotland Group plc":
For those who follow financial news, it makes sense because both RBS and NatWest belong to the same group, but technically, RBS and NatWest are competitors (and both have branches on the high street in the UK -- although that's going to change).
If your user doesn't have that extra knowledge about which groups trade under which name, the fact that a certificate is issued to the name of a potential competitor should ring alarm bells. If, as a user, you saw a certificate on gooooogle.com issued to Microsoft or Yahoo, however green the bar is, you should not treat this as Google's site.
One point to bear in mind with EV certificates is that their configuration is hard-coded into the browsers. This is a compile-type setting, which cannot be configured later on (unlike normal trusted certificate stores, where you could add your own institutional CA cert, for example). From a more cynical point of view, some could consider this as a convenient way for the main players to keep a strong position in the market.
Seals
Some CAs also offer various "seals" that you can put on your website, usually with different colours depending on the type of certificate you purchased. They seem to be intended as an extra step to prevent less-reputable CAs issuing a valid certificate to the wrong party.
As far as I'm aware, these are completely useless from a security point of view. Indeed, when you click on it to have your certificate verified (for example, if you click on GoDaddy's "verified an secure" logo, you end up on this page), nothing tells you that the certificate you see is the same as the one that's sent to the service behind seal.godaddy.com. Indeed, if there was a MITM attacker between you and example.com, with another valid certificate for example.com issued by a sloppy CA, that MITM attacker wouldn't be between example.com and seal.godaddy.com. Unless the user really looks at the certificate in detail, the seal wouldn't help very much (bearing in mind that the attacker could simply remove the seal link or point it to the one from the other CA).
Insurances
Some certificates also come with some sort of insurance. You would get some sort of compensation should something go wrong during a transaction up to a limited amount. It's not clear to me what the conditions to claim such insurance would be.
Which one to choose?
At the end of the day, most users keep the default list of trusted CA certificates that are bundled with their OS or browser. Since the user interface don't distinguish between CAs very clearly, the overall security as seen by the user (whose responsibility it is to check the certificate) will be driven down by the lowest common denominator in each category (blue and green bars).
If it's important to tie the domain name to a "brick and mortar" organisation, it's worth considering an EV certificate. I personally don't think that the way UIs distinguish DV and OV certs is good enough to make displaying the organisation name with a blue bar useful.
If you're primarily known by your domain (or if there is no ambiguity at all that the domain is yours, from a user's point of view), go for any blue bar certificate. (Check the insurance details if that's relevant to your website.)
