X-Cart forums

[xplorer]

Originally Posted by BritSteve

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?

If so, I believe you will need X-Payments. X-Cart won't be certified as a PA-DSS verified application. As far as I know it will be prohibited to use solutions that are not certified.

For now I can't say how much work it will take to make an X-Cart 4.1 store integrated with X-Payments. We haven't tried it yet.

Originally Posted by Duramax 6.6L

Looks like then end to one page check-outs

There is an idea that we may implement in future X-Payments versions.

Originally Posted by Duramax 6.6L

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

Since X-Payments will be isolated from X-Cart and other web applications installed on your server, hackers won't be able to hack X-Payments via a bug in other applications.

Also, PCI DSS ensures that the payment application create logs and that the logs contain all the information needed to catch a hacker.

[geckoday]

Originally Posted by xplorer

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

Boy, someone sold you a bill of goods. You must have hired an extremely overzealous QSA. If you look at the PCI-DSS 1.2 Requirements and Security Assessment Procedures document you will see there is an Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers that makes it quite clear that shared hosting is allowable under PCI-DSS. It does require that processes run under the merchants user ID, so a shared host using mod_php could not be used, but a host using suphp should be fine. It is up to the merchant to validate that the host meets the requirements of Appendix A.

Originally Posted by xplorer

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).

Wow, again. This simply isn't true. Ask your QSA to point you to the specific PCI-DSS requirement that dictates this. Take a look at your competition who are already PA-DSS certified -- they don't have this requirement because it doesn't exist.

If this kind of stuff is going to make it into your PA-DSS required implementation guide you are going to put yourselves at a significant disadvantage in the market place. Forcing merchants onto multiple dedicated servers/VPS, X-Cart on one and X-Payments on another, will send your old and new customers to competitive shopping carts that have done the job right and don't impose silly "PCI requirements" that don't exist.

[carpeperdiem]

I smell language barrier here...

A couple of years ago, X-Cart put all kinds of PayPal code in place that was one person's interpretation of the contract -- but the reality was that none of the "requirements" were in the contract. X-Cart's engineer just misread it/interpeted it incorrectly.

Sounds too familiar.

I'm with Ralph on this...

[exsecror]

@geckoday

I should point out that using suPHP is a deprecated security method (and also very slow and very buggy). It was mainly a workaround because Apache's suExec at the time didn't work correctly with PHP in FastCGI mode. This is no longer true (we've been running FastCGI + SuExec for years).

[geckoday]

Originally Posted by exsecror

@geckoday

I should point out that using suPHP is a deprecated security method (and also very slow and very buggy). It was mainly a workaround because Apache's suExec at the time didn't work correctly with PHP in FastCGI mode. This is no longer true (we've been running FastCGI + SuExec for years).

Yes, FastCGI & SuExec works as well, the key is the processes must run under the merchants user ID. There are some people who prefer using SuPHP as it has features that SuExec does not. It is not deprecated (perhaps it is generally going out of fashion) and is still maintained by the author. Many of the typical X-Cart customer hosting environments will be running suphp rather than FastCGI.

[geckoday]

Originally Posted by carpeperdiem

I smell language barrier here...

A couple of years ago, X-Cart put all kinds of PayPal code in place that was one person's interpretation of the contract -- but the reality was that none of the "requirements" were in the contract. X-Cart's engineer just misread it/interpeted it incorrectly.

Sounds too familiar.

I'm with Ralph on this...

May not be only language. Here's a good article by a QSA on how some well meaning QSA's inflate the PCI requirements.

[exsecror]

Originally Posted by geckoday

Yes, FastCGI & SuExec works as well, the key is the processes must run under the merchants user ID. There are some people who prefer using SuPHP as it has features that SuExec does not. It is not deprecated (perhaps it is generally going out of fashion) and is still maintained by the author. Many of the typical X-Cart customer hosting environments will be running suphp rather than FastCGI.

Actually suPHP has no real advantages over SuExec + FastCGI. The configuration is still extremely basic (also everything that can be done in suPHP's configuration can be done in the FastCGI+SuExec method). There's also the fact that it's not mpm-worker friendly (at least the last time I tried it, it constantly cored and mpm-prefork is not SMP friendly). Besides with the fact that Apache took over the mod_fcgid project and is integrating it into Apache 2.3 the FastCGI support is far better than it was years ago.

[geckoday]

Originally Posted by exsecror

Actually suPHP has no real advantages over SuExec + FastCGI. The configuration is still extremely basic (also everything that can be done in suPHP's configuration can be done in the FastCGI+SuExec method). There's also the fact that it's not mpm-worker friendly (at least the last time I tried it, it constantly cored and mpm-prefork is not SMP friendly). Besides with the fact that Apache took over the mod_fcgid project and is integrating it into Apache 2.3 the FastCGI support is far better than it was years ago.

There are differences that still matter for some people but if you want to talk about suphp vs fastcgi/suexec take it to a new thread. For the purposes of this thread either is an acceptable method of getting the webserver process to run as the merchant user id for PCI compliance in a shared hosting environment.

[exsecror]

Originally Posted by geckoday

There are differences that still matter for some people but if you want to talk about suphp vs fastcgi/suexec take it to a new thread. For the purposes of this thread either is an acceptable method of getting the webserver process to run as the merchant user id for PCI compliance in a shared hosting environment.

Yeah I think we'll pretty much end it there to avoid detracting from the thread. I do agree with you on that bad information concerning shared hosts. Unless it was a really cheap poorly ran shared host there's nothing saying you can't practice eCommerce on it and be compliant.

[cflsystems]

Originally Posted by xplorer

Since X-Payments will be isolated from X-Cart and other web applications installed on your server, hackers won't be able to hack X-Payments via a bug in other applications.

Also, PCI DSS ensures that the payment application create logs and that the logs contain all the information needed to catch a hacker.

Then why not just make X-Cart PCI-DSS instead of developing a new application to handle this? Originally I was under the impression XPayments will be integrated part of xcart store not almost like payment gateway