Implementing Luhn's algorithm to validate a credit card number in Java
Ordering

The ordering is a bit mixed. Try to an ordering such as: variables, constructor, public methods, private methods. There's no real convention for that, but try to tell the reader the story about your class. As for instance the member vars are the protagonists, the Constructor is the entry of a book, and the methods are the chapters.

Probable bugs


Even and odd sum are never assigned


simplify


In validateCompany, you can assign the char once and use a switch-statement.
In validateLength: String has a length() method.
In isDivisibleBy10: You call getEvenSum and getOddSum, add both values up, even though you have a getSum method.


concerns


The validateCompany method assigns the company. On one hand, the developer who uses your api would never figure that out. Also, you have to call validate, otherwise you wouldn't get the company
The constructor gets a credit card number passed. At the same time it reads from the console. And then ignores the input and assignes "0;" to the local variable. Only pass the number, that should be enough, the type shouldn't care about how the number is loaded.
getCcNumber: This method too should not read from the console. It should return the value which was passed to the constructor.


public methods

The only method you call in your tester class (which should start with a capitalized T), only calls the isValid() method. Reduce the visibility of all other methods. Depending on how the type is used, the user of the API will see too many methods, he only needs one. And beside that: It's a common principle to hide as much implementation as you can, also known as 'information hiding'

Hope this helps,
slowy