X-Cart forums

[cflsystems]

More clear Steel thanks. I guess I will have to read more on the subject as I was getting confusing reports - from one place D, from another place C.

[geckoday]

Originally Posted by cflsystems

Can someone (Ralph Day or someone else with good understanding of this) explain which SAQ will apply for most xcart owners - A,B,C, or D - as I am getting really confused by that whole thing. For example an ecommerce store that sells only online and has only one server with only xcart on it and accepts cc payments on that server without storing any cc data?

Probably SAQ C. You should read all of the requirements for SAQ C as Steel posted but the one that most likely could push you to SAQ D is the connection to other systems in the merchant environment. I've heard varying opinions from QSA's on what that means but I believe that for the typical X-Cart user that is administering their cart via HTTPS the connection to other systems doesn't apply so you would be eligible for SAQ C.

Originally Posted by cflsystems

Or same but processing cc data offsite on the payment gateway page?

Probably SAQ A but almost equally as likely SAQ C. The issue many merchants run into with qualifying for SAQ A is handling phone orders and entering credit card numbers into the gateway virtual terminal from their PC. Suddenly, you are not completely outsourced and that pushes you to SAQ C. OTOH, I hear of acquirers who are OK with SAQ A even if you enter credit card numbers into the gateway from your PC. Ultimately its up to the acquirer to approve which SAQ you use so if you tell them what you are doing and they say SAQ A is OK then you're good with SAQ A. Just make sure you document their answer.

Originally Posted by cflsystems

How about a store connected to POS for face-to-face transactions where cc is physically present at time of purchase?

This is pretty tricky depending on exactly what you mean. If your POS system is sending card numbers to your X-Cart store you're into SAQ D for sure. If the X-Cart store doesn't store card numbers and its just sending inventory changes to X-Cart you get into a grey area around what exactly connected means for SAQ C again. If the inventory changes are sent via HTTPS with login/password authentication and that's all that is done I personally would argue for SAQ C but your acquirer might have different views. No possibility for SAQ A or B because it isn't outsourced and you have both face-to-face and internet.

[cflsystems]

Thank you Ralph. Nothing in this life is meant to be easy I guess

[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]

[Jarron]

[Continued from pevious post]

Realisation 4 - X-Payments Will Not Support My Gateway on Release
My gateway provider (www.paydollar.com) is not on the X-Payments supported gateway list. I asked XCart if I could get them added but received a "maybe later" styled answer. (XCart built the custom mod in my current XCart to connect with PayDollar...).

So now my XCart 4.1.x options are:

