I suspect a proper fix may need a little more than that, but at the very least a number of things have to be checked and tested before a patch like this is committed to core. This can potentially affect the code in many places. Does Maestro use the same checksum as "normal" 16-digit card numbers? Is there a unique first digit that would allow a program to identify a number as a Maestro 18-digit number? Does the form validation check on the length of the number or the maximum digits (if so, you're breaking validation for all other types of cards...) Does the encryption/decryption work properly when more digits are supplied? Are the DB table columns big enough to hold 18 digit numbers - in *all* modules where this data is used? What about the display of the "last 4" numbers - does it work properly when there are extra digits? Is the CVV handled the same way for these new 18-digit numbers?

This patch may be all that's needed, but it would be nice to have all the payment code examined carefully to make sure it doesn't break something - especially if you want to get this fix into 1.0. I'm far more concerned about breaking things at this late stage in the 1.0 release process than I am about adding features/capabilities.

Maestro (debit card)
Prefixes: 5020, 5038, 6304, 6759
Digits: 16 or 18
Validation: Luhn algorithm

This is really all I know. I don't have time to go into this issue, maybe some others have some background on this and can get it done quicker.

We've been running this modification since I posted the patch and we have not had any errors or other symptoms caused in this time. Is there any chance that this will ever make it into Ubercart or are we going to be forever maintaining this core hack?

I've just realised/remembered that I can just copy the credit card module to create a new one, therefore negating the need to maintain the hack.

No need to maintain it forever... this issue is still in my "review" queue, but the CC security stuff took up most of my coding time last week. You can always do this with a hook_form_alter() in a custom module and not have to hack anything at all.

Just to verify, though... do 18 digit card numbers still validate properly when you have that setting turned on?

Hi Ryan, great to hear you've got this on your radar. I always seem to forgot about hook_form_alter(), doh!

As for your question, yes, it does still work with validation turned on:

That Maestro number is a dummy that I found:

http://apps.cybersource.com/library/documentation/dev_guides/CC_Svcs_IG/...

Not wanting to hijack this thread for more than the original issue, we also require issue number and start date for our credit card processor. I would have thought that others will need this too.

http://www.ubercart.org/issue/4766/credit_card_start_date_and_issue_numb...

So... based on that documentation page, I don't see why we shouldn't up the maxlength to 19. Can you shed some light on this?

Actually... let's just centralize all discussion through your other issue:

http://www.ubercart.org/issue/4766/credit_card_start_date_and_issue_numb...