X-Cart forums

[Swish]

My bet is x-cart 5.0 is proving to be a bigger task than QT had anticipated. 4.4 is a gap filler and maybe 5.0 is another 18 months/two years away. Still you x-carters should think about us Litecommercers who really are left out in the dark. I can't afford to make the shift to 4.4 and then again to 5.00. I got to admit, QT need to get their act together and commit to a 5.0 release date otherwise a shed load of us will have no choice but to jump ship.

[Steel]

Hello Vyacheslav,

Based on discussion in the X-Cart and PCI-DSS / PA-DSS compliance thread, I am under the impression that X-Cart and your PA-QSA did not have a handle on the PCI issue (as relates to the most user friendly PCI option for merchants) until late last week, and as such, your previous efforts are having to be modified.

I suspect that v4.4 is being developed, as it is the path of least resistance, to be able to offer a couple* of PCI compliant cart solutions by the July 2010 mandatory compliance deadline. Can you provide a definitive answer as to whether or not v4.4 will be PCI compliant?

* One Page Checkout
http://ideas.x-cart.com/pages/32109-feature-requests/suggestions/373001-one-page-checkout?ref=title

Assuming v4.4 is stable by May, two months will not provide a lot of time for installation and development.

For those of us with limited resources, and where time is of the essence, it would be helpful to have an ongoing update of the X-Cart Roadmap with as much detail provided as available.

Is the X-Payments v1.0 module still planned to be available in January 2010, and is it realistic to expect that it will provide a PCI solution for v4.1 cart users?

Will v4.4 focus on shipping and billing changes, where there might not be any changes to the item/product databases, where prior version users could justify migrating the item/product databases to v4.3, and get that information up to date? Or, would it be better to just wait for the v4.4 release?

What will be the best update path from v4.1.12 to v4.4?

Previously, v5 was to be available this year, and is currently listed in X-Cart Roadmap as scheduled for release Summer 2010. Do you still expect this to be a realistic release date?

Thank you

[RichieRich]

is the 4.x branch going to be supported once version 5 is here? Otherwise it wouldnt be worth the hassle

[exsecror]

