Wrong way round IMHO. Decide how you are storing the data (surrogate or natural key) and then build the app to suit that. Personally, I would use natural keys and cache this (likely unchanging) data at the client. Not bother with enums at all.
There is no such thing as a lookup table. Treat this data no different than any other data in your database. If your standard is to use natural keys, then use natural keys. If your standard is to use surrogate keys, then create a surrogate key for these values.
And if you not referring to surrogate keys, but actually mean true .net "enums", well the whole practice of dynamically creating surrogate database keys in the applicaiton layer is so lame that I don't really want to get into it.
If it's not practically useful, then it's practically useless.
what happens if there are additional types eg debit card
in my books it has to be a table, ENUMS are fine for the very limited occasion where every possible value in perpetuity is known at design time, but even then they can still fail if you say move the db to another language. the often quoted example are Male / Female using M or F as the Key. but that can fall down in these modern times with a move to non English, or the addition of other categories eg Trannies
I'd go along with the idea of not alwasy using surrogate values for the key, it can make the data a heck of a lot easier to read.