Yes I fully agree with you on the storing of encrypted or non encrypted
credit cards. I actually only stored them on the server for a half day at
max but that was when the site was live. I closed it down a few months ago
when I started a new career. I hated to do that since it was doing very
well. But its was mostly a test just to see if I could do it and now we are
getting ready to open the doors again with a whole new product line and more
sophisticated design. 

My servers are actually hosted here in DFW over at CI HOST. They are Co
Located with a firewall. I would like to think they are fairly secured.  

Well I think I will design into my backend, when someone places an order
that it will pre-authorize the card and store it as a pending order, then
once we ship the item we just marked it as shipped from the Admin and the
system automatically process it as a final sale and charge the card. 

Well thanks for all the advice. I really just wanted to chat about it before
I start to redesign the database structure and backend functions. I want to
make sure I do this right as maybe down the line I may want to sell the
Shopping cart itself. 

If anyone wants to take a sneak peek let me know I will post the link. Would
be curious to gets some feed back. 

Thanks, 

Neal Bailey
Internet Marketing Manager
E-mail: [EMAIL PROTECTED]
 
-----Original Message-----
From: Matthew Woodward [mailto:[EMAIL PROTECTED] 
Sent: Monday, March 08, 2004 2:49 PM
To: [EMAIL PROTECTED]
Subject: RE: Credit Cards - Best Practices

Well, any encryption is better than nothing, but you don't want to use 
something that's immediately crackable or recognizable either.  If you pick 
something unique for a seed for each user, you could use Encrypt() to do the

job.  (This is of course assuming that you have a real NEED to store credit 
card numbers and that you have an extremely secure environment already!)  
You might pick something like the user's email address backwards, for 
example, and then encrypt based on that.  That way it's a decently-long 
string used for encryption but something unique to each user and something 
that you can replicate for decryption.  I would still say that unless you 
really need to store CC numbers and have a very secure environment that's 
managed by a sysadmin who really knows his or her stuff, this is still a bad

idea.  Just had to put yet another disclaimer in there!  Encrypting this way

doesn't make things bulletproof, but at least if a hacker gets into your 
database they don't have plain text CC numbers staring them in the face.

Typically if you're shipping someone a product you won't actually charge 
their card until you ship the item, so you're correct, in those cases you 
would just want to do an authorization charge and not do the sale charge 
until you ship.  That's standard practice for sites with shippable 
merchandise.  I deal more with sites for which immediate charges are 
necessary, like subscriptions, online ad placements, etc., so in those cases

you would want to do a sales charge immediately.

Good luck with all this stuff--just make sure your server is EXCEPTIONALLY 
secure if you're going to be storing credit card information, even 
encrypted.  I have a horror story about this that I won't go into since it 
involves a former employer, so let's just say even with million-dollar-plus 
web sites and supposedly knowledgeable security experts, you have to be 
very, very, very careful.

Matt

-------------------------
Matthew P. Woodward
[EMAIL PROTECTED]
AIM: CaptainJavac
http://www.mattwoodward.com




----Original Message Follows----
From: "Bailey, Neal" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: Credit Cards - Best Practices
Date: Mon, 8 Mar 2004 14:31:48 -0600


Thanks Matt,

Preferably I would like to encrypt the CC numbers but I really don't know
how to go about this. Any suggestions? And can I de-crypt the number if
needed?

With the Card API that I'm using, it will also give immediate feedback on
the pre-authorizing same as a normal transaction. So live feedback I not
really an issue. I am just not sure which is better. We sale candles and I'm
not sure if it would be right to charge the customer's card if say we are
out of stock on something. Usually we process their cards when we ship the
merchandise. With that being said, I guess it may not matter as I'm thinking
about it, I usually get charged immediately for a magazine subscription even
though it can take a month or two to get the actual magazine.

Neal Bailey
Internet Marketing Manager
E-mail: [EMAIL PROTECTED]

-----Original Message-----
From: Matthew Woodward [mailto:[EMAIL PROTECTED]
Sent: Monday, March 08, 2004 11:34 AM
To: [EMAIL PROTECTED]
Subject: RE: Credit Cards - Best Practices

In general when I deal with credit cards I absolutely recommend that unless
someone is on a dedicated server in an extremely secure environment (their
own firewall, the whole works), they should never store credit card
information, even on a temporary basis.  You're opening yourself up to too
much liability otherwise IMO.  Even if you are in a secure environment, you
still likely want to somehow obfuscate or encrypt the CC numbers in the
database the second they get inserted.  If someone hacks in the CC numbers
shouldn't just be sitting there for the hacker to see.

In general for retail stuff I do the CC processing right when the buyer hits

the "buy" button, just because then they get immediate feedback if their CC
gets declined or if there's some other problem with the order.  I can
definitely see how if you were doing high-volume stuff the batch processing
might be the way to go though.  Just depends on the situation.  I typically
use Verisign Payflow Pro and haven't ever run into any issues with doing
one-off transactions, but I haven't done any huge volume e-commerce sites
either.

HTH,
Matt

-------------------------
Matthew P. Woodward
[EMAIL PROTECTED]



----Original Message Follows----
From: "Bailey, Neal" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Credit Cards - Best Practices
Date: Mon, 8 Mar 2004 11:11:47 -0600

Hello CFers...

I was wondering what are the best practices for credit card processing over
the web. Should you pre-authorize a customer's card during check out and
then run a batch transaction at the end of the day? Or should you run the
card as a final sale and gather the funds immediately.  Just as I have heard
people doing it both ways and I am in the process of converting my cart over
to an automatic Card processor API.

What are the pros and cons of both...

Also I have noticed that many shopping carts store their Credit card info in
the database. I have a little utility (MS Access) that transfers the
customer's info to my system at home and then deletes all credit card info.
This usually runs twice a day. Is there a better way to keep the card info
secure?

Thanks
Neal Bailey
Internet Marketing Manager
E-mail:  <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]

_________________________________________________________________
Create a Job Alert on MSN Careers and enter for a chance to win $1000!
http://msn.careerbuilder.com/promo/kaday.htm?siteid=CBMSN_1K&sc_extcmp=JS_JA
Sweep_MSNHotm2

-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
    Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
    Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org

_________________________________________________________________
Learn how to help protect your privacy and prevent fraud online at Tech 
Hacks & Scams. http://special.msn.com/msnbc/techsafety.armx

-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe: 
   Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe: 
   Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org

Reply via email to