Opinion on my CreditCard exp. date function using select boxes.

[nelsonm]

hi all,

I just wanted to get your opinion on the method i used to create a credit card expiration date function to populate the Year select box. The Month select box is not an issue.

I know that making it function correctly until an end of time restricted by the data format that may last to the year 9999 is absurd. But, just for fun, I wanted to create the year select box options in such a way that it would not fail under any circumstance within the specified parameters:

1. The year select box would properly display past expiration date years retrieved from the database.

2. The base year determines the earliest expiration date year that can be stored in the database.

3. As the years progress, only that current year plus the next 11 years show up in the select list.

4. Only show the year abbreviation (only the 10's and 1's place) in the select list.

5. Store the exp. date as a 7 char table field with a format of "MM/YYYY". This format would allow the exp. date select function to work until year 9999.

In order accomplish this i constructed the year select options such that the option values start from a static base year (must be at least 1 year less than the year the web app went online) through the current year plus the next 11 year.

Here is my working code sample, what do you think?

function ExpDateSelectOptions(OP){
 var Selectoptions = '', ThisYear = currentDate('yyyy'), 
 BaseYear = 2011, MaxYears =
 (((ThisYear - BaseYear) + 12) + (BaseYear - 1)), i, k;

 switch(OP){
 case 'MM':
 Selectoptions ='<option value="00"></option>'+
 '<option value="01">01 - January </option>'+
 '<option value="02">02 - Febuary </option>'+
 '<option value="03">03 - March </option>'+
 '<option value="04">04 - April </option>'+
 '<option value="05">05 - May </option>'+
 '<option value="06">06 - June </option>'+
 '<option value="07">07 - July </option>'+
 '<option value="08">08 - August </option>'+
 '<option value="09">09 - September</option>'+
 '<option value="10">10 - October </option>'+
 '<option value="11">11 - November </option>'+
 '<option value="12">12 - December </option>'+
 '';
 break;

 case 'YY':
 Selectoptions = '<option value="0000"></option>';

 for(i=BaseYear; i <= MaxYears; i++){
 k = i.toString().slice(-2); // only show year abbreviation - YE[AR].

 if(i < ThisYear){
 Selectoptions += '<option disabled hidden value="'+i+'">'+k+'</option>';
 }else{
 Selectoptions += '<option value="'+i+'">'+k+'</option>';
 }
 }
 break;

 default:
 }

 return Selectoptions;
}


$('#workorder-form select#wp-ExpMM').empty().append(ExpDateSelectOptions('MM'));
$('#workorder-form select#wp-ExpYY').empty().append(ExpDateSelectOptions('YY'));

The code to set the correct expiration date retrieved from the database for the entry form expiration date month and year select fields as follows:

date = retrievedExpDate.split('/');

if((date[0] == '00') || (date[1] == '0000')){
 $('#workorder-form select#wp-ExpMM').val('00');
 $('#workorder-form select#wp-ExpYY').val('0000');
}else{
 $('#workorder-form select#wp-ExpMM').val(date[0]);
 $('#workorder-form select#wp-ExpYY').val(date[1]);
}

Thanks for your opinion.

[edited by: incrediBILL at 10:25 pm (utc) on Nov 10, 2012]
[edit reason] added line breaks [/edit]

[daveVk]

The Month options are static, better directly encoded in HTML.

While the Year options are not static I would put them in HTML as well.

This will avoid coding style decisions, such 2 vs 4 digit years, months as number + full English word, etc in JS.

If need be, you could remove static year options not in valid date range.

Not good to Year 9999 !

[nelsonm]

I appreciate and understand your concerns about styling but i was more interested in opinions about the method to insure that the year part of the exp. date select block would function correctly year after year.

I use the exp. date select block in multiple places on the site, so defining it in one place as a function and inserting the options into empty select tags where needed is better than having static multiple code copies duplicated throughout the site.

While the method constructs all the select year options from the base year through the current year plus 11 more years, only the current plus 11 years are visible and selectable in the drop down list. Past year options are disabled and hidden in the drop down list but still can be displayed when the values are given.

The method updates the visible 12 year range automatically year after year while still allowing past dates retrieved from the database to be displayed. The only thing the method won't do, is allow you to select one of those past years.

The method does work to year 9999. Try it yourself by setting "ThisYear = 9988".

I realize this is not earth shattering innovation, but i thought it was cool.

[daveVk]

It meets your requirements and works so that is good(cool?).

