Well this is a huge can of worms. In early 2004 (if memory serves) Visa required all its merchants above a certain threshold that sell on-line to be "certified" as "CISP" (Cardholder Info Security Program) compliant. Non-Categorized merchants - which may be defined as merchants with less than 6,000 transactions a year, no "hack" attempts (pretty vague) and who are not on Visa's radar - have avoided the cost of auditing by keeping a low profile while visa has other fish to fry - but the free pass may be coming to an end. Since "level 1" merchants are anyone that Visa says they are, they can require you to submit to an audit (at your expense) in order to continue processing Visa transactions. Wait.. it gets suckier....
If you are identified as "level 1" you must have an annual onsite security assessment by a crony... er.. company certified by Visa. You also must have your network scanned quarterly by an independent scan vendor. The cost of these changes is enough to make you flock to Paypal.
What does it take to "get certified"? The following items are on the checklist. Much of this is "network" related so you may need to talk to your provider unless you host your own.
What is interestingly absent from this list is encrypted data. The only mention of encryption has to do with ensuring the transmission of data was encrypted.
In my opinion you should not choose to store the Credit Card Number in the database unless you have a reoccurring charge - a subscription service. Simply require folks to re-enter that bit each time they purchase from you. If you do choose to store the CC data you should follow the guidelines above (within reason) - even if you are not subject to an audit. Personally, in my view the credit card number should always be stored as encrypted in the DB, and it should never be visible or unencrypted until the time comes to create a transaction. Moreover I would also use the CVV2 value and encrypt that as well. Since it is a check bit of the number and the exp date against a key value (generated by Visa) it is a valuable bit of information - arguably more valuable than the exp. date.
To encrypt I think I would shy away from cfencrypt in favor of one of the many Java based CF tags found on CF Lib.org. I'm sure that on CFMX the cfencrypt tag is safer than it was on CF 5. But since I've been avoiding it for years now, why stop.
One final note, you can also encrypt the network packets to and from your SQL server using built in net libraries. While this is doable it slows down your connection considerably in my experience. If your DB server and Web server are on the same network this might be overkill. If they are not on the same network (not a good idea but sometimes necessary) then I would recommend a hardware solution like 2 pix routers with point to point 3DES. This keeps you out of the business of managing encryption as well as all the other stuff you have to look after on your SQL server.