Unfortunately, credit card security for traditional online payment rely on payment processor actively blocking bruteforce attempts and CVC number never being stored to stay secure.
Masking six digits out of sixteen digits is a very common practice in the industry. The first 6 is BIN which is sort-of public data (full BIN table are distributed by Visa/Master only to acquirer/issuer, but some acquirer may provide them for free to a payment processor/merchant), next 6 is not unique enough since it depends on issuer's scheme so last 4 is used for identifying a card with the middle 6 masked.
I don't know about this particular case (and it depends on QSA), but if the number is in any way reversible e.g. a plain hash(card_number), it would put any system that store that hash in a PCI-DSS storage scope. I once worked with a system that solve this issue by having unique salt to each card, but the salt is never exposed outside of PCI-DSS scope. This prevent rainbow table attack, but still open to brute force.
3-D Secure was suppose provide a better security for online transactions by requiring a second factor (e.g. OTP), but it introduces a lot of hassle since it rely on HTTP POST from a client's browser (thus the "Your payment is being processed. Please do not refresh this page." screen), add two extra vendors to trust (ACS/MPI), and the card is still usable with merchants that doesn't enforce 3-D Secure (though I'm not sure if this is the case with India), making the whole scheme similar to having a tightly locked door with a window open wide. The scheme protects merchant more due to liability shift which removes them from being liable to chargebacks.
3-D Secure 2.0 tries to fix the hassle part by requiring merchant and payment processor to send data about the transaction back to the bank (email address, previous transaction info, shipping address, etc. which may be a privacy issue) and letting them decide whether a transaction should require an extra authentication.