How do you handle credit card data ?

[eshopper]

I'm coding my own shopping cart, and now I want to implement the right way to handle credit cards. I know the basics about merchant accounts, gateways and PCI.

It seems that many other shopping carts have a separate page for entering credit card data, and then continue to a confirmation page, which after confirmation will send the payment to the gateway for auth.

The question is... how do you store the credit card data between these 2 pages without having to deal with a lot of PCI compliance ?

[lorax]

Welcome to WebmasterWorld eshopper!
I'm not absolutely sure of how it's done but it seems to me you could place them in a temporary table that is destroyed after 1) completion of the sale or 2) some time limit has passed like an hour or so. Have you located any PCI compliance documentation for developers from the CC vendors?

[jwolthuis]

I'm assuming you're not going to sell your code as a standalone product, otherwise the handling of cardholder data involves the PA-DSS Specification, and a lengthy (expensive) auditing process. Alternatively, you can elect to *not* handle cardholder data, which avoids that process.

If you're just using your code for your own store, you would cookie-up the customer over https, and stash the cardholder data in an in-memory cache between pages. You are not permitted to write the CVV/CSC code to a database, and by all means don't encode anything into the URL.

Just use a secure cookie to identify the customer, and read/write to a memory cache.

[rocknbil]

you could place them in a temporary table that is destroyed after...

No. :-) I mean, it's not necessary to store it, ever, if you are interfacing with a credit card processor. Read on, there is an easier way.

you would cookie-up the customer over https

In terms of "keeping track" through the site navigation, this is OK, but to actually post to the gateway, again, it's not necessary. Nor is the use of PHP sessions, if you're into that.

other shopping carts have a separate page for entering credit card data, and then continue to a confirmation page, which after confirmation will send the payment to the gateway for auth.

IMO, this is a stupidly obtrusive method of managing a sale. Eliminate the two pages, I'm serious . . . the more clicks you have, the more sales you lose. There is no reason not to have an order summary/update/confirmation right on the checkout page.

Second, many are in the habit of entering CC info, click, DONE . . . and people wonder why they have a high cart abandonment rate. "I thought I was done."

Sites who do this are (or should be!) on a PCI compliance level higher than most of us need to be, as they DO store the CC info in some way. Even if that storage is a PHP session, that data is still stored on the server temporarily. This level of PCI compliance gets into audits of your network and hardware, which most of us can't do . . . so avoid it.

The question is... how do you store the credit card data between these 2 pages without having to deal with a lot of PCI compliance ?

There is only **one** condition under which your site is not subject to a PCI compliance review: you link off-site in payPal or processor "payment page" fashion. That is, no credit card info is entered on your site and it's handled off-site. This presents obvious problems in programming: updating after the sale, etc.

But if you want the client to enter CC info on your site, here is what you do:

1. Install a strong SSL cert, obviously. You use the term "pages" but it doesn't have to be a "page" housed in the https directory. All you need to do is when the sensitive info is requested, you point it to the secure version, like (baby-code logic:)

if (isCheckout) and (! $ENV{'HTTPS'}==on) {
# post/redirect to https version
}

This is important, don't put the entire thing on https. Just what you need, this slows down the site and (IMO) is just lazy. When done, make sure it redirects back to the non https version.

2. Now that you have an encrypted environment in which to post CC info, when that final form is submitted you do what is often referred to as a silent post:

a. accept input, cleanse, if error is found in input, return to form.
b. If input is OK after cleansing, you perform the silent post to your credit card processor (details below) and you will receive a response.
c. Based on that response,
-- 1) update database, send emails, or
-- 2) return to your form with message that there was an error posting to the gateway. DO NOT reveal specifics - "card declined," etc., this is not recommended by gateway docs and reveals too much to potential fraudsters.

So what's a silent post? There are a couple ways to do this, one of which is the command line program curl, available on most 'Nix servers.

$result = exec("curl -d 'variables=1&expected=2&by=gateway' 'url-to-the-gateway'");

Sometimes the "expected variables" are a query string, like above. Sometimes it's an XML string. It varies.

The contents of $result also vary. I think Authorize.net supports both: query strings or an XML input parameter, and returns a delimited string (you specify delimiter in POST) or an XML string.

You can extract a lot from the response, but of course the important one is the auth code, sometimes its' APPROVED|DECLINED, sometimes it's numeric, again . . . it varies. :-)

So what you have is the submit of a form, before returning a response to the browser you post to the gateway, do some stuff, respond to browser. Customer never leaves your site.

And you don't store CC info, but since you are accepting CC input, you must still meet certain PCI compliance criteria. ***

An important thing about silent post: Authorize.net servers (and others) will NOT accept input from curl via non-secure locations and will just . . . not respond. No error, nothing. So don't test in a non-secure environment, this little gem cost me a couple days at first. :-) I even had an issue once with A.N. involving the version of curl used from the posting server.

*** "Wait a second, I accept CC info and no one's said anything about being PCI compliant." My guess is that that haven't caught up to you yet. The credit card companies are the driving force behind this, mandating that merchant account providers that process their cards either pass a PCI compliance survey and scan or pay an extra monthly fee.

All in all, it's a good thing, tightens up the ship. But it's a pain in the patootie sometimes. :-)

[rachel123]

I do the perl equiv. (https LWP post to gateway). Similar to the approach rocknbil describes.

However, this mandates that the cc entry is the final step before processing. If you want cc entry at, say, step 2 of checkout, then confirmation, and then actual processing at step 4, each of those screens is (generally) a new instance of the script.

So if you want the user input (ie cc #) to survive between 2 distinct instances of the script you have to store it somewhere.

You can put it in a temp table, you can put it in a cookie, I've seen it printed to the browser as a hidden field, several diff. approaches, but you have to put it somewhere. Avoiding this is one reason why I do the way I do (https cc entry form, submit, read and parse input, send secure lwp post, return confirmation).

[enigma1]

Yes and for these reasons you're describing rachel, is best to have the cc input on the last step of the checkout process. To avoid lots of complications.

Actually it's best as rocknbil described to use a single page for checkout. Despite the use of shipping, coupons etc, everything can be accommodated in the same page and with some ajax the page won't be cluttered, at least for those with js enabled; always use an alternative for those with js off to fall through a regular checkout process.

[eamo27]

I always use third party solutions that are integrated into the cart I use. All the heavy lifting is done by the cart developers and all you have to do is purchase and enable.

[jecasc]

How do you handle credit card data ?

I don't. I let third party processors handle this. Much too risky in my opinion.

[rocknbil]

Just to clarify,

The question is... how do you store the credit card data between these 2 pages

The O.P. is posting to a gateway and is asking how to hold the CC info between entry and final confirmation. I say eliminate the two pages and summarize all in one, then post to gateway.