As soon as you've processed the transaction delete the card from your database. If it's not there then an attacker can't steal it!
It's not clear to me that this is always the safest option. Consider a shop where customers come back, and over time, do repeated purchases. If the shop doesn't store the credit card information, customers have to resubmit their credit card info for each purchase. So the shop reduces the number of credit card numbers stored in their on-line database (unfortunally, that doesn't mean the numbers are gone - good database management means keeping backups and transaction logs and those can stolen as well), at the cost of having more numbers floating over the network.
(Further remarks are addressed to the OP)
Security is more than win2k vs apache (which isn't a valid trade-off anyway, it's like saying "shall I have bread, or peanut butter" - you can run apache on win2k. You can make win2k secure, or leave it unsecure. You can set up apache securely, or unsecurely). It's more than the OS, web server, your code and any third party code. It's also the people - many credit card number thefts are inside jobs. Your code and setup can be bullet proof from the outside, it will be of no use if an operator makes a private copy of your database backups.