[Jarron]

Hi All,

I am breaking this over two posts - apologies for the length - but I very much hope worth the read.


A) Introduction
I am a loyal XCart customer, trying to decide on a PCI-DSS/PA-DSS compliance strategy (henceforth "Compliance"). XCart has enabled my business and I have no business with out it. My heartfelt thanks to the XCart team for that.

Sadly however, the Compliance debate in these forums is scaring me. What is the best strategy for a modified 4.1.x user like myself? (Does that profile put me in the majority here?).

Should I:

1. Upgrade to 4.1.12, then to 4.2 (I believe a fairly manual/painful upgrade path is offered in the Support area), then upgrade to 4.3/4.4 plus X-Payments?
2. Stay with 4.1.12 and modify it to work with X-Payments?
3. Wait (nervously) for 5.0 and hope it arrives on time and is useable/stable before July?
4. Switch to a Payment Gateway that takes customers away from my site for the Payment Form?
5. Or bite-the-bullet and switch Carts (with all the tremendous pain that this involves)?
6. Something else?

I have scoured these forums and the web, waited eagerly on XCart delivery announcements, and reviewed my own resources and timelines.

This is my business, my livelihood, my family's well being. With only 6 months to go, I consider that I have reached the minimum responsible window to make my decision.

The following is my interpretation of the main issues and my open questions. I am trying to write a definitive post that, along with the responses to it, will help myself and others to decide on strategies 1-6.

Caveat: Before anyone gets all excited:
a. I am not a Compliance guru and I have frankly become a bit confused with all of the requirements. There seems to have been several versions of the Compliance rules over time and even the latest versions are open to a degree of interpretation.
b. Some of the assertions below are hotly debated in these forums (particularly the XCart team's assumptions). Below represents my understanding on balance after reading all points of view.
c. I AM NOT engaging in any bashing of the XCart team here. XCart has served me well until now, I hope that will continue.

B) An Enlightening Thread
I have been following the thread here (http://forum.x-cart.com/showthread.php?t=51228&page=2). That thread:

1. Started by announcing XCart v4.4; which
2. Received a lot of criticism (ie. pls focus on Compliance & v5.0 instead of another 4.x release); which lead to
3. A heated discussion on the suggested shortcomings of XCart's upcoming X-Payments solution; and
4. XCart suggesting that it may reconsider and not release 4.4 afer all; and
5. XCart submitting a final post and promtly closing the thread.

RRF even pitched in to the discussion at one point and his views on the product direction were questioned quite assertively. Have a read, for me it was the most enlightening discussion on XCart's answer to Compliance so far.

That post prompted me to seek clarity here.


C) What We Want
I believe that most of us want a Compliance solution that:

1. Allows customers to stay on our own website (or the appearance thereof) when entering their Credit Card details
2. Arrives to a clearly articulated Release cycle (with actual delivery dates being articulated and met)
3. Allows us to use our existing *single* Server (whether dedicated, VPS or shared) with no need to invest in an additional Server
4. Is compatible with existing supported XCart releases - either out-of-the-box, or, understandably, with a small amount of well documented customisation.

In addition, I believe that some of us want a Compliance solution that:

1. Allows us to use our existing Payment Gateway, even if it is not on the X-Payments list of supported gateways (I use PayDollar, probably the biggest Gateway in Asia these days). If this requires custom modification, that's OK, just so long as it is possible in the X-Payments design.
2. Allows us to offer our customers Payment Methods that require credit card storage (ie. recurring subscription, mail/phone order, or just not having to enter redit card details on every purchase). All this whilst maintaining the requirement to keep customers on our own Payments page (I know, I know - just read on).

D) XCart's Key Points
The XCart team have suggested:

1. They can not build a Compliance solution that is part of core XCart because the Compliance rules would then require all of your mods and every release/patch to endure expensive Compliance audits as well. ie. X-Payments must be a stand alone service on a separate server.
2. The X-Payments module is a compromise that allows <v5.0 users to achieve Compliance without having to vastly alter their site or worry about the viability/timing of v5.0
3. If we don't like solutions involving X-Payments or waiting for v5.0, then the easiest solution is to switch to a Compliant Payment Gateway that allows customers to be diverted to the Gateway provider's site to capture credit card numbers.
4. Versions from 4.1.x through 4.3/4.4 can all use X-Payments. However, the language in the following quotation (from the post referenced above) uses the words "may" and "most likely" when referring to compatability with 4.1.x and 4.2. This requires some clarification (italics added by myself):

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.

E) Some Realisations
All of the above brought home some realities to me:

Relisation 1 - I can not bet my Business in v5.0
Version 5.0 is not due out until mid 2010. It has been delayed already and XCart have not been confident enough about it's progress to provide a hard delivery date. But July 2010 is the cut off date for Compliance. Realistically, this means that none of us can confidently put our hopes on v5.0 for meeting the deadline because:

1. It would be the exception to the norm if v5.0 was stable on its release date. I know XCart have improved their QA processes (read that in some post from XCart) but this is first-release software and, well, let's leave it at that....
2. Most of us have custom or 3rd party mods installed. We need time to re-integrate and test them. As I understand it, the release date doesn't allow enough time.

So I must dismiss v5.0 for Compliance on day one.

Realisation 2 - X-Payments Requires A 2nd Server
In the post I referenced above, it was suggested that the X-Payments solution needs to run on a separate server (not your X-Cart Server) so as to satisfy the Compliance requirement of being a distinct system to XCart.

So you need to rent another server from your hosting provider ($$$) to achieve Compliance using X-Payments. There did seem to be debate around this point, but if this is the case then the value-for-money argument for investing in XCart just took a hit.

Realisation 3 - X-Payments Diverts Customers Away From XCart
In the post I referenced above, it was also suggested that the design of X-Payments results in customers being visibly diverted away from XCart, to an X-Payments server, and then back to XCart. So, to a customer, it's not that different to being sent off to a PayPal or other third party server.

That is, the page diverts to the X-Payments server, they enter their details, the server tells them to wait, they wait, if all goes well they get diverted back to XCart.

It does seem that the template system that comes with X-Payments allows you to customise the look and feel of the Payment Screen (probably more so than PayPal etc allow). But, I/we just don't want people leaving XCart because they all-too-often get annoyed and walk away. Customised look-and-feel or not, customers are fickle and diversions to another site get noticed, make true one-page-checkout impossible, and lead to abandoned carts (I remember a terrific post in these forums by Balinor that discusses this issue).

[To Be Continued in next post]