The system involves a pop-up window appearing during the online transaction process, requiring the cardholder to enter a pre-agreed password which their card issuing bank will be able to authenticate. The problem for the cardholder is determining if this pop-up window is really from "your bank", when it could be from a fraudulent website attempting to harvest the cardholder's details. Many of these pop-up windows lack access to the page's security certificate, eliminating a way to confirm the credentials of the window.
The "Verified by Visa" system has drawn some criticism,    since it is hard for users to differentiate between the legitimate Verified by Visa pop-up window or inline frame, and a fraudulent phishing site. This is because the pop-up window is served from a domain which is:
* Not the site where the user is shopping.
* Not the card issuing bank
* Not visa.com or mastercard.com
1. "web site does not have the bank or visa web site URL" Its a small matter : need make an A record entry to make the page officially have your bank URL. So if the bank url is http://abank.com they can ask their ACS (the people who do the auth) to make changes in the their web config and to their domain to add a record to point http://3ds.abank.com to the acs URL. Users should push their banks to do this -> its technically a no brainer.
2. Mobile: there are ways to find that the request is coming from a mobile device and in those cases the page needs to be rendered properly, or better use the one time access code based new India IVR VISA extension.
3. Yes all this added security can be broken too. But no one wants to pay for hard tokens or stronger authentication (auth) but in the future if enough users push for it and willing to pay for it then there are ways to make it more secure within the current framework. Especially if its card user controlled. Meaning a user should be able to choose which method of auth she/he wants to use.