Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Yes, your host is in the tar pit as service providers are only eligible for SAQ D. But that only applies to the services they provide. What you do in your domain on a shared host falls under your PCI assessment which would still be SAQ C. As part of your processes required by SAQ C you must monitor your hosts PCI-DSS compliance. This can mean either your host doing their own PCI-DSS assessment and giving you a copy or you asking them questions to establish their PCI compliance as part of your annual filling out of your SAQ. If you're hosting with a quality host then they shouldn't have a problem with meeting the PCI-DSS requirements.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

This has generated a few thoughts and requests on the X-Payments implementation.:

1. It was mentioned that X-Payments would serve up its own payment page which would mess up a good one page checkout. This isn't required to properly separate out the payment module from the core. Take a look at the Transparent Redirect method Braintree talks about for their gateway (rebranded Network Merchants, Inc. gateway). X-Payments could work the same way. The payment form on the one page checkout can post to the X-Payments module which then redirects back to the core X-Cart receipt page. Simple and makes the breaking out of X-Payments transparent. I do this today with the Network Merchants gateway to completely remove my web server from PCI scope.

2. If you decide to follow my suggestion in #1 above, why not generically support any browser redirect gateway API? USAePay, Network Merchants and others support this type of API and it has the HUGE advantage of taking your web server completely out of scope for PCI-DSS while keeping it transparent to the customer (i.e. no gateway hosted payment page driving customers away). I modified X-Cart to support the Network Merchants browser redirect API and it works great. And it looks no different to the customer than when I was using Authorize.Net AIM. The idea here is the X-Cart core will allow you to choose USAePay browser redirect, Network Merchants browser redirect, etc or X-Payments. You choose X-Payments for gateways like Authorize.Net AIM where payment data will post to your server.

3. Gateway vaults. Many of us use other backend systems to handle order management. Often we need to charge additional amounts to a customer card for upgrades to shipping, add-ons to an order or reorders over the phone. Some gateways, like Network Merchants, allow referencing a prior transaction ID to create a new transaction. But most, like the ever popular Authorize.Net, don't. More common are "vaults" (Authorize.Net CIM for example) to store all of your customer information including payment information that allow you to reuse the payment information to create new transactions. You separately submit the payment transaction and a transaction to store the information in the vault. Some allow combining the two transactions but it still requires adding additional information to the payment transaction. To eliminate storing card numbers and passing them to the backend systems X-Cart needs to have an option to store the payment information in a gateway vault and store the vault id information in X-Cart so exports to backend systems have the data they need to charge additional amounts to cards.

4. The ubiquitous Authorize.Net. Yup, its the big boy out there. So much so that many competing gateways (Network Merchants, CDG Commerce Quantum, etc.) offer Authorize.Net emulation. The problem is X-Cart has the Authorize.Net URL hard-coded. How about making that URL a configuration parameter in X-Payments?

5. Network Merchants Inc. (NMI) gateway. If you haven't figured it out by now I'm a big fan of the NMI gateway :D. You may not have heard of it before because they don't offer it directly. They specialize in allowing merchant service providers to rebrand their gateway with the MSP's own name. I use Network Merchants through my card processor Alpha Card Services. They call their gateway Alpha Card Gateway but its really NMI. Same with Braintree and a whole bunch more. So how about supporting it, particularly the Transparent/Browser Redirect API. I really love having my web server out of scope for PCI compliance and would love it more if it was supported by X-Cart. I'd be happy to send you my code to jump start it.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

This whole thing is doing my head in, I can't understand why qualiteam are not making this a simple thing for us, at the end fo the day if you make ecommerce software it's your job to know and help customers be able to implement this with ease no?.

Does anyone know of any other shopping cart systems which are already pci-dss compliant please?

I think it's time to switch can't be doing with this.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Just a side note: there is no a trustworthy study confirming that putting all the fields on one page increases conversion. One-page checkout looks cool, but it doesn't guarantee that you will get more sales.


