A client asked me to receive credit card info of his costumers by email. I know that is a very very not secure way ... But if the page with the input form is on HTTPS, and then i use a smtp (like mandrill) that use a SSL/TLS ... the email can be sniffed from someone?


Using an encryption system like http://www.sendinc.com/ ( with their api ) could be a solution?

2 Answers 2


I would not trust credit card details to be sent out over email unencrypted, and while I am not an expert in PCI, I believe this violates PCI's requirements to protect cardholder data. HTTPS merely encrypts data transfer between the web browser and the web server over the network. If your email client is set up to use SMTP with SSL, that only encrypts data transfer between your email client and your email domain (e.g., if your address is gmail.com its encrypted while being sent to gmail's servers, but then gmail can fully read your data). Your mail server may route your plaintext email to many other servers (who would be able to read that information), even going over unencrypted networks if necessary.

Also again, I wouldn't trust PCI data with a company like http://www.sendinc.com/. They say they randomly generate a decryption key, which they will send to you, and also say they will not keep their own copy of that key. That last part relies on you trusting them not to keep a copy of your key or plaintext message, and I simply would not trust them to do so without an explicit business agreement that holds them liable to any flaws in their implementation setup that allows any malicious admin (or hacker) at their end to steal your data. If you need to send sensitive data over email, I would save it into a file and encrypt that file somehow locally (on the same computer) and then send the encrypted file to the client, and on a separate secure channel give the client the passphrase/key to decrypt it.

If this needs to be done infrequently, maybe something simple like install GPG in a linux/unix environment (like Mac OS X) and use gpg -c sensitive_file.txt, which will prompt you for a passphrase, and create an encrypted file sensitive_file.txt.gpg which you can then send for the other party to decrypt (gpg -d sensitive_file.txt.gpg) with a passphrase you've shared in person or through a non-eavesdroppable channel. Otherwise, you both should set up a public/private keys that you each trust, and then can set up encrypted email clients with PGP or S/MIME. This is a little bit more work, but most modern email clients support some form of email encryption.

PS: This request seems very strange. Are you sure you aren't being socially engineered by someone trying to steal credit card information? Make sure this is really your client, not someone posing as the client (say after getting their login credentials/email account password in any of a variety of ways) who is now trying to get you to give away credit card information in a phishing attempt.

  • Thanks for your answer. The scenario is this: - An user choose a service on my client website - then have to pay for the service - my client doesn't want any paypal or bank gateway system, but just the card details as warranty of payment ... Commented Aug 9, 2012 at 18:32
  • 1
    @Michele Matto - What? So your client isn't going to charge the credit card, but just want it in case they don't pay via check or other means? That makes very little sense. What's to prevent users giving bogus/stolen CC# if they don't intend to pay? If you want to have customers have the option to pay things online, you need to use a service like paypal or create a payment gateway.
    – dr jimbob
    Commented Aug 10, 2012 at 3:09
  • I know it's a strange request. I'll speak again with my client to change his mind. Thanks. Commented Aug 10, 2012 at 7:31

I'm guessing he wants to use some kind of PDQ machine he already has to process the card details, rather than set up a separate internet merchant account?

Regardless of whether or not that would be secure, depending on the country he's in it's almost certainly illegal and/or against the payment processors terms and conditions. I would highly discourage it, in fact I'd personally refuse to implement such a system.

It's not just the transfer of the details that you need to worry about, it's also how they're stored when they reach their destination. Read up on https://www.pcisecuritystandards.org/merchants/ for more information.

(Sorry for not actually answering your question, but I really dont think this is even an option you should be considering.)

  • 2
    I also want to point out that this type of transfer will be extremely insecure. Your client software may accesses the mail server with SSL, but the message itself will be passed between mail servers over generic port 25 SMTP. Commented Aug 9, 2012 at 14:11
  • and if the port is 465? help.mandrill.com/entries/21746318-does-mandrill-support-ssl Commented Aug 9, 2012 at 14:43
  • 2
    @Michele Matto - Port 465 only ensures that SSL is used between to transfer data between your computer, and your mail server (say mandrill.com). Meaning mandrill.com can fully read your email message unencrypted, but someone at your ISP couldn't read it (since it was encrypted over the network). However, if the final destination is not at mandrill.com (say its [email protected]) mandrill.com may transfer your message unencrypted over the open internet to yahoo.com mail servers, where people could eavesdrop. Or the client who downloads the mail, could have it setup over port 25.
    – dr jimbob
    Commented Aug 9, 2012 at 17:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .