Wow, Jarron. Glad to see you taking this seriously. I'll answer what I can as I find time.
Quote:
|
Originally Posted by Jarron
Which gateways allow hosting of the payment form on your own web server in such a way that the cardholder data is directly submitted from the form to the gateway? And can this form be embedded within your existing checkout page?
|
There are several gateways that allow hosting the payment form on your own server. It can be embedded into the existing checkout page - I do it on my site. It requires writing your own payment module and minor tweaking to some code and templates. I use the Network Merchants Gateway which is not sold directly but rebranded by merchant service providers like Braintree or my processor Alpha Card. The USA ePay gateway also allows this. These are the two that I know of that have the security feature I consider an absolute requirement - message signing. What this means is that the form you create contains a field with your merchant identifier and a hash of several fields on the form like the order id, amount and time along with a hash code that does not appear on the form. This allows the gateway to verify the form was created by your server. Without this feature fraudsters can just pick the merchant id off your form and use it in automated tools to pound your gateway with stolen card numbers to find good ones or validate AVS & CVV information. There are several other gateways that allow you to create the form on your server that do not appear to have this feature. I don't remember most of them but Elavon's Virtual Merchant is one of them.
Quote:
|
Originally Posted by Jarron
With the processing of Payments for orders received by Phone/Fax/Email/Post, is the method of processing relevant? Or is it the fact that I have that paper/email record that defines my Compliance requirements? If so, what are my obligations?
|
There are some overall issues for all methods and specific issues for each individual method.
With any of these methods you have the issue that you are probably entering card numbers into your gateway virtual terminal using a computer at your store/office/home. That means that computer and its associated network are in scope for PCI-DSS compliance. You will at least need to comply with SAQ C for that environment. If that environment is considered connected to your web site it can push you to SAQ D. What is considered connected? Unfortunately, that is unclear even amongst QSA's. One QSA opinion I agree with is that if you are connecting to the web site via HTTPS for normal X-Cart type administrative stuff and not passing card numbers back and forth you can probably consider it not connected.
For phone orders there are possibly two issues. One, you may be writing down the card numbers. Then you must comply with paper record PCI-DSS requirements. The second won't apply to many people - its more common in call centers. If you record any customer calls you are now storing card numbers and probably CVV codes which is not allowed after authorization. Best not to do this unless you want to sort out the problems with it. If you are using an outsourced call center you must ensure their PCI compliance.
Fax requires your fax machine be in a secure area and compliance with paper record requirements. If you use a fax to email service you must ensure the compliance of your fax to email provider and the email issues below.
Email can be a big problem if customers are sending you card numbers via email. This might push you into SAQ D for storing card numbers on your email server. If you tell customers not to send card numbers via email, just a phone number you can call them at to get it and an occasional customer sends you one which you delete immediately it shouldn't be a problem according to one QSA I heard from on this.
Post/snail mail just adds the paper record requirements.