in reply to Credit Card Billing

I run a site that does monthly credit card re-billing and our solution was to store a "last-billed" UNIX timestamp in the database, and then query the database for users that have a "last billed" date on a certain day of the month. (That is, if it's the 10th of the month, look for last billed dates that are the 10th of the last month.) This system works great except for people who originally subscribe on the 29th, 30th, or 31st of the month... to take care of them we just bill all those people on the 28th. Easy peasey. Missed transactions (or failed transactions) are easy to track because we always know the last date a successful billing occurred. No need to set a separate flag.

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

Replies are listed 'Best First'.
Re: Re: Credit Card Billing
by Anonymous Monk on Jan 05, 2002 at 21:08 UTC
    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
[reply]
      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.

[reply]
        I like the idea of single serial cable with only write access (no read) to the CC Processor and that the CC Processor is not on the network.

        Also some care should probably be taken that any variables used to store the CC info en route from CGI app to CC Processor should be nullified after the CC info has been passed along. If someone breaks into your webserver and gets root they could dump memory to core and possibly pick up CC numbers that way. Something to think about.

        metadoktor

        "The doktor is in."

[reply]

In Section Seekers of Perl Wisdom