"After eReader has created and stored the hash, it uses it as a key to decrypt the protected e-books (which are, to my knowledge, encrypted with the DES-X algorithm)."
If its a one-way hash, there is no "decryption" involved. You simply take the password/key/code that is entered, encode it with your known seed + hash, and compare it with the stored value. If it matches, access is granted. If it does not match, access is denied. This is how the standard Unix (and Linux) username:password login authentication is handled.
If there
is a key of some sort, which is used to encrypt and decrypt the book, and that is stored somewhere in the application or the book itself, then the whole process of encryption is irrelevant, and can be easily bypassed, using any one of dozens of different techniques to bypass the check for the proper code (witness the thousand of Palm applications that have been breached because they use this method of "securing" their application).
Regarding entering the credit-card-as-key every time, I think what was meant was that the value you enter the first time, has to be encoded, encrypted, or stored somewhere within the book metadata, so that it can be checked and verified every time you launch the reader to read the book. The mention that the credit card value is not stored anywhere is completely false, if this is how their application works.
If you have to enter the key every time you open the book, then it would appear that they aren't storing the key anywhere. If you don't have to enter the key every time, then it is stored, somewhere, in some format, which is queried and used to authorize reading of the book.