Are you sure that you remove your server from PCI scope? Yes, a browser submitting the data to your gateway is out of the scope. But behavior of the payment form is determined by X-Cart, not the browser. X-Cart is the party that decides where the credit card data will be send. And I guess it will be considered as a payment application that must be verified against PCI DSS requirements: just a small change in a template file of X-Cart will result in sending all credit cards though a hacker's proxy server.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

So its OK if you don't support it when there is no evidence either way and your customers want it?

The test for scope is: store, process or transmit cardholder data. My server does none of those so its out of scope. I asked quite a few questions of Braintree about this and they have had it approved by every QSA they have worked with as removing the server from PCI-DSS scope. By your logic even a merchant that uses Paypal or Authorize.Net SIM would have their server in scope because they could be hacked to send customers to a phishing site. Or even a site that says only call us with your credit card information could be hacked to add a card input page or link to a phishing site. Whether or not their are risks doesn't relate to scoping - there are always risks. Scoping just separates the high risk from the lower risk environments. Certainly no merchant should neglect securing their servers - in scope or out of scope.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Future X-Cart versions will feature one-step checkout provided it is not against PCI-DSS or PA-DSS. You can share your thoughts on this feature at ideas.x-cart.com


Yes, your server neither stores, nor processes, nor transmits CC data. However, X-Cart is a client-server software. And the payment page is a part of X-Cart. Unfortunately, PA-DSS doesn't give a clear answer on this question.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

You have multiple PA-DSS certified competitors with one-page checkout already. Google "PA-DSS one page checkout" and you'll find two of them on page 1.

PA-DSS is derived from PCI-DSS. Same test as PCI-DSS. From the PA-DSS Requirements and security document under Scope of PA-DSS:

"The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data"

You might want to read a good article on a trend of inflating PCI-DSS requirements, The QSA Connundrum. Its easy to expand what needs to be done saying its more secure. But ultimately, its the PCI-DSS or PA-DSS standard we are required to meet - everything else is optional. When selling software, that option should be the customers option not something forced by the software vendor.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

I've received an unofficial response from our PA-QSA (they haven't investigated it in details) that, although it is an insecure method of integration, it is not against PCI-DSS. So, most likely the next X-Payments version will support displaying of the payment form in X-Cart, not in X-Payments.

Thanks!

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Hello Steve,

1) 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? Answer: Could possibly qualify for C or D.
2) Same but processing cc data offsite on the payment gateway page? Answer: Could possibly qualify for A or C.
3) A store connected to POS for face-to-face transactions where cc is physically present at time of purchase? Answer: Could possibly qualify for B, C, or D.
You would need to supply additional information for your questions to be answered.

The PCI information is here: https://www.pcisecuritystandards.org/pdfs/pci_dss_saq_instr_guide.pdf

For simplification, I look at this as a process of elimination.

From the information Ralph has posted earlier in this thread, http://forum.x-cart.com/showpost.php?p=269106&postcount=37
http://forum.x-cart.com/showpost.php?p=273460&postcount=76
and other information I have read, I have concluded that SAQ Validation Type 5 / SAQ D is unrealistic for most businesses. If your company does not have someone that can comprehend and implement procedures/solutions for most of the questions asked in SAQ Validation Type 5 / SAQ D, then you could be looking at $10,000+/year for compliance. And, if you have staff that can comprehend and implement procedures/solutions, then perhaps you can get by on a budget of $1,000 to $10,000/year for compliance. So, for the majority, I suspect SAQ Validation Type 5 / SAQ D is out.

The other practical options for the small internet merchant, as Ralph stated, are SAQ A & C; and, unless you have a third party handle ALL creditcard data functions (internet, phone, fax, mail, and card present), SAQ A is also out.

So, our business will focus on what requirements/procedures we will need to change in order to meet SAQ Validation Type 4 / SAQ C. It would be helpful to have detailed discussions on the various options available for all aspects.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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.

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

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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

Summary So Far: X-Cart & PCI-DSS / PA-DSS compliance
 

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.



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

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]

