I suppose I don't need to remind you that if you're going to be storing credit card numbers for God's sake don't store them anywhere within your web server's file tree... yes, I know you're encrypting them but it's always good practice to make it as hard as possible to even get to the cc numbers in the first place.

Gary Blackburn
Trained Killer

Hi All,

thanks so much for the responses

The way I was thinking was to store the cc numbers in an sql database.

If the encrypt/decrypt key was stored in the perl script, and then the script were to be compiled using perlcc or such, would that be secure? Or would it still be the best option to just enter the encrypt key manually whenever i deal with the cc numbers, i know that method would be very secure

Thanks

Obfuscating the key using perlcc is not the answer. The only setup I have seen that seems remotely comforting is a multi-tier design where the box that has the keys is running no services, and can only be passed transactions. (i.e, it can't be queried).

Something like:

Internet =====> Firewall ===> 
        DMZ Web Server ==> Firewall ==> 
               Seriously Locked Down CC Processer 

The 'CC Processer' box should be running no services at all, and listening on only one socket. This socket should accept inbound transactions and return an ack/nack, and nothing else. This would mean that administration, key changes, logging in, etc, would have to be done at the console. The web server should only have CC number while they are in transit, and should never write them to disk.

The folks at VISA have a pretty decent summary of what should be done to protect machines with CC data. ( It's a bit lacking on implementation details, but still good.) See: The VISA CISP Tech Info page.

I use Class::Date for date comparisons. It facilitate comparisons with past, present and future dates.

use Class::Date qw/ date localdate now /;



# date that the billing period starts  (get data from db)
my $period_start = date('2001-12-31');


# date to start attempting charges  (get data from db)
my $charge_date = date('2001-12-27');


my $today = date( localdate( now ))->truncate; # truncate makes time m
+idnight



# it's late

if (  $charge_date < $today ){

    print "Charge date passed. Transaction previously failed.  Try aga
+in.\n";

}


# not yet due

elsif ( $charge_date > $today ) {

    print 'Charge to be processed in ',
          +( $charge_date - Class::Date->new( $today ) )->day,
          ' days.';

}


# charge today

else {

    print 'Today is charge date.  If successful, next charge date will
+ be: ',
          date( $charge_date + '1M'); # one month

    # change next charge date in BillSchedule table.

}
[download]

An alternative is to use Date::Calc, which was discussed recently here. Depending on how many comparisions you'll be doing, Date::Calc may be the best choice because it's much faster.

I have come up with a similar solution previously, initially making use of some hand-rolled calculation routines which I have since replaced using Date::Calc.

The setting in which these calculations are used is a billing system where the billing for each customer is determined by their plan id (which in turn relates to billing information in another database table) and the activation date of their account. The following is an edited snippet of the transaction calculation code:

#   return customer id, plan id and activation date for activated acco
+unts and customers

my $acc = $dbh->prepare(qq/
    select  accounts.customerid, accounts.planid, accounts.activationd
+ate
    from    accounts, customers
    where
            accounts.customerid = customers.id
        and accounts.terminationdate = NULL
        and customers.activated = 'Y'
/);
$acc->execute;

while (my $res = $acc->fetchrow_hashref) {

    #   Information regarding billing fees for each plan is stored in 
+@plans where the array index correlates to the billing id

    my $plan = $plans[ $res->{'planid'} ];

    #   $delta is the number of days since account activation - note t
+hat @date holds todays date

    my $delta = Delta_Days((split '-', $res->{'activationdate'}), @dat
+e);
    if ($delta == 0) {
        if ($plan->{'setup'}) {

            #   account was opened today - charge set up fee if necess
+ary

        }
    } else {

        #   Alternatively, if the plan has a regular billing period, c
+alculated as number of billing periods per annum, calculate whether t
+he client should be billed today

        if ($plan->{'fee'} && $plan->{'period'}) {
            my $calc = $delta / int (Days_in_Year((@date)[0..1]) / $pl
+an->{'period'});
            if ($calc == int($calc)) {

                #   Client should be billed $plan->{'fee'} amount

            }
        }
    }
}
$acc->finish;
[download]

The details of billing plans is stored in @plans and includes an unique plan id, plan setup fee (if applicable), the number of billing periods per annum and the fee per billing period. The use of number of billing periods per annum was selected as a measure for billing as it allowed the maximum in flexibility with regard to future plans - There is no fixed limitation with regard to all plans having to monthly or annual or alike. The number of billing periods per annum is converted to day period by the int (Days_in_Year((@date)[0..1]) / $plan->{'period'}) which in turn allows the date of billing to be calculated if the modulus of days since the account activation to day of transaction run ($delta) is zero.

 

perl -e 's&&rob@cowsnet.com.au&&&split/[@.]/&&s&.com.&_&&&print'

I realize that is not a Perl answer but I am not sure your post is a Perl questions as much as it is an algorithm question. That is is fine, but I wanted to be clear on that.

My only other thought on it is to use Class::Date for handling the date calculation, storage, and calculation. I like the OO interface that it uses.

I did something like this recently, and would be happy to rehash that with you directly. Feel free to email me outside PM is you want to bounce some ideas around.

So, you have setup a new field with the next-billing-date and you're afraid that if the program is not run that day then the transaction will be missed? How about adding a billed flag? When you establish the next-billing-date also make sure to set the billed flag to 0. That way when your program runs even if it runs after that billing date you will still bill the account because the flag has not been set. This is a simple solution but you can probably fit it to your needs with additional modifications depending upon your constraints.

metadoktor

"The doktor is in."

Not necessarily the case - some of the payment processors will handle scheduled re-billing for you. I know that WorldDirect will do this, although in this case they require the user to set up a username/password.

If monks know of other payment processors who offer automatic rebilling, could they tell me (in this thread or by /msg) - it would be handy to know.

Cheers,
andy.