Not sure why BaseYear hard coded to 2011 ? Lesser of current year and date[1] may suffice.

I was not questioning if it would work to 9999 ? In fact it probable works past that the date.

[nelsonm]

The BaseYear has to be set to the year of the earliest exp. date entered into the database in order for previous year exp. dates to be displayed in the exp. date select block.

In any case, as you said... "It meets your requirements and works" so good for me!

thanks for your opinion.

[swa66]

(((ThisYear - BaseYear) + 12) + (BaseYear - 1))

is mathematically equivalent to

ThisYear + 11

What worries me a lot more is

while still allowing past dates retrieved from the database to be displayed

You do know that storing credit card details is not the right thing to do unless you adhere to the PCI regulations ?

[nelsonm]

swa66,

Yes, (ThisYear + 11) is mathematically equivalent to (((ThisYear - BaseYear) + 12) + (BaseYear - 1)). I didn't think of simplifying - thanks.

Ah... another fly in the ointment. I was not aware of the PCI regulations. I will read it and inform the client. Currently, the only thing that is being saved by the web app is the:
1. last for digits of the credit card number
2. the card holder name
3. expiration date.

The web app does not do any credit card payment processing, that is done through some third party merchant service the client has been using since before the web app was developed. The user just wants to manually enter and store the above credit card info into the web app database for future reference.

I'm reading the PCI docs but I haven't found what regulations, restrictions or procedures that the web app or database has to follow yet regarding this issue. Do you know where they are?

Thanks again.

[swa66]

To avoid too much detail:

Your CC processor will most likely be PCI "certified" on some level, but in the agreement he'll transfer some of his requirements to your customer.

So the first place to look is the agreement/the conditions of the CC processor and the obligations you incur that way - that's unless your customer has an agreement with the CC companies - then these come into play as well.

Storing things from a CC: completely avoid it if you can. if they pass on the least bit of the PCI rules, you'll end up needing hardened systems, cryptographic protections, regular audits, separation of duties, etc. And a lot of liability too if anything ever goes wrong.

[nelsonm]

ok, let me see if i got this right.

Your saying that whatever merchant services my client is currently using, that service will tranfer or require my client to follow some restrictions and/or requirements of the PCI rules.

So if the client wants to maintain any part of the their customer's credit card info outside of their current merchant processing method; whether on paper, chalk board or in a sql database, the client will have to comply with applicable PCI rules - correct?

I noticed that my commerical Quickbooks Pro accounting app allows me to store the credit card name, number and exp. date of my customers on my office computer and I'm certainly not going to harden or encrypt my pc.

[swa66]

To try to set you on the right track:

See page 6 of [pcisecuritystandards.org...]

The primary account number is the defining factor in the applicability of PCI DSS requirements. PCI DSS requirements are applicable if a primary account number (PAN) is stored, processed, or transmitted. If PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.

You are transmitting the PAN (credit card number), even storing part of it. So the PCI DSS applies.

Now the PCI DSS standard applies to banks, credit card processors, and merchants (and probably a few more). So you see a lot in there that you can get around and make it easy on yourself by not storing it (or part of it).

In fact in PCI documents you see often the phrase: "Cardholder data—if you don’t need it, don’t store it!". Don't shoot yourself in the foot by trying to store things you do not absolutely have to store.
[Moreover PCI DSS requires you to have good reasons and prohibits storing certain data at all]

Secondly it's important to minimize the scope. You can do this by isolating what machines you use to transmit credit card data or are related to it. Now it's not an easy exercise to isolate it, but you should do your very best to get it as if you don't you end up with all IT equipement being subject to strict rules (wich drives up the cost of IT by a serious factor).

Personally: I'd go for a solution where the customer interacts with the processor and I just point them in the right direction, and get a "success + tracking number" back from the processor. That way I neither transmit, process nor store anything and I'm not subject to PCI DSS.

If you have to do things, remember the minimal approach, and you probably can do a self-assessment to claim to be in compliance -do not lie, there are consequences- , but process enough and you'll get an auditor that's going to scrutinise it all.

[nelsonm]

Ok, thanks. I will inform the client.

[daveVk]

The BaseYear has to be set to the year of the earliest exp. date entered into the database in order for previous year exp. dates to be displayed in the exp. date select block

The earliest exp. date entered into the database should not matter, you are dealing with one person, if his year is 2011 start at 2011, if it is greater than current year (say 9000) start at 9000.