Summary So Far: X-Cart & PCI-DSS / PA-DSS compliance
 

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


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?:wink:

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

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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?

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

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.

Re: Summary So Far: X-Cart & PCI-DSS / PA-DSS compliance
 

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

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

Re: Summary So Far: X-Cart & PCI-DSS / PA-DSS compliance
 

This is possible with some gateways. Again, USAePay and Network Merchants both will allow this. Both support a customer database/vault that can have card numbers stored as part of the checkout process. As I mentioned before, the payment form can be served from your server and post to the gateway servers taking your server out of scope for PCI compliance. Both gateways will allow you to add a "save this card for future use" checkbox to the payment form. Both gateways have a reporting/query API that allows you to find out what cards a customer has stored, the card type (VISA, MC, etc.) and the last 4 digits of the card number so you can present that to the customer to choose from. Both allow you to submit transactions using a token identifying the payment method instead of a credit card number.

The downside is that most gateways charge and extra monthly fee and per transaction charges for using their customer database/vault. I haven't priced USAePay but Network Merchants typically runs $10/month and $0.05 or $0.06 per vault transaction.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Hi Ralph, if you don't mind me asking this (also hope it is part of the thread scope): I use Quantum Gateway and they have this http://www.quantumgateway.com/developer.php (look at the Integration APIs/In Line Frame APIs), this is the documentation - http://www.quantumgateway.com/files/ILF_API.pdf. Is this what you are talking about? In your experience how customizable this is - will it look on the site as it is not part of the site (talking about position of elements, organization....)? I got a quote from QT for integration and just want to know if it's worth paying them to write the module.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

The real question is can a merchant who is SAQ C (which I suspect is the vast majority here) continue to use older versions of xcart or any version of Litecommerce, and if so under what circumstances (third party gateway, off site processing or direct on site processing)

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

I guess that this company can solve the PCI problem for xcart users in the USA

http://www.cresecure.com/

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

This is something I'd definitely consider for my stores... assuming that I'm able to keep the one page checkout and it doesn't interfere too much with the checkout process.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

well they have not developed it yet! they say "coming soon" but I note that xcart is at the top of their list.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Isn't this what x-payments is going to do basically.

Hope it is ready soon.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

It is almsot the same what X-Payments does:
http://www.cresecure.com/pages.php?CDpath=4

The only difference is that with X-Payments the payment form is on a merchant's website, not on our servers

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Hi Xplorer,

I am wondering if you have a list of payment gateways that x-payments will work for, allowing for integration of a one page checkout?
e.g. will worldpay or asiapay etc. allow for a one page checkout on the merchants server, using x-payments?

Which payment gateways will x-payment actually work for?

Thanks again, Asiaplay

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

This is similar to what I am doing but not the same. Instead of hosting the payment page on your server like I do with this solution Quantum hosts the payment page but it is loaded in an iframe on your checkout page. This can be done with most gateway hosted payment pages but Quantum has developed a specific API for doing it this way. They've added some better security over the typical hosted page and a session keep-alive to prevent timeouts during checkout. I don't have a Quantum account to play with to fully understand how integrated it can look but is sounds like it should end up pretty transparent. As long as the Quantum page can be stripped down to just the entry fields for the card information the iframe will look just like any other part of your page. I'd ask Quantum for a demo site or another customers site to look at before you pony up for it.

I find hosting the payment form on my server and posting to the gateway cleaner. The iframe approach adds some overhead and some people have an aversion to iframing things on a page.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Thank you for looking at this Ralph. I already have a quote form QT for integration, good advise to ask Quantum for a demo page, I will. Will this integration take the store out of the PCI-DSS / PA-DSS scope?

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Not exactly. It looks like their templating system is pretty sweet at least from the marketing material. You setup a payment page on your server using your standard site template but missing the payment fields. They suck it into their server and plug in the payment fields then serve it up from their servers.

