With respect, what you propose to do is a very bad idea. You'll have an extremely hard time passing a Payment Card Industry Audit if you store card numbers in a form where it's possible for your software to decrypt and use them. And if a cybercreep compromises your system you'll get the dreaded call from Brian Krebs (of krebsOnSecurity.com). Use stripe.com or Braintree instead. They have very competent security teams. They give you secure tokens to represent your customers' card numbers.
But that is not what you asked. You want a reversible way to encrypt payment card info.
You could use a private/public key scheme. To do this with best security, you'll generate the key pair on a machine you usually leave switched off and disconnected from the network. You'll copy the public key to your web servers, and use it to encrypt the payment card data. (By the way, merchants are forbidden from storing the 3-digit CVV number in any form.) php offers the openssl_public_encrypt function for that.
Then when you need to decrypt the card numbers, you'll temporarily switch on the secure machine and decrypt the card numbers there. You can use openssl_private_decrypt.
I once renovated a payment processing scheme that did this secure-machine thing so it used stripe.com instead. Everything about using the service was easier.
In general, to store sensitive data (other than the tightly regulated payment cards) you
- use your DMBS-furnished encryption-at-rest scheme to encrypt your tablespaces.
- read and follow the OWASP recommendations for securing your web app.
- perform penetration tests on your system. Burpscan is one of several tools you can use to do this yourself.