Looking at how credit cards are used in everyday life, it's amazing that such an inherently insecure system survived as it is violating almost every rule there is in terms of security. Even though it provides all three security relevant details (the number, expiry date and CCV code) on the same physical plastic card – and that in human-readable form –, you hand it over to the waiter in the restaurant, hoping he or she will not copy the data down whilst processing your bill.
Oh, and you might as well sign the receipt with "Mickey Mouse" rather than your real name, as nobody bothers checking your signature anyway. Technically the transaction has already been processed, and the signature merely gets checked – if at all – in case of a dispute.
It seems that the credit card companies realized that this is becoming expensive for them. Sick of covering up the fraud and reimbursing customers, they have started to fight back: When used online, instead of only entering the already known three components, one now has to provide a fourth – at least sometimes.
Because depending on the bank, card issuer and credit card company the mechanism for this component varies. Some want to have an answer to the previously chosen question; others require the use of random reader generated code. To make it a bigger mess, the requirement to actually use this more secure system depends on the country of origin of the card in use, local laws, and on the online shop you try to pay at. Because the shop owner may also decide whether or not to require this additional security layer.
Of course this won't work at in an old school classical retail store or restaurant. Did somebody just say PIN code? Do you have any idea how that would screw up the processes in (busy) restaurants, where credit cards magically disappear from the table just too magically return with the printed receipt, waiting to be signed? Or do you actually sign on those digital pads at the register?
Long story short, it seems that tightening the security on the user side is not really an option if you don't want to cut down on ease of use. And the ease of use seems to be a vital factor – otherwise there would be no logical reason to push contact free payment methods that do not even require a signature or PIN. So instead of adding security measures and even enforcing them, the credit card companies had to come up with a means to decide whether or not to accept a transaction before authorizing payment.
Looking at it, the credit card companies have the same type of problem as every online shop. Depending on the trustworthiness or track history of the customer, different forms of payment may be available – or not. Prepaid, credit, an invoice based payment, or even instalments. Each method comes with pros and cons: While a prepaid transaction is most secure for the shop owner it is also pretty much the slowest form of payment, causing huge delays in getting the ordered goods out to the client. A post paid payment on the other hand comes with the risk of not getting paid at all.
So what to offer? And to whom? A returning customer with a standing history of successful transactions is more likely to be allowed to pay after receiving the goods than a new customer. Sounds logical? True, but why? Every customer was a good customer – before things went downhill. To reduce their own risks, many a shop owners push the burden of deciding about which type of transaction to use to a payment provider. And what do they do? They usually perform various logical checks of the data provided as well as additional background checks. The logical part starts with a simple question: Does the credit card number given make sense? As random as the digits may seem, they include checksums and other information that make it easy to tell if the numbers are made up or could actually exist. But of course by merely looking at them, nobody can tell whether or not they refer to an active card, and if it actually belongs to the person claiming it. Another important Task is to find out if new transactions can be run against it? The only way to do that is to actually run a transaction, which – at least for a credit card – is pretty easy: A simple lock request will allocate, but not yet subtract, funds on the card – but only if all the passed details match. In case this is merely done to verify the card, using a large amount of money for this is likely to make the customers unhappy. As a result, many websites try to allocate very small amounts, like 1 cent only.
While 1 cent may seem like nothing much, it still is an allocation of funds. So to be nice to their potential customers some shops and their payment providers must have been thinking: How about we run a transaction allocating 0 cent? What sounds like a brilliant idea at first, can easily backfire: My credit card company, for instance, blocks empty transactions to prevent the potential abuse of their service for the very reason these checks are made and to not have to process – from their perspective – pointless transactions. Hence, as part of their fraud detection they don't allow 0 cent transactions, declining the (verification) request.
What makes perfect sense in their context – who would want to pay for empty transactions? – gets interpreted as an invalid card by the shop, prohibiting the use of these cards, even though they are perfectly valid and active.
So if you have to implement it on your systems, you should think at least twice on how to translate the business requirement into rules, and those rules into actual code. This process can be as hard as figuring out the correct ruleset as external services and partners may have their own rules and fraud detections in place. The last thing you possibly would want is two fraud detection systems fighting each other – the user will always be at the loosing end.