Credit Card Number in POST var

There really is no other way to send it. $_GET would not be the way to go. As long as it's over an SSL connection, you're fine. Just make sure that the actual form is posting to an SSL location. It doesn't matter if the form itself is over a secure connection, unless it's displaying confidential information.

Storing card information in a database still makes me nervous. I always choose to use a third party for card transactions.

Preface: this may be over the top of what you are asking as you may already know some of this, but I wanted to elaborate for those who may come here looking for this type of info.

As mentioned, the page that displays the form to fill in does not need to be secure, IMO it is still best to do so as it help reassure some customers when they see this. Additionally, if you have any SSL certificate seals on your site, they may not show properly if the page they are on isn't secured, and what good is the confidence building of having the seal AFTER they entered the info

Unless absolutely necessary, do not store the credit card information in any way (not counting it as being in a variable while the page is processing as storing). Most payment processors have methods of recurring billing and they will store it for you.

If you do need to store it, or.. ack... e-mail it, make darn sure you have plenty good enough encryption on it. NEVER EVER send it in plain e-mail (I have seen two companies do that!!!)

Now most places will keep things like last 4 digits on file in case they have to verify with a customer or something. Some places will also keep the exp date and the CVV (CV2, CCV, different terms for the extra code on cards now). BE SURE TO NOTE: Per your agreement with your merchant account, and per their agreement with Visa and MasterCard, you are NOT allowed to store the CVV # in any form. It is to be used for the immediate transaction and nothing else. This is "technically" grounds to loose your account. If you do have the need to keep a card on file for future payments, you really do not need this code, as you have already run the card the first time with it. Only request it again the first time you process a new card.

Back to basic security...

When companies think about the security of order processing, one thing many do not consider is the person programming the site! If they know nothing about the programming, they are at the mercy of whoever has access to program their site. Even if they don't store the card #'s, even if they use best encryption, anything and everything... guess what... you get a devious employee, and he's got your customers credit card information. And with cards that don't have an expiration until a few years out, he could be gone from your company for over a year before he uses OR sells that.

I have personally seen a company who was screwed out of tens of thousands of dollars because the dork in charge of the server decided to reroute funds to his own account. If you are not the programmer, keep damn good track of money coming in vs. what is bought on your site. This is no area to just "think" things are good. The problem with the company that had money lost for MONTHS, was that the person in charge of the finances thought she was too good to be told anything by anyone, and didn't know anything about how it should be done. And worse, I was told later that the people in charge had "feelings" something was up for the months it was happening. If you have a feeling about something not being right, stop everything and get an audit of things.

Even if you are getting the funds, the person could write a script hidden to send themselves the info. If you ever have a employee change in this area make sure you have the new employee check EVERY bit of code that goes with the credit card handling. EVEN "canned" API scripts for the payment processor that are on your server. One line of code is all it takes to mail off the credit card info. When i first did a credit card payment system, I was not about to let it go live until I understood everything in the "canned" authorize.net class we were going to use. I'm just that paranoid, I still wrote my own. Same with the encryption LOL.

In todays world, imagine the implications if someone is able to track down misuse of their credit card to a breach in your security! It gets out, and EVERY customer of yours wants compensated for all the time and trouble of going back and double checking all their statements, canceling their cards, getting news ones. Again, with cards with an expiration date 2 years out, even if a card hasn't been misused yet, it was still compromised and is at risk, so they need changed.... Better have good company insurance, not to mention the reputation hit you just took.

Now, the intentions of this is not to scare anyone away from credit card processing, but to scare you into making sure you realize to make yourself knowledgeable of the area before you just go get someone and say "set me up credit card payments on my site". Make sure to ask for references if you don't personally trust them with what I described in the paragraph above. And when in doubt, belly up and pay for a "known" service for handling this if you must. This is YOUR business at stake!

Again, this goes more than what was asked, but in case someone searching for basic credit card processing finds this post, I wanted to inform as much as possible. I deal with programming e-commerce sites often now, and want to help those getting started be safe!

-Greg

Security is to be taken into consideration, also taken seriously and put into practice, but you have a need to temporarily store data, so there is really nothing you can do about it.

From what I see you have taken all the required security measures and the same ones that most large companies websites use.
No-one can access data they shouldn't by normal means, find data by chance or even use simple hack methods with the procedures you are using, so there is nothing more you can do.

If someone has advanced hacking skills, and is good enough to "hack" the server and/or sniff/listen to port data (etc) and get post data, sessions and other stuff, then you are likely in trouble regardless what you do.
By that I mean if someone for whatever reason has targeted that website, and has abilities to carry out the above without initial server access, then it likely doesn't matter what security measures you take, they will get in anyway regardless of how good your security is.
That's their abilities, not your lack of security.

That of course is hardly going to happen, not impossible, but extremely unlikely, so you shouldn't worry about it.

Carry out the best security you can, but don't 'worry' about it.