Welcome to WebmasterWorld Guest from

Forum Moderators: buckworks

Message Too Old, No Replies

Storing credit cards or somthing better

7:00 pm on Aug 22, 2007 (gmt 0)

New User

10+ Year Member

joined:Nov 13, 2006
votes: 0

Alright, I am developing a new version of the auction site for a company. The thing is they need each user to sign up using there credit card in case they back out on an auction so they can get charged for it. My question is, should I store the credit cards are not.

Its fair to risky in IMHO but they need to get them some how or another.

I want to hear everyone else's ideas.

Keeping in mind that they are currently PCI compliant, the new version has to be PCI compliant.

2:57 pm on Aug 24, 2007 (gmt 0)

Preferred Member

10+ Year Member

joined:Jan 19, 2004
votes: 0

Since you are developing for a client you carry some liability. Read up on the Cardholder Information Security Program (CISP) [usa.visa.com].

More specifically, take a look at this file for CISP payment application best practices guide [usa.visa.com] (the link points to a .doc file). This document will outline what data can be stored, what cannot, and restrictions for both.

5:27 pm on Aug 27, 2007 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:June 2, 2003
votes: 0

You'll need to encrypt the credit card information if you decide to store it in order to be compliant.

I just had to do PCI compliance for a web application. The biggest issue I faced wasn't technological either. It was the users behavior.

This particular application was ecommerce order processing where all the users had access to multiple machines in an order processing facility under 1 single user account. Well, in walks PCI compliance which says that all users must have their own accounts and the system must log when anyone of these users looks at a credit card number.

This meant the users couldn't bounce around from machine to machine to work on something at any available workstation w/o always logging off and back on. They didn't like this 'at all' and it has to constantly be reinforced or they'll be subject to a PCI Audit failure which I believe comes with a fine.

3:39 pm on Sept 4, 2007 (gmt 0)

Junior Member

10+ Year Member

joined:Mar 22, 2004
votes: 0

I would use a third party system to store the cards for you. Some payment processors do this.You pre-authorise an amount to test the card works and can then charge it later, with the card holders permission of course! I think SECpay offers a service which does this. Another good one which I know offers this is Axiar Payments.
8:18 pm on Sept 4, 2007 (gmt 0)

New User

10+ Year Member

joined:Sept 4, 2007
posts: 1
votes: 0

The answer will vary depending on the industry.

If you DONT store the CC in your own database and it gets housed in the payment gateway, i.e VERISIGN then there are some issues involving this. Firstly, Verisign or similar gateways will return a reference transaction associated with the credit card. (number, exp, type, etc). Depending on the card issuing bank, there IS an expiration associated to this reference transaction. Meaning, if you need to charge the card again in 3 months and the most recent transaction on record for the customer ID is 3 months ago---you cant. I've experienced some card #'s lasting for up to 6 months, but since I have customers purchasing once a year. I HAD to store it in our own database, with proper encryption of course.

The other issue is, if you decide to go from storing the CCS elsewhere to your own servers--you MUST ask how much would it cost to attain the necessary CC infos from prior customers using the stored CC (in payment gateway). They DO charge you based on volume.

If your application requires an immediate charge to the card and would never have to reference it in the future. Then I would not store the CC's in your own database due to liability issues.

Hope this helps


Join The Conversation

Moderators and Top Contributors

Hot Threads This Week

Featured Threads

Free SEO Tools

Hire Expert Members