X-Cart and PCI DSS / PA-DSS compliance

xplorer · #51 11-18-2009, 01:19 AM

Hi folks,

1. More info on system requirements for X-Payments:

First of all, X-Payments will require a dedicated server. It is not because of its performance, it is due to the PCI DSS requirements. I believe that no stores hosted on shared servers will ever be verified as PCI DSS compliant. The only exception are stores that don't collect credit cards via the store website

Also, if you host X-Payments with other web applications on the same server, the server will require a special configuration because PCI DSS dictates a payment application (X-Payments) to be isolated from other applications (your website, X-Cart, forums and other web applications). It can be done either on the hardware level (different hardware servers) or on the software level (firewalls and jail systems).

Most likely X-Payments will require PHP 5.3 and MySQL 5.

It will require an SSL certificate.

2. How it will look in the storefront:

When a customer places an order and chooses a payment gateway handled by X-Payments, he will be redirected to a payment page hosted by X-Payments.

X-Payments will act like payment gateways hosting payment pages on their websites: it will collect credit card data, request a payment transaction and redirect the customer back to X-Cart

The difference is the domain name. With X-Payments you can control the payment page URL. For example, if your store is located at http://www.mystore.com/ , you can install X-Payments at https://payment.mystore.com/

So, the payment page will be on a different subdomain, but on the same domain with your X-Cart store

Duramax 6.6L · #52 11-18-2009, 03:13 AM

Will you need a dedicated server or will virtual servers be OK, the way that PCI DSS is going, quite a few smaller stores are going to go out of business as they will not be able to afford a dedicated server.

xplorer · #53 11-18-2009, 03:21 AM

I'm not sure about virtual servers. I guess it is acceptable provided there are no ways for users and applications installed on one virtual server to affect users and applications installed on other ones. And I believe it is the way how X-Cart and X-Payments should be installed on the same server machine: each should be on its own virtual server.

As for smaller stores. Most of them will switch to payment gateways that collect credit cards from their websites, not from a merchant's website. There are many payment gateways offering such an integration method.

carpeperdiem · #54 11-18-2009, 03:30 AM

Quote:

Originally Posted by xplorer

When a customer places an order and chooses a payment gateway handled by X-Payments, he will be redirected to a payment page hosted by X-Payments.

Uh, adding a 3rd party to the transaction? And what makes this safer for the data?

Sorry, but we invested substantially in getting our server PCI approved. I will imagine that as soon as a 3rd party is introduced to the payment gateway chain, all of our hardening will be for not.

And based on the reliability of x-cart hosting, I wouldn't trust my payment processing to you guys at this time. First Data (sales of more than $10 BILLION) has a hard enough time keeping their servers up 24/7, how can we be assured that your servers for x-payments will always work, no down time, ever, and have redundancy and fast processing worldwide, all the time. How many transactions can x-payments handle per second? Are you running the servers from multiple data centers, with load balancing and redundancy? Will you have 2 or 3 live backups that will kick in in case of failure? On multiple networks? Geez...

I KNOW that you are not trying to be a payment gateway, but by design, you will be JUST AS CRITICAL to the transaction as the gateway.

Sorry, but you can count me out.

xplorer · #55 11-18-2009, 03:54 AM

Quote:

Originally Posted by carpeperdiem

Uh, adding a 3rd party to the transaction? And what makes this safer for the data?

X-Payments is not a service. It is an application installed on your server. Perhaps, "hosted" is not the right word. The payment page is displayed by X-Payments.

cflsystems · #56 11-18-2009, 04:01 AM

carpeperdiem thinks X-Payments will be hosted on QT servers and we all have to connect our carts to QT servers for payment. Is this really the case? If yes what is the difference then for having cart connected to the payment gateway we are using right now and QT X-Payments? If that's the case I better use my payment gateway off site. Or X-payments will be just a separate application on my server? Also when you say it will require SSL do you mean separate SSL for X-Payments only?

BritSteve · #57 11-18-2009, 04:48 AM

I find this very confusing. We have a separate firewall, a web server and a database server. The Web server is scanned daily and is PCI compliant. I send the SAQ every quarter.

We use Usaepay as a gateway, and do not store card numbers or CVV data.

Do we need a separate payment server to remain PCI compliant?

Steve

xplorer · #58 11-18-2009, 05:11 AM

Quote:

Originally Posted by cflsystems

carpeperdiem thinks X-Payments will be hosted on QT servers and we all have to connect our carts to QT servers for payment. Is this really the case? If yes what is the difference then for having cart connected to the payment gateway we are using right now and QT X-Payments? If that's the case I better use my payment gateway off site. Or X-payments will be just a separate application on my server? Also when you say it will require SSL do you mean separate SSL for X-Payments only?

X-Payments will be just a separate application on your server.

You need an SSL for the domain where X-Payments is installed. If it is "https://checkout.store.com", you need an SSL for "checkout.store.com". Or you need a wildcard SSL for "*.store.com".

Quote:

Originally Posted by BritSteve

I find this very confusing. We have a separate firewall, a web server and a database server. The Web server is scanned daily and is PCI compliant. I send the SAQ every quarter.

We use Usaepay as a gateway, and do not store card numbers or CVV data.

Do we need a separate payment server to remain PCI compliant?

Steve

I'm not an expert on PCI compliance and can't consult you on this matter. However, I guess it depends on whether customers enter credit card numbers on your website, or on the USAePay website. If your server and web applications never touch the credit card data (i.e. it is collected on the USAePay website and is never transmitted to your server), I believe you don't need X-Payments at all.

BritSteve · #59 11-18-2009, 05:20 AM

Thanks for the info.

We don't redirect to Usaepay but collect the card info to pass onto the gateway. I will ask our PCI scanner if they can give a definitive answer on this one.

Am I correct in assuming that we will need to use x-payments in order to remain PCI compliant? How difficult will it be to add x-payments, how much work is involved?

Steve

Duramax 6.6L · #60 11-18-2009, 05:29 AM

basically you will have to maintain a seperate domain with the x-payments module installed on it, xcart will handle the shopping functions, then send you to the x-payments module, the x-payments module will talk to the gateway that you choose to process the credit card info, then pass the approval or denial and the customer back to the original store site to finalize the transaction.

Looks like then end to one page check-outs

I do not see how this would be any safer that how xcart handles the credit card transactions now.