Question: I'm not a security guru. I'm thinking about how to implement credit card storage in a software system where credit card transactions are accepted through the web, but are manually executed by an in-house user. We are going to use HTTPS which (I believe) will eliminate the risk of a man-in-the-middle attack. Now, I'm trying to figure out if I can make it so that the data received from the client can encrypted before it hits our server.

The idea is that their browser would encrypt the data using the public part of an asymmetric key pair. The private part would be known by an in-house user. Then when it's time to manually process the charge, that user would go to an HTTPS page that we serve. They would manually enter the private key (which would not be transmitted to our servers) and the encrypted credit card info would be retrieved from our system and decrypted by the browser.

In this way I'm hoping I can keep any of our servers from ever seeing unencrypted credit card information. Am I missing some well known security hole? I've read [this](http://www.matasano.com/articles/javascript-cryptography/) which seems to address a different kind of security hole. I've also read a few other SO questions, but none of them seem to map clearly to this particular design.

Edit #1: @Pointy asked why not use the industry standard. Major online retailers use solutions that are far more sophisticated and expensive than my problem warrants. Major retailers automatically process their transactions so typically work toward PCI-DSS compliance. This is not the problem that I'm trying to solve. I'm working on automatic tools to securely assist in manual transaction processing.

Edit #2: @Jason Dean pointed out that I didn't describe the plan for managing the private key very well. The idea is literally to have our employee keep it on a piece of paper at their desk. Our main concern is with remote security violations. Our physical site is secure enough that we're not worried about someone breaking in. The idea would be to keep the private key out of any persistent storage on any machine anywhere that way no purely electronic attack could possibly get both the data and the private key.

Answer: 
> 
> They would manually enter the private key (which would not be transmitted to our servers) and the encrypted credit card info would be retrieved from our system and decrypted by the browser.
> 
> 
> 

It would be harder to keep secure and type in (or copy/paste) the private key than it would be to simply type in the credit card number. I would call this a rather obvious mistake in your scheme. Note that security protocols are hard, and as you are "not a security guru" I would strongly discourage you of trying to think one up.
It's interesting that you are so concerned about the unencrypted data being seen by the server, but your willing to give the decryption key for all of that important to whatever $8/hour monkey you decide gets to type (or more specifically copy and paste) asymmetric keys all day. 

Where do you plan to store these keys so that your monkey can get to them for copy/pasting? They'll need to be in plaintext for that. 

Key management is, without question, the hardest thing to do in cryptography and you are talking about violating best practice protocols by making the key available to users that should not need it and by storing it insecurely. 

SSL already takes care of encrypting your data before it leaves the client, then, when it reaches the server, you need to encrypt it again before storing it. You can use asymmetric crypto for that if you really want to. I would not worry about trying to do it at the client. 

I think you are making things way harder than they need to be and with no benefit for your effort.