Just making this comment because it wasn't specified in the question - a 2048-bit key should be used as a minimum (but I'd go even higher if I were encrypting something as sensitive as credit card numbers).
–
hunterNov 7 '13 at 17:30

@hunter The actual key management is not specified. The key management procedures around the private key are very important. Key size is important, but it is only a very small part of the key management. Then again, those would be more at place at security.stackoverflow.com. For credit card numbers I would certainly first check the requirements of the credit card companies themselves.
–
Maarten BodewesNov 7 '13 at 19:03

@owlstead - yup, key size is only a small part of key management - but one that often gets overlooked with RSA - I'm amazed at the number of people still using 1024-bit keys in the wild. Thought it was worthwhile making a PSA.
–
hunterNov 7 '13 at 19:13

Great! We use a 4096 key with the public key in the codebase, and the private key on our local-network payment server. To decrypt the log, we login to the payment server and paste the cyphertext into openssl's stdin. We intend to change the key every couple years.
–
cmcNov 11 '13 at 10:48

Be aware that your solution will touch much more than cryptography. Your command shell, the account it runs on, the swap file, the whole machine falls under the purview of PCI DSS regulation and auditing.

If you can avoid storing or even handling the number, so much the better.

We are PCI certified so that's fine. But I agree it shouldn't be taken lightly; we decided payment processing is a core competency for us, because of the market edge it gives us in responding to customer needs combined with a software customization framework.
–
cmcNov 11 '13 at 10:44