I’ve been delving through the knowledge on the site, and still seem to be having trouble locating the answer for my exact situation. A company i consult with is accepting credit cards via email or fax. They provide a service for their customers, so they store the card information and then they use it to pay for various things, like storage of belongings, or other services. Kind of like giving your credit card number to your wife, so she can buy something for you. So, what category does this put them in for PCI compliance? I assume they are a service provider. But… I’m trying to get them to implement a web solution for accepting the card numbers, so it is encrypted during transmission over the internet. And it will need to be encrypted in the database where it is stored. So does this now become a Payment App? or a Payment Gateway? The picture is blurry right now, and I need to clear it up some. I appreciate the help.
-Mike
Sending credit card numbers via email is a breach of PCI as the card number is then stored on various mail servers connected to the internet prior to it reaching its destination. Card numbers are not allowed to be stored on a computer accessible from the internet. Accepting via fax should be okay as then the card number never goes onto the internet in the first place.
To be PCI compliant the page collecting the card number must use HTTPS so that the number is automatically encrypted between the browser and the server - a large range of other conditions then apply to what has to happen to it after that/
I should have clarified that some. They have users fax a completed form to their internal fax server which pdf’s the fax and emails it internally to a processing account to be uploaded into their database system. So the email is all internal, but still it’s in an unencrypted form on that server which isn’t good. So, that’s why I was asking them to set up an https webserver for direct input from the user across the internet to the database server. The question becomes, what are the requirements that need to be met if they are accepting the card number (including the expiration and code), storing it encrypted in their database, and then allowing specific agents to access that information to use to pay a 3rd party for the user.
Does this make them a service provider?
Is there an issue regarding the storage of that information in the first place?
If they write an application that retrieves the card information from the database, only displaying the last 4 to the processing agent, and then behind the scenes passing it to the 3rd party for payment, does that make it a payment application?
What I need to do is figure out what they are, so I can figure out what the requirements are. They are even talking about using an SFTP/EFT server with an HTTPS web frontend as an option for transferring files encrypted from the user.
Sounds like the best option for you would be to use a third party billing provider. They are slightly more expensive, but when you take into consideration they do all the PCI, hosting, process, etc. its actually a pretty good deal. If they dont have good security that is usually my recommendation as it is something you really need to keep on top of. PCI compliance can be tricky and expensive to get verified (if you do it properly). Avoid all the hassle and go with a thirdparty provider like 2checkout (there are many others, thats just the first one I can think of).
The PCI scope of something like this is so big, I wouldn’t even attempt to try to hack this into something secure. Everything needs to be operating over secure connections, but how do you maintain accountability for the data over every step of the process is what I would be asking? When you add in any 3rd party network, service provider, etc., it makes PCI virtually impossible to prove as well.
Are they the ones charging the cards themselves? Assuming so, best bet is to use a payment gateway and a customer vault or token based storage system. How this works is that you create a payment authorization page that is hosted securely. The customer enters their card information on that page, and that information is then stored directly with a payment gateway. You can charge the card right away or just store information without charging anything. The gateway returns a token that the merchant can later use to bill or re-bill the customer’s card. They can also log into the virtual terminal and manually charge the card. The token needs to be stored securely still, but as long as the token itself cannot be used to retrieve the card number (No payment gateways allow this that I know of), the PCI scope is significantly reduced and the whole process is simplified.