Password itself is an exception, I agree with you since you don't need the plain value at all, you can get away with comparing hashes. But how about CC data?

Couldn't you do the same? Hash-spaces are segregated by zip codes (hash(zip) is the key to buckets) and then hash the credit card and cvv; compare to verify

Store last 4 digits of cc and mastercard vs visa to provide the "is this the correct card?" form

I'm not sure you can. If a site asks you for CC and CVV data it should already be PCI compliant, say a payment processor. Don't they need the plain text CC and CVV to be able to bill it, if it's a first time user? How can the client send a hash, compare it to what?

I'm really curious about how you see this working, I can't understand how you can forever obfuscate your CC info. I assume at some point the server needs your plain data.

I've personally never worked with payment processors, but I don't see why your intermediate servers would need to have it plaintext

To the payment processor, they'll always have the cc/cvv info, or rather, the hash of it, to verify with. If they don't have it, then I imagine the user doesn't have a valid cc. (How can you have a VISA cc that visa doesn't know about? If its a valid cc, eventually we have to hit someone who knows it...)

For creation of the CC, its entirely done offline atm isn't it? And since its basically just a shared secret, you could do the whole diffie helman physically.. but anyways

So then on your side, as some kind of store, it should be the same as passwords. The payment processor tells you the hash function to use, and you use it client side, and the processor verifies.

Alternatively, you send the user to the someone else (ie redirect to paypal), who does the same thing.

It doesn't seem at all necessary to me that your cc/cvv actually leaves your machine in plaintext. Of course, they may be sending plaintext for some reason, but I don't see an obvious reason why they should