X-Cart forums

[necroflux]

Originally Posted by verbic

Wow! Situation came to the boiling point here. We will try to clarify situation as the whole thread seem to be a sequence of misunderstandings.

Appreciate you coming to clear things up, and please stick around/answer questions often as this is a confusing and very serious matter.

Originally Posted by verbic

Most of merchants here believe that they have to implement X-Payments or similar solution in their store by July if they are using background payment gateways such as Authorize.net AIM.

But, they don't have to!

Merchants may have to use PA-DSS certified solution (e.g. X-Payments) only if they store credit card information on site.

That flies in the face of just about everything I've read about PA-DSS - including the following excerpt from page 5 of the "PCI PA-DSS Requirements and Security Assessment Procedures v.1.2.1" at https://www.pcisecuritystandards.org/pdfs/pci_pa_dss.pdf"

The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data as part of authorization or settlement, where these payment applications are sold, distributed, or licensed to third parties.

Am I reading this incorrectly?

[geckoday]

Originally Posted by verbic

Wow! Situation came to the boiling point here. We will try to clarify situation as the whole thread seem to be a sequence of misunderstandings.

Most of merchants here believe that they have to implement X-Payments or similar solution in their store by July if they are using background payment gateways such as Authorize.net AIM.

But, they don't have to!