1. Change over to an X-Payments supported gateway (but I feel that you really need to be with AsiaPay if you're serious about HK/China - a topic for a different thread); OR
2. Accept a Payment Gateway provider that diverts customers to it's own Payment Form.

Realisation 5 - Upgrading to XCart 4.3 Is a Big Deal
There are posts all through the forums on how hard it is to move to XCart 4.2/3 from 4.1.x. I won't repeat all of that here but the key takeaways for me were:

1. At the very least, all of my Smarty templates need to be changed due to the eradication of tables for positioning
2. My many, many custom mods will need a lot of refactoring/reintegration
3. Many feel that the 4.2 and (to a lesser extent) 4.3 releases are still buggy
4. There may, or may not, be another 4.4 release that I would need to upgrade to in order to avoid any outstanding issues with 4.3. Or am I exagerating here - has 4.3 been declared a Stable release by XCart and does the forum agree?

Given these risks, the competing demands on business resources, and just-around-the-corner-super-version-5.0 release, it is hard to justify an effort to upgrade to version 4.2/3/4 (/5/6/7?).

Realisation 6 - Other Carts Are Already Compliant
I didn't know this until I read the post referenced above. So there is Choice and we have 6 months to get it working.

But for many of us, this would be very painful given the degree to which we have integrated XCart into our business processes and technology stack.

Realisation 7 - Phone Orders etc - Am I screwed anyway?
7.1 Phone Orders
This is probably not an X-Payments issue so much as an issue of how to interpret the Compliance rules.

What if I want to take an order by Phone/Mail/Fax/Email? I'm thinking that with all of these, the moment I have a record of the customer's details in my posession (on paper or email) then I'm screwed, right?

In terms of processing the Payment I actually have a choice. I can either:

• Use my gateway provider's already Compliant web site to enter the Credit Card details and process payment (XCart & X-Payments are not in the loop); or
• Place the order in XCart on behalf of my customer (XCart & X-Payment are in the loop).

But is the method of processing above even the issue? Or is it the fact that I have that paper/email record that defines my Compliance requirements?

7.2 Subscriptions & "Remembered" Credit Card Details
My customers have been complaining that they don't want to enter their credit card details every time they buy from me. I explain the security advantages of me not storing their credit card details and they simply respond that they are confident the bank will sort them out if they are subject to credit card fraud.

Now, whether that's correct or not, they want maximum convenience at checkout.

But this means storing credit card details somewhere. So how do I simultaneously:

• Avoid forcing them to login to a 3rd party gateway (that stores their credit card details instead of me) at checkout; and
• Store their credit card details for convenience at checkout; and
• The clincher, avoid a Compliance Audit and all the hassle that goes with it?

Any ideas gang?

I guess the related question is, does/can X-Payments store credit card details in a compliant manner? Or (as I suspect) is X-Payments a pure gateway with no persistence?

Realisation 8 - A Possible Solution?
In the above referenced post, Vyacheslav Petrov from XCart gave me hope when he wrote:

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

Does this mean I can:

• Change to a Payment Gateway with a service as above; and
• Embed the Form into my own Checkout Page (as <div>gateway form here</div> rather than as a whole different look-and-feel page); and
• Side-step the X-Payments etc requirement altogether?

Yes, I'd rather not change gateways, but it's worth a look right?

So, which gateways offer this? Anyone got experience in this? Or is there a forum rule that stops us discussing gateway providers' offerings?


F) Open Questions
So all of the above leaves me with the following open questions that I hope XCart plus this fantastic user base can help me with.

I suspect/hope that the answers to these questions will help many in the forum!

F.1) Questions for the XCart Team

1. What is the actual hard delivery date schedule for v5.0?
2. Will 4.4 be released or not? If so, what is it's hard delivery date?
3. Will version 4.2 definitely work with X-Payments after modification?
4. Will version 4.1.x definitely work with X-Payments after modification?
5. Can we get additional Payment Gateways added to X-Payments prior to July? Does the answer change if we're willing to pay?
6. Does/can X-Payments store credit card details in a compliant manner? Or (as I suspect) is X-Payments a pure gateway with no persistence?

F.2) Questions for XCart & the Forum

1. Has version 4.3 been declared a Stable release by XCart? If so, does the forum/user base agree that it is Stable?
2. If using X-Payments, do we really need to install X-Payments on a separate/2nd server to be Compliant?
3. 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?
4. 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?
5. For customers who wish to avoid entering therir credit card details on every transaction: I doubt it but I'll ask: Is it possible to simultaneously:

