All 0s (zeros) in a bank card's CVC code
Alexander O'Mara provided a correct answer, but having worked in a hotel that was using booking.com I believe I can provide additional information about the reason that CVV was denied.
Every day the hotel I worked in would receive around 50 bookings, a quarter of these bookings would be using fake credit card details, and about 90% of people using fake credit card details would not show up.
This resulted in a lot of guesswork when assigning rooms, we would often try to guess if the person will show up just based on their credit card details, and also sometimes take into consideration the name, location, how many days they will be staying, etc. We would also try to call the day before to confirm bookings, so that these fake bookings result in a minimal interruption to the business.
Blocking CVV 000 is just booking.com's lazy attempt to reduce the amount of fake bookings. Some other CVVs are blocked as well.
The reason why booking.com blocks the CVV and other websites do not is because other websites generally attempt to charge the credit card immediately, while booking.com only forwards information to the hotels which charge the credit card on the day of arrival.
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.