Argthtjtr

The only weak argument I can think of to reject such a CVV would be that if someone were trying to brute-force your 3-digit code, they might start with 000 first (but would they also reject 001?).

From practical point of view, how reasonable it is to decline "000" as insecure?

It's not really reasonable. Either you can charge the card with the provided CVC/CVV code or you can't. There's no good reason to reject this code, since it is valid, and you can't really be sure if a credit card's codes are valid until you actually try to charge it.

Sadly, poorly-designed input validation is all too common. Some developers have a tendency to just assume certain values are invalid without checking the spec, or not properly unit test their input validations.

Some examples include:

• IP address 1.1.1.1
  


• Version checking bugs like "10" < "9" if only the first character in the string is checking


• Names with non-alpha character (like the apostrophe in my name)

It's also not uncommon that people in customer service will respond to your bug reports with something along the lines of "that's not a bug, it's a feature" without ever even consulting the developers.

This is a frame challenge of the company's claims. A random number in the range 000-999 is more secure than 001-998, rejecting values weakens it.

It's a software bug. They can't admit it.

Just one example: say, somewhere in the stack, they use a language with untyped variables (i.e. Where the same variable can hold 123.45, "late for dinner", a 0-character string, an "undefined" token, etc). It's commonplace to write this:

if ($CVC) # is CVC field present?

In an untyped language, a blank string evaluates to 0 (false) as the programmer intended, but so does 000! There are better ways to do that.

In this case, we know the problem is not in the public-facing web UI you use, but in the back-end platform that both of you share. The agent should open a bug on it in the ticketing system.

So why did they claim what they said? Because normal businesses are very reluctant to admit this kind of structural error that makes them look incompetent. But they also cannot send you off with an "I don't know", as that has the same effect. So they need to say something to you right now that feels sellable to them.

Obviously it is wrong; as proven by all the other people you do business with who have no problem with it. But try it yourself; try a competing booking platform and see how it goes.

I currently have a credit card that arguably has a worse CVV number: 123

So far it has never been denied, but from a security point of view I don't like it as I feel like it could very well be the first thing a thief would type in if somehow they had my numbers but not my card.

From the website's point of view, IMHO it's asinine to purposely treat a valid number as invalid. (Even more so if the chances of it occurring are merely 1 in 1000.) Since it would be extremely easy for the site to attempt a very small authorization to confirm the credit card, or even let the hotel decide for themselves, I don't agree with the "preventing fake numbers" argument. That being said, a quick search yields quite a few people with the same issue on various websites over the years. So, you're not alone. :)

In fairness, there are tens of thousands of hotel booking systems that booking.com have to pass information on to for them to process. I trust that booking.com can afford a developer who knows that (000) == FALSE in JavaScript... but is it worth their support time trying to diagnose the exact same bug for the hundreds of hotels who probably have this bug in their booking systems? Absolutely not.

My guess is that this is actually a rather reasonable attempt to mitigate data processing errors that happen further down the chain, and in systems that are out of booking.com's control.

As a card-processing merchant, they are obliged to process valid cards, so are probably breaking merchant rules here and could get in trouble with VISA (or whoever)... but i can almost see the logic.

I have some problems with the simple "stupid bug" theory here. I have no doubt that the person you were talking to was pulling this nonsense out of thin air (as some customer services people are wont to do). 000 is perfectly valid and you're no the first person on the internet to point out having the number.

But there's a scale here that people aren't appreciating.

• The natural possibility of getting 000 as your CVV is 0.1%


• Booking.com is a business that generated $8 billion in raw 2017 revenue, most on card transactions. That's about a fifty thousand medium bookings a day.


• Booking.com must therefore encounter 000 50 times a day. To a tune of $25k lost to Booking.com and, much, much more in terms of actual bookings not passed on.

Rejecting 0.1% of card transactions is $9m in lost revenue. In the [very much smaller] businesses I work for, booking flow analytics would flag this up the chain pretty quickly. These sorts of companies (I tangentially work in holiday booking systems), the cart experience is the most tracked part... I'm finding it very hard to believe that a company that relies on analytics would miss something as simple as a card validation issue.

So if we assume that this cannot exist at that scale, we have to offer some suggestions that limit the scope...

1. 
   

   This is a local bug.

   
   
   

   Many multinationals put money through local accounts and bounce it around from there for tax purposes. It may be that Booking.com allows its local offices to edit the code on this to handle local quirks (currency, whole payment schemes that aren't global) and in doing so, allowing bugs to creep in that don't exist elsewhere.

   
   
   

   The possibility of this is increased because the target country is Croatia. They use the Kuna there, not the Euro. There may well be a raft of accounting differences and mechanism providers.

   
   
   

   That also goes some distance to explain why this has gone under the radar. 0.1% of Croatia-bound money is going to be a hell of a lot less than the global income.

   
   


2. 
   

   000 isn't as common as 0.1%

   
   
   

   As JPhi1618 points out in the comments, the other scope-limiting factor is that perhaps banks don't issue 000 very often. There's no reason they shouldn't and as I've said, there is evidence online of other people with 000 cards, but that is not to say it is common.

   
   
   

   I have no way to verify this. Perhaps somebody with a card processing log that includes CVVs can run an analysis.

   
   

Still, if you find issues like this, report them. Skip the customer services team because they simply don't know what's going on. Go to the CEO, or security team as they're both going to take this pretty seriously for slightly different reasons. $9m in lost revenue is a good motivator.

Note that on some Credit Card software, a CVC with the magic value 000 means that a CVC was provided but has been deleted since (due to PCI constraints). That's probably what Booking is doing, and that explains why they don't accept it.

Tough luck :/