• Avoid login to a 3rd party gateway (that stores the customer's credit card details instead of me) at checkout; and
• Store the customer's credit card details for convenience at checkout; and
• The clincher, avoid a Compliance Audit and all the hassle that goes with it?

----
OK - thx to all who have read this tome. Greatly looking forward to the responses.

thx,
js

[bigredseo]

Jarron, what a wealth of information and questions! Great job documenting it all. I really think that these questions deserve their own thread rather than getting burried here in this PCI thread. Can forum admins move these to another NEW thread so we can follow along on this?

From a web hosts standpoint, we are seeing MOST people who install X-Cart using the 4.3 branch and really we're not seeing any complaints from users on it. I don't know if it's "stable" by forum standards, but definitely from our end we're not seeing half the questions or problems that people ran into in the 4.0 and 4.1 versions. It seems to play rather nice on the server from our end.

One question I wanted to throw in here was in regards to the F.2-2 part (using X-Payments on a 2nd server). Can someone clarify if this just means hosting it on an alternate SHARED account with a dedicated IP number, or if it requires it's own environment (VPS or Dedicated Server)? Even if it needed it's own Dedicated IP number that will mean TWO SSL certificates needed by store owners - one for their site (customer logins etc) and one for the Payment section which would be on a separate server/domain. So my question is does having X-Payments on a separate shared hosting account that ONLY runs X-payments satisfy PCI, or does it need to be on a VPS/Dedicated Server?

[kulture]

Great post. I use Litecommerce and am currently considered "PCI compliant" by my merchant service provider. Or at least by the auditors they have recommended. In my opinion the only real way to get a definitive answer for YOU is to ask your card provider what YOU have to do to satisfy them.

All that said, I consider version 5 a non starter. It has already slipped from its original delivery date; there is absolutely no information as to what is in it; there is no way I would go live on it in its first year.

Litecommerce is clearly no longer supported by Qualiteam (no meantion of it in the recent paypal pro changes for 3d secure). So I am moving cart and not to XCart.

Regarding gateways, I am looking at Sagepay Server which looks like it runs from an IFrame in my chosen new cart and thus is hosted on Sagepays server BUT looks like its your site.

[Swish]

Originally Posted by kulture

Great post. I use Litecommerce and am currently considered "PCI compliant" by my merchant service provider. Or at least by the auditors they have recommended. In my opinion the only real way to get a definitive answer for YOU is to ask your card provider what YOU have to do to satisfy them.

All that said, I consider version 5 a non starter. It has already slipped from its original delivery date; there is absolutely no information as to what is in it; there is no way I would go live on it in its first year.

Litecommerce is clearly no longer supported by Qualiteam (no meantion of it in the recent paypal pro changes for 3d secure). So I am moving cart and not to XCart.

Regarding gateways, I am looking at Sagepay Server which looks like it runs from an IFrame in my chosen new cart and thus is hosted on Sagepays server BUT looks like its your site.

I was thinking again over Christmas and as QT have pushed back x-cart 5.0 and have given no insight into it or some of the features to expect I'm again looking at competitors carts. QT, you need to show us what 5.0 is all about asap.

Kulture, I recently signed up with Sage pay as Worldpay are expensive. Sagepay were useless. They took two months to set my account up and it was full of bugs. I decided not to bother in the end and cancelled. They then tried to say I was contracted to pay them 3 months fee. Shit company.

[geckoday]

Originally Posted by handsonwebhosting

One question I wanted to throw in here was in regards to the F.2-2 part (using X-Payments on a 2nd server). Can someone clarify if this just means hosting it on an alternate SHARED account with a dedicated IP number, or if it requires it's own environment (VPS or Dedicated Server)? Even if it needed it's own Dedicated IP number that will mean TWO SSL certificates needed by store owners - one for their site (customer logins etc) and one for the Payment section which would be on a separate server/domain. So my question is does having X-Payments on a separate shared hosting account that ONLY runs X-payments satisfy PCI, or does it need to be on a VPS/Dedicated Server?

As with anything PCI there are no simple answers.

First off. X-Payments will not require a second server even though that is the way Qualiteam has designed/envisioned/promoted its use. I've probably contributed a bit to that misconception due to my vocal objections to how the design allowing it to run on a second server makes it an ugly bolt-on to the end of the checkout process instead of it being integrated into checkout. X-Payments can be installed into a folder within your X-Cart site and use your sites existing IP and SSL certificate. The downside to this is that your X-Cart server will be in PCI-DSS scope. For most of us level 3 or 4 merchants who are not storing credit card information and filling out SAQ C that shouldn't be a big deal - no worse than dealing with the X-Payments server being in scope. If you do store credit card information or are otherwise pushed to SAQ D having your X-Cart server in scope *might* not be something you want to do as any changes you make to the X-Cart server then would require all of the development process and associated documentation required by SAQ D. Qualiteam assumed we are all in the SAQ D boat and all didn't want to deal with the development process & documentation, hence the two server design. In reality, I think most of us are in the SAQ C boat and hence don't have the development process & documentation burden.

Ok, but what if you want to install X-Payments on a second server? A shared hosting account, VPS or dedicated server are all OK. If you are going to store credit card numbers whichever you choose must not have the database on the same server as X-Payments. The database server must be on another server that is not accessible from the internet. In addition, if you are using shared hosting and storing credit card numbers your shared host must meet the requirements in Appendix A of SAQ D - processes must run under merchants user account (no mod_php), access restrictions keeping everyone in their own environment, PCI required logging in place, processes in place for rapid forensic investigation of compromises.

[geckoday]

Wow, Jarron. Glad to see you taking this seriously. I'll answer what I can as I find time.

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.

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.