Merchants may have to use PA-DSS certified solution (e.g. X-Payments) only if they store credit card information on site. In this case they have to submit the most strict Self Assessment Questionnaire type D (https://www.pcisecuritystandards.org/pdfs/pci_saq_d.pdf), which also applies to banks, payment gateways etc. Conforming SAQ D is a tough task and X-Payments implements a number of security measures that make the compliance much easier.

The typical user of background payment gateways do not store CC data on site therefore they have to fill Self Assessment Questionnaire type C (https://www.pcisecuritystandards.org/pdfs/pci_saq_c.pdf) which is much easier to conform:
Basically you need to follow simple PCI-DSS implementation guide published at our help portal: http://help.qtmsoft.com/index.php?title=X-Cart:PCI-DSS_implementation_guide
It explains how to disable storing CC numbers in X-Cart database (which is actually X-Cart default behavior).

So the conclusion is: if you do not store CC information on site then X-Cart should not prevent you becoming PCI-DSS compliant. However you need to remember that you also have to apply additional security measures not related to shopping cart software like anti-virus software, employee related policies etc. For details see SAQ C: https://www.pcisecuritystandards.org/pdfs/pci_saq_c.pdf


I believe that the situation became more transparent now. If you have other PCI-DSS related questions, please post them here.

It appears you are confusing PCI-DSS compliance with the VISA PA-DSS mandate. Given that you are the Qualiteam CIO and you are this confused about the VISA requirement at this late stage its no wonder you've been developing a solution that doesn't meet your customers needs.

According to the VISA PA-DSS 7/1/2010 mandate :
"Acquirers must ensure their merchants, VNPs and agents use only PA-DSS compliant applications"

It says nothing about it applying only if you store credit card numbers. PA-DSS applies if you store, process OR transmit credit card numbers. The emphasis is on the OR. All of the background payment methods transmit credit card numbers therefore they must be PA-DSS certified by 7/1/2010 or merchants can't use them if they accept VISA cards. AFAIK this is a US merchant only mandate at this time with other countries to follow over the next couple of years.

See the VISA page on the PA-DSS mandate.

[ManFromDet]

I've been using X-cart for several years (since 2003) and very much appreciate the software, short of this whole PA-DSS issue. Because QT hasn't been very clear about resolving PA-DSS, and the urgency just wasn’t there, I've since moved my web store to a competitor that is PA-DSS certified. (I made this move late last year.)

Once X-payments has been certified, and is considered a reliable, "bug-free" solution by the forum participants, I'd like to come back to X-cart and continue to use the platform. I've tried other solutions and believe X-cart is the most full featured cart out there.

I've been reading these forums for months, anticipating making the switch back to X-cart, but the responses from QT regarding PA-DSS have been distressing. There doesn't seem to be a unified understanding of PA-DSS amongst QT, and QT doesn’t seem to be taking the matter very seriously. The most recent posts in this thread are just the latest examples.

I’m confident I represent a significant amount of X-cart’s customers. At least I’m willing to come back and give X-cart another try – once this issue has been resolved to the satisfaction of X-cart’s core users – the forum participants. How many other vendors like me have just moved on and won’t be back?

If QT doesn’t get PA-DSS right soon, this will hurt everyone involved – possibly beyond repair. Software is only as good as the trust, reputation, and support of the provider.

[balinor]

Unbelievable. We have been talking about this for MONTHS and now you tell us that you don't even understand the guidelines? How can we expect you to develop a compliant system when you don't even understand the guidelines? I'll make it simple for you:

ANY online store using a background payment gateway (auth.net, Payflow Pro, etc) needs to use a PA-DSS compliant piece of software to transmit credit card data.

X-Payments needs to make this happen for any 4.x cart using a payment gateway that does not send the customer to an external site to process the card. And just to reiterate, NO ONE WANTS TO SEND THEIR CUSTOMERS TO AN EXTERNAL SITE TO PROCESS CARDS!

Now do you see why it is so important that this gets done YESTERDAY?

[bigredseo]

WOW. No wonder we're getting complaints from our users and questions on where to get an alternate cart. There is a mad scramble going no now to be compliant, and other carts are already there (and beyond with newer releases etc). This is a sad sad day for X-Cart and the developers as it's just one more nail in the coffin of the software and the choices for users to go to alternate shopping carts.

This needs to get in gear and be in production already!

[BritSteve]

Slightly off topic here, but if you take credit card orders by phone, fax or mail, then you fall into the scope of SAQ-D as you have the card numbers in your possession on paper.

Steve

[FiberGuy]

Originally Posted by verbic

Wow! Situation came to the boiling point here. We will try to clarify situation as the whole thread seem to be a sequence of misunderstandings.

Most of merchants here believe that they have to implement X-Payments or similar solution in their store by July if they are using background payment gateways such as Authorize.net AIM.

But, they don't have to!

Merchants may have to use PA-DSS certified solution (e.g. X-Payments) only if they store credit card information on site. In this case they have to submit the most strict Self Assessment Questionnaire type D (https://www.pcisecuritystandards.org/pdfs/pci_saq_d.pdf), which also applies to banks, payment gateways etc. Conforming SAQ D is a tough task and X-Payments implements a number of security measures that make the compliance much easier.

The typical user of background payment gateways do not store CC data on site therefore they have to fill Self Assessment Questionnaire type C (https://www.pcisecuritystandards.org/pdfs/pci_saq_c.pdf) which is much easier to conform:
Basically you need to follow simple PCI-DSS implementation guide published at our help portal: http://help.qtmsoft.com/index.php?title=X-Cart:PCI-DSS_implementation_guide
It explains how to disable storing CC numbers in X-Cart database (which is actually X-Cart default behavior).

So the conclusion is: if you do not store CC information on site then X-Cart should not prevent you becoming PCI-DSS compliant. However you need to remember that you also have to apply additional security measures not related to shopping cart software like anti-virus software, employee related policies etc. For details see SAQ C: https://www.pcisecuritystandards.org/pdfs/pci_saq_c.pdf


I believe that the situation became more transparent now. If you have other PCI-DSS related questions, please post them here.

I'm at a loss for words.

[geckoday]

Originally Posted by BritSteve

Slightly off topic here, but if you take credit card orders by phone, fax or mail, then you fall into the scope of SAQ-D as you have the card numbers in your possession on paper.

Steve

No, only electronic storage will push you to SAQ-D. You can qualify for SAQ C with paper storage of card numbers. In fact, the subtitle of SAQ C is "Payment Application Connected to Internet, No Electronic Cardholder Data Storage". The eligibility to complete SAQ C states "If Merchant does store cardholder data, such data is only in paper reports or copies of paper receipts and is not received electronically". In talking with QSA's, electronically received does not apply to telephone or fax - it only applies to computer received data. If you use a fax to email service instead of a standard fax machine then you will be pushed to SAQ D depending on how your email is implemented.

Edit: You may be thinking of the case when you use a hosted payment page for SAQ A eligibility. Orders by phone, fax or email where you enter card numbers into your gateway web site will kill your SAQ A eligibility. Its somewhat debatable but most I have heard that most acquirers agree it will push you to SAQ C, not SAQ D.

[necroflux]

Okay, so now that you've been exposed as being clueless as to the reality of the situation, can we have some candid, honest, realistic responses from Qualiteam? Can we get someone from Qualiteam to definitely say one of the following:

"Oh, wow, I can't believe we didn't know that! Okay, sure, we're going to get out X-Payment module out for all 4.x carts within a month to accommodate the vast majority of our current customer base."

"Oh wow, I can't believe we didn't know that! Unfortunately we don't really have the time/organizational skills/manpower/ability to get this finished in time for you all, so you'd best start working on plan B while you still have time."

No more BS Qualiteam.

[Steel]

Hello Ralph,

I have a couple questions for you. Do you know if the following 4.3 (and 4.2?) features are required to be compliant, and if so, will these requirements still be necessary with off-site processing? If so, and Qualiteam (or a 3rd party) does not plan on developing these features for prior versions, then we need to get on with 4.3 and/or other options.

PCI DSS compliance options

• Number of failed login attempts after which a user account must be suspended: The number of login attempts that a user is allowed to make using an incorrect password before X-Cart automatically suspends their account. For compliance with PCI Data Security Standard, set this value to 6.
• Lockout duration in minutes (Leave empty if you do not want to automatically re-enable automatically suspended users): The time period for which a user must remain suspended after having been automatically suspended by the system after a number of failed login attempts. For compliance with PCI Data Security Standard, set this value to 30 minutes or leave the field empty.
• Number of days of inactivity after which an administrator account must be suspended (Set to 0 or leave empty if you do not wish to suspend unused administrator accounts): The number of days that an administrator account may remain inactive before getting automatically suspended by X-Cart. For compliance with PCI Data Security Standard, set this value to 90 days.
• Use password strength check: This option allows you to enable password strength check for passwords created by the users of your store. If this option is enabled, every time a user creates a new password for their account, X-Cart will perform a check to ensure that this password contains both numeric and alphabetic symbols and is no less than 7 symbols in length. If this option is disabled, no such check will be performed. For compliance with PCI Data Security Standard, enable this option.
• Number of days after which non-customer users must be requested to change their password: The number of days since the user's most recent login after which X-Cart must request the user to change their password. This setting is relevant only for non-customer users (administrators, providers). For compliance with PCI Data Security Standard, set this value to 90 days.
• Do not allow a user to submit a new password that is the same as any of the last four passwords they have used: This option helps you ensure that users who are requested to change their password will change their password to something new (not a password they have already used). For compliance with PCI Data Security Standard, enable this option.

http://help.qtmsoft.com/index.php?title=X-Cart:Security_Options

Thanks