Well we've been on 4.1.x for god knows how long, we're making the migration to 4.2.3 (because let's face it, our current site is just awful in so many ways) and I've been heavily modifying the code base mainly to switch to PostgreSQL, get us out of PCI scope (I don't feel like waiting till version 5 just to get the compliance updates out of the way) and fix a huge number of bugs that are in the core of the program. The fact is we'll probably never upgrade to 5 simply because I don't want to have to integrate code for eBillMe, iShopUSA, and Amazon FPS (which will be on our new site) all over again. We'll more than likely look at a higher end proprietary solution at that point as I'm just one guy and maintaining a forked branch of x-cart for our needs is taxing.

[lash]

I will continue on the 4.1 for awhile. I want to try the 5 for the big revamp of the site but who knows how long that would take. I though it would be out the end of this year so I could start development beginning of 2010, but now it seems like it won't be stable until late 2010. I also don't want or can afford to wait too long..as for now I will continue develop the 4.1, get new mods, etc. It just sucks if I have to make big and costly design changes 2 times in a year. I also have way too many custom development and mods and I guess it all has to be redone. Just wonder how much it will cost me to do the update. Unless version 5 is something really special I might have to abandon the ship. X-cart is hardly used in my country which means to many extra costs and I would probably be better off choosing a platform that is.

[bigredseo]

Originally Posted by cherie

In light of how many in this thread feel, it would have been better if v5 was never mentioned. This is why some companies don't announce future versions of software and hardware. If a hardware maker announced a new laptop was coming out next year you may not buy the current one or you may not be happy with the one you just purchased.

The reason that Version 5 was mentioned (and previously scheduled fro release in Winter 2009) was spicifically because of the PCI/PA-DSS Compliance issues. We were told in early 2009 that the current version of X-Cart would not be compatible. A new thread was then made (by X-Cart) asking what we wanted to see in Version 5, with a projected delivery date of Winter 2009, and then extended to Summer 2010.

The problem now is that a new 4.x version has been released with still no real grasp on what the status of Version 5 is (their proposed solution). When we do upgrades of the software, it's not cheap. THOUSANDS of dollars are spent upgrading between branches, heck even just some point versions get thousands of dollars due to reworks etc.

So we're left, waiting, hoping, and praying that production on Version 5 has actually started and that it can potentially resolve the issues that are required. If there is no PCI/PA-DSS Solution by July of 2010 (the date enforced by Visa & MasterCard), then we will see many people headed to other carts. I'd say that if there was no released version by April/May we'll see a mass exodus to another very popular cart which IS compliant and has been since earlier this year.

[cherie]

Originally Posted by handsonwebhosting

So we're left, waiting, hoping, and praying that production on Version 5 has actually started and that it can potentially resolve the issues that are required. If there is no PCI/PA-DSS Solution by July of 2010 (the date enforced by Visa & MasterCard), then we will see many people headed to other carts. I'd say that if there was no released version by April/May we'll see a mass exodus to another very popular cart which IS compliant and has been since earlier this year.

I'm pretty sure the PCI issue was separated from the X-Cart version with X-Payments, due next month. Unless I'm missing your point, I believe that will solve your issues and it doesn't rely on v5 (or v4.4).

http://www.x-cart.com/roadmap.html
http://forum.x-cart.com/showthread.php?t=46073

[xplorer]

Hi!

Thank you for your feedback! We will consider this once again and maybe will remove X-Cart 4.4 from the development plan.

As for PCI compliance:

The PCI DSS security requirements apply to all network components, servers, and applications that are included in or connected to the part of the network that possesses cardholder data or sensitive authentication data. If the part of the network is not isolated (segmented) from the remainder of the network, the entire network (with all purchased and custom applications, including web applications either) is in scope of the PCI DSS assessment.

The easiest way to reduce the scope of the PCI DSS assessment is to completely outsource credit card processing to a PCI-compliant payment gateway so that your server with all installed web applications (including X-Cart) is isolated from the part of the network that possesses cardholder data. You can do this in any X-Cart version by disabling all built-in CC processing functions and using X-Cart in connection to a payment gateway that hosts the payment form on its own server. Note: there are payment gateways that allow you to host the payment form on your web server in such a way that the cardholder data is directly submitted from the form to the gateway. Since the data never touches your server, the server may be moved out of the assessment scope (please consult with your acquirer to clarify whether it is true for your payment gateway).

For those who can't or don't want to completely outsource CC processing to a payment gateway, we will release X-Payments. X-Payments is a stand-alone web application with encrypted code acting like a proxy between an X-Cart store and a payment gateway. When a customer places an order in X-Cart, he will be redirected to the payment form displayed by X-Payments. X-Payments will handle the entire payment processing job and will redirect the customer back to X-Cart. So, X-Payments is the payment application that processes and transmits cardholder data, not X-Cart. The main idea is still isolating X-Cart from the part of the network that possesses cardholder data, however now X-Payments (the payment application) is included into that network part and is in the scope of the assessment. Since payment applications will be subject for PA-DSS rules soon, X-Payments will be certified by an authorized PA-QSA as a PA-DSS verified payment application (Q1 2010).

For X-Cart 4.3 there will be a connector module that integrates X-Payments with X-Cart. It may happen that X-Cart 4.2 users will be able to use the module with a few modifications. Integration of X-Payments with X-Cart 4.1 and LiteCommerce most likely will require customization.

Why not to certify X-Cart as a PA-DSS verified payment application? The reasons are:
1. PA-DSS would require costly certification of every released X-Cart version
2. You would experience difficulties when explaining your acquirer that the custom modifications made to your X-Cart are not against the PCI DSS requirements

[geckoday]

Vyacheslav,

It appears you still don't have a realistic handle on the PA-DSS/PCI-DSS compliance issue.

Answer me this:

Why would anyone use X-Payments to connect to Authorize.Net AIM when Authorize.Net offers SIM which does exactly what you are building X-Payments to do? SIM has been out for years and works. It has a module in X-Cart to interface to it today. No need for a new module to install. No need for a whole new application to install. No need for a whole new configuration process to go through. No need to take risks on a whole new system that provides no tangible benefits.

Originally Posted by xplorer

Why not to certify X-Cart as a PA-DSS verified payment application? The reasons are:
1. PA-DSS would require costly certification of every released X-Cart version
2. You would experience difficulties when explaining your acquirer that the custom modifications made to your X-Cart are not against the PCI DSS requirements

1. Your chosen implementation goes well beyond what is required to remove X-Cart from PA-DSS scope. Other vendors use modules that reside alongside their core product rather than your complex design trying to build a whole new gateway service to be run by the merchant with security measures even the largest gateway services don't have.
2. Only if you are storing credit card numbers and must fill out SAQ D or are big enough to require a QSA review. In these cases, your whole development process is in scope anyway and this shouldn't be a big additional burden. If you are a level 3 or 4 merchant not storing credit card numbers and filling out SAQ C then this doesn't apply.

Lets get this very clear. What your customers want is:
1. PA-DSS certification.
2. Continue to run on a single server or single shared hosting account.
3. No change to the payment form integrated into the checkout process - not an Authorize.Net SIM-like solution, a solution that looks like the Authorize.Net AIM module in X-Cart today.

If you don't listen to your customers you will lose them. If I were looking at X-Cart/X-Payments today as a possible eCommerce solution for my company the X-Payments checkout process would kill it as an option.

I have 30+ years of big shop IT experience. 15+ of that in retail and eCommerce managing development teams. I have worked with many IT security officers. Security people are very focused on security by itself. You have to bring a business focus to them or you will get the equivalent of a house with armor plating, windows with bulletproof glass and electrified bars and mantraps at every entrance. During the last year I have been studying PCI-DSS/PA-DSS. I hang out on security forums. I have seen the tendency to overstate PCI-DSS/PA-DSS requirements. You have to challenge statements that PCI-DSS requires x and get it truly justified by a PCI-DSS/PA-DSS requirement. Often there are multiple ways to meet a PCI-DSS/PA-DSS requirement. If you don't like the proposed solution to meet a particular requirement push for alternatives. If you don't start challenging your staff and security consultants to give you a design that meets your customers needs you will not only lose existing customers you will lose potential new customers.

[finerpeter]

Very well said Ralph.