Ah, versioning is a pain! By all means, I agree, get 1.0 out the door and then it'll be a lot easier to think about these things.

I'm rather too busy at the moment to do a CC enhancement module myself, but it's not an unworkable idea. I just think it would duplicate effort, and would also increase the complication and difficulty of configuring Ubercart as a whole. Wouldn't it be easier to stick the patch into CVS after releasing 1.0 and just rely on testers? If it gets into CVS then I'll release my Protx module and we'll get a few guinea pigs... I mean beta-testers

Just a thought... looking ahead to 2.0... I would advocate a rethink of how cards are handled. At the moment, it seems necessary to do a regex to determine what card people are trying to pay with (because the select list is free text), and converting that to whatever code the merchant service requires; but if we're looking long-term, would it not be better to have each card as a kind of object (residing in a file, perhaps, like countries) that could have start date, validation type, etc., as required. Then, depending on which cards are enabled, suitable fields would appear as required. I am not convinced this abstraction layer is actually necessary, so it really is just a thought.

P.S. I think I may have spotted a bug in uc_payment_process() on line 907... it seems to turn all UIDs to 0. I don't know if this is intentional or not.