|
|
|
|
|
by cm2187
4063 days ago
|
|
We should have moved a long time ago to vendor specific credit card numbers (ecommerce isn't exactly a new activity). Say I get from my bank a token which I provide to this vendor, and the first time the vendor uses it to accept a payment, the token locks in to that vendor, i.e. my bank will not allow any payment with this token to another vendor (i.e. to another bank account). Then it doesn't matter if it's stolen, only that vendor can use it anyway. And I could have the option to tell my bank to make it a single use token, or to cancel a multiple use token or to set a payment cap to that token. That doesn't seem very complex to implement and would alleviate the vast majority of the credit card related problems. I am sure it can be made simpler, have a protocol with redirects to the bank's website that eliminate the need for the client to copy-paste a token, or to have another mechanism with similar effects. Banks are one of these many industries that don't seem to get technology. They employ massive IT and developer staff but are run by people who don't get it (and to make things worse, are most of the time massive bureaucracies which means that even when they know what they need to do they just can't execute). |
|
The big problem arises when you booked your hotel on one of these temporary numbers and show up to try to check in to the hotel. The card was not actually issued and some hotels have weird policies in that regard.
Of course, chip card based solutions that devalue the PAN are superior.