For a hash to be collision free, each unique input would need to map to a unique output. If each output is unique, that means it can be reverse-mapped to a unique input. That would not be hashing, that would just be an encoding. Collision-free and non-reversibility are mutually exclusive by definition.
The important point is how likely a collision is, and the answer for modern hashes is negligibly unlikely. If the output key space is larger than the input key space, you're extremely unlikely to ever find a collision, and even if it's not it's still so unlikely as to not be worth considering in the real world.
I would guess though that those smart card ids aren't very complex, likely decimal numbers all of the same length (e.g. 1234567890). That means there aren't that many possible inputs and it's probably possible to calculate the hashes of all possible ids in a feasible amount of time, creating a lookup table to reverse the hashes. If that's the case, you'll want to be using a slow hash like bcrypt, scrypt, PBKDF2 etc. to make this infeasible.
The more I think about it the less the requirement makes sense. The secret here should be between the card and the reader, and the trust needs to be between the reader and the system it's connected to. Why is it a security problem if the id of a card is known? What can somebody do with this id if he obtains it? If the answer is that the id is a secret and somebody can do whatever he wants if he knows the id number, that's poor security. The security here should come from the fact that one needs to have physical possession of the card, which means the secrets are all between the card and the reader. Beyond that there's only an authenticated user with an id, which is a simple necessity to make the system work.