I've been a user of debit cards for many years, and don't know much about the security issues. However, just thinking logically, I find the practice of paying by providing card data (i.e. card number, validity date, CVV code, cardholder name) inherently broken from a security point of view. I want to understand if my reasoning is right, and if so, why the system was designed like this. Or, if I'm wrong, what is the problem with my reasoning.
In some online services/offline businesses, it is possible to pay by providing debit (credit) card data directly to the vendor (card number, validity date, CVV code, cardholder name). (And I think also off-line, by writing it on a paper, or by dictating it via phone.) Then, the vendor will charge the account using this data. (I imagine, that basically, he passes this data, together with the sum to be charged, to a card company, like Visa or Master, which check that they are valid and then instructs the bank about the amount to charge.)
I see (at least) two problems with this process:
- Nothing guarantees me, that the vendor will really charge the agreed sum and not more.
- Nothing guarantees me, that the vendor (who now knows the necessary data), won't charge my card again.
- (Let's forget for now about the issues like leaking card data, etc.)
If I want to compare it to a cash payment, the process seems to me like this:
I give my whole wallet to the vendor.
I go out of the room.
The vendor takes out from my wallet what he thinks is right.
I go back, get my wallet back, and only count the remaining money once I'm at home, not in front of the vendor. (If there was an issue, I can go back to complain later, but meanwhile, the vendor already has my money.)
From now on, the vendor has unlimited access to my wallet, and he can withdraw money whenever he feels like it.
What I would see as a secure enough solution: whenever someone tries to charge my card, I get a one time token sent to me (e.g. via SMS). In order for the transaction to be successful, I have to provide this token too. This solution seems so simple, and yet it could prevent (or at least make harder) most of the card frauds. The process would look like this: I get an SMS with a token. Am I paying for the service written in the SMS? Yes --> I give the token to my bank, to confirm the transaction. No --> I report the fraud attempt to the bank.
- I know there is the possibility of a chargeback if the withdrawal was fraudulent. But why not prevent the possibility of fraud altogether as written above?
- Also, I know you can set limits for the transactions, still it does not eliminate the risk to lose at least some money.
- I'm also aware, you can have e.g. virtual cards for paying on the web. You can keep the corresponding account always empty, and only put money on it when you want to buy something with that card. There is still a very small chance, though, that someone will steal your money in the small time window that you've put it on your card but not yet spent it. (And in all cases, this is rather a workaround, not a fix for the root issue.)
- Putting additional security codes (e.g. CVV) on the card does not help much in this aspect (the vendor will get it, and can reuse it if he wishes).
- This question, although related, is not a duplicate in my opinion. The reason is, that the question suggests another solution (middle-man), and as far as I understand the answer, it boils down to rules/laws stating that vendors should not store credit card data. (But my problem is: why does the vendor have to receive data that he can reuse at any time if he wishes?)
- Also from the above Q&A, I read that there are laws which prohibit that the vendor stores (and reuses) card data. But this seems very weak. This would be like saying that there are laws that prohibit that the vendor takes more money from my wallet than he is due, while I'm not watching...
- There are some (in my opinion really dubious/unethical) practices from some hotels/car rentals etc. of pre-authorizing the agreed price and then, in the end, charging once again the price. (The pre-authorized transaction will be cleared eventually, but meanwhile, the user of the card does not have access to his money maybe for weeks.) This could also be easily prevented, by my one-time token suggestion (I would simply decline the second transaction).
(The more of these you can address explicitly in your answer, the better.)
Is my understanding correct, that security of this payment method is broken? And is it broken in the way I think it is broken?
If yes, then what was the reasoning for designing cards in this way?
If not, then where is my reasoning wrong? (In particular, what is the difference between paying with my card by giving out all its data (cardholder name, card number, validity date, CVV), and giving my wallet to someone, so that he can take out the money himself, while I'm not watching? The only difference I can think of, is that the transaction with the card is at least logged somewhere.)
Is there a well-known name for the issue I'm asking? (Of course, I tried to use Google before coming here, to search about credit card security, but I only got very particular results like issues with the security of the chip, and none of them addresses this issue within the model.)
Why don't banks use the (seemingly trivial) method of the one-time token generated for the bank I proposed above? This works so well for money transfers (at least in my bank, I always get a unique number via SMS with which I have to confirm transfers). And why doesn't the answer to this question also apply to money transfers then? (In other words, why do then banks use one time tokens for money transfers? Why don't they just let any money transfer transaction succeed by default, with the possibility of claiming the money back, if the transaction turns out to be fraudulent?)