Hi All

I've finally managed to track down this site when the mailing lists dried up.

Basically I have created my shopping cart site from scratch using ASP and a MySQL DB and have finished the SSL side so that customer accounts and orders are all done on the SSL side of the site. At this present time, my idea was that the client enters their credit card details on the SSL side and these details are submitted into the DB, the merchant goes to a secret admin page on the SSL, finds the order, prints it out and then clicks a button to obliterate the credit card details out of the order, sort of a 4568 xxxx xxxxx type of thing.

Having got all of this ready I've now heard on the grapevine that this might not be acceptable and that I would have to do this through a PSP - is this true? Is my method not acceptable? Is this just a money making racket so that the PSPs have a monopoly on this sort of thing?

Feedback from you ASP Ecom gurus would be really appreciated.

Rgds

Laphan

Laphan -

I have a large amount of experience on e-commerce.

The big problem here is only your procedural methods in the architecture of your website. At least that is what it sounds like.

It is true that you are not supposed to store credit card info in a database. I am sure you can get in big trouble doing that if found out or leaked out.

If you are taking a credit card the object for most e-commerce sites is to process it because the shopper/customer has selected the items they wanted to purchase are aready to checkout/buy.

So you need to have the individual entere their card when they are ready to checkout, then submit the card information through your gateway processor and process the returned response from the credit card processor has being a good purchase or bad purchase.

Unless you are trying to do something slippery like auto-subscription renewal for your site's service or something like that there is no need to maintain a credit card number in a db not event for a short period of time.

If you just want them to print a receipt with a credit card number in a format like 4111 XXXX XXXX XXXX then simply capture the credit card variable and hold the first four digits of the credit card in a variable like this:

That should help.

Cheers,
Christian

Entering the credit card number in the text box and doing a form POST (not GET) - is OK in case of SSL. The POSTed data gets encrypted, so it is safe.

Displaying it on the HTML page directly is not safe. SSL only encrypts the HTML through the network layer. When it reaches the browser, it is decrypted and displayed. Hence, the page might get stored in the browser's cache. Very very unsafe.

Actually, it is a good practice to also blank the credit card number text box as soon as the user enters his credit card number. (You can read it into a hidden variable and blank the actual text box. This is because usually submit takes some time and if the user leaves the system, etc. the number can still not be retrieved, since it is kept in memory!)

About keeping in database - ABSOLUTELY NOT! Most unsafe. And if as a user of your website I know that this is happening, I will never transact on your site again! :)

However, certain business logic requires credit card numbers to be stored in database. One of my friend had done this since there was a credit option when the user gives his cc number and the cc is actually charged only at a later date. But to my knowledge he had implemented this by using a very complex custom algorithm!!

But suggest that unless business requires it (and don't give me the business reason that you don't want user to enter each time - it is not trouble for the user to enter 16 digits, it is highly risky for him to leave it with you :) ), NO NO NO to storing in database.


Best Regards
Vadivel

MVP ASP/ASP.NET
http://vadivel.thinkingms.com