But overall I agree. Its not all that much better than just using Authorize.Net SIM or the like. I don't think I would put another server layer between my checkout and the bank and I don't want somebody elses URL to show up to my customers.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Yes it will remove it from PCI-DSS scope and X-Cart will not be the payment application so there will be no need for it to be PA-DSS compliant. The iframe is like a mini browser within your page. The customers browser will contact the Quantum server to get the payment fields page and load it into the iframe on your page. When the customer enters the card information it will post directly to the Quantum server keeping your server totally out of PCI scope.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Sure. You've just got to remove X-Cart as the payment application. This can be done on any version of X-Cart by using a gateway hosted payment page (Authorize.Net SIM, Paypal Payflow Link, etc.). This will also remove your server from PCI scope and depending on your business model this might even move you down to SAQ A. If you don't like that approach you could have a one-off payment module written just for you to use a fully integrated API (Authorize.Net AIM, Paypal Payflow Pro, etc.). A one-off module isn't subject to PA-DSS and would just be part of your normal PCI-DSS assessment. The only problem with that might be your card processor won't like it and still insist you use a PA-DSS certified shopping cart even though its technically not required.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Thank you Ralph. This is something to consider then. Will save a lot of headache

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Interesting article on One Page Checkout...

http://www.getelastic.com/single-vs-two-page-checkout/

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Xplorer: Is the X-Payments module currently scheduled to be released together with the Xcart 4.4 some time in March/April timeframe? Or should the question be......Are you still releasing Xcart 4.4.x? Or is it going straight from 4.3.x to the new V5.0 instead? Just need some clarification so we can do some planning internally. Thank you!

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Hi!

1. Most likely we will release 4.4

2. X-Payments release is not tied to 4.4. Its release date depends on results of beta testing (will launch soon) and on results of PA-DSS certification

3. We plan to support the following payment methods in X-Payments v1.0:

• ANZ eGate - Virtual Payment Client (merchant hosted)
• Authorize.Net - Advanced Integration Method
• Beanstream - Process Transaction API
• Global Gateway - Direct model
• BluePay
• Caledon - Real-time interface
• DIBS - API integration
• DirectOne - Direct interface
• ECHOnline
• ePDQ - MPI XML
• eProcessing Network - Transparent Database Engine
• eSec - Web Direct Model
• eSelect - DirectPost
• eWay - Realtime Payments XML
• GoEmerchant - XML Gateway API
• HSBC Secure ePayments - API integration
• Innovative Gateway - PHP Connection
• iTransact - XML connection method
• Global Gateway - API (North America)
• Global Gateway - API (EMEA)
• Netbilling gateway - Direct Mode 3.1
• Netregistry eCommerce Gateway - HTTPS method
• Ogone e-Commerce - DirectLink integration
• PayPal - Website Payments Pro
• PayPal - Website Payments Pro Payflow Edition
• PayPal - Payflow Pro
• WebXpress - XML method
• Sage Pay - Direct protocol
• PSIGate - XML API
• Quantum Gateway - Transparent QGWdatabase Engine
• SecurePay - Non-recurring Interface
• SkipJack
• USA ePay - CGI Transaction Gateway API
• Virtual Merchant - Merchant Provided Form
• CyberSource - SOAP Toolkit API
• Manual credit card processing

4. X-Payments v1.0 requires the payment form to be displayed by X-Payments (on your domain) and doesn't allow the payment form to be integrated into a checkout page displayed by a shopping cart system. We will check (when will be certifying X-Payments by a PA-QSA) whether it is not against PCI DSS, and perhaps future X-Payments versions will support this feature.

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

Is xcart 4.4 from 4.3 going to be just a simple upgrade or will it require a whole nother redesign?

Re: X-Cart and PCI-DSS / PA-DSS compliance
 

We use Streamline & SagePay Direct.

We've been told that as we're not storing any Card Details at all we DON'T need a Server Scan & only have to fill in the PCI-DSS Form "C". Even though we're on Shared Hosting.

So I'm sat here thinking "Do we even need the X-Payments Addon"?