Upcoming X-Cart v 4.4.6 (now renamed to 4.5.0) & PCI-DSS requirements
 

Hello X-Carters,

We would like to inform you about major changes in upcoming X-Cart v 4.4.6 (to be released very soon, in a week or so):

1) Due to PCI-DSS requirements being enforced over last months we have to remove all background (aka "onsite" or "merchant hosted") credit card processing methods from core X-Cart package. See the list of removed methods below.

A merchant that need such credit card payment methods has to use a PA-DSS validated application like our X-Payments or go with "offsite" or "gateway hosted" methods.

2) No credit card data will be stored in X-Cart anymore (due to PCI-DSS requirements again).

3) USPS shipping calculator module will be completely revised and updated to meet the latest USPS APIs requirements.

4) Two new built-in skins.

You are welcome to ask any questions.

List of the credit card processing methods removed from X-Cart since v4.4.6 release:

* ANZ eGate - Merchant-Hosted (cc_anz_mh.php)
* AuthorizeNet - AIM (cc_authorizenet.php)
* Bean Stream (cc_bean.php)
* BluePay (cc_blue.php)
* Caledon (cc_caledon.php)
* CyberSource - SOAP Toolkit API (cc_csrc_soap.php)
* DIBS (cc_ideb.php)
* DirectOne - Direct Interface (cc_directone.php)
* ECHOnline (cc_echo.php)
* ePDQ - MPI XML (cc_epdq_xml.php)
* eProcessingNetwork - Transparent Database Engine (cc_eproc.php)
* eSec - Direct (cc_esec.php)
* eSec - ReDirect (cc_esecd.php)
* eSelect Plus - Direct Post (cc_eselect.php)
* eWAY Merchant Hosted Payment (cc_eway.php)
* First Data Global Gateway - LinkPoint (cc_linkpoint.php)
* GoEmerchant - EZ Payment Gateway Direct (cc_goem.php)
* GoEmerchant - XML Gateway API (cc_goem_xml.php)
* HeidelPay (cc_heidel.php)
* HSBC - XML API integration (cc_hsbc_xml.php)
* Innovative E-Commerce (cc_innec.php)
* iTransact (Process USA) - XML scheme (cc_processusa.php)
* Netbilling gateway - Direct (cc_netbilling.php)
* NetRegistry e-commerce (cc_nrecom.php)
* Ogone - Direct (cc_ogone.php)
* PayFlow - Pro (cc_payflow_pro.php)
* PayPal WPP Direct Payment (ps_paypal_pro_us.php and ps_paypal_pro_uk.php)
* PlugnPay - Remote Auth method (cc_plugnpaycom.php)
* PSiGate - XML Direct (cc_psigate_xml.php)
* RBS WorldPay - Global Gateway (cc_bibit.php)
* Sage Pay Go - Direct protocol (cc_protxdir.php)
* SecurePay - Non-Recurring Interface (cc_securepay.php)
* SkipJack (cc_skipjack.php)
* USA ePay (cc_usaepay.php)
* Virtual Merchant - Merchant Provided Form (cc_virtualmerchant.php)

============================================
FAQs (covering the major questions asked in this forum thread)
============================================

===
Q1:

If a store is not storing credit card information, why must it lose the ability to use Authorize.net AIM?

A1:

X-Cart is not PA-DSS verified application, unfortunately. So, in order to handle, process and transmit cardholder data THROUGH your cart (which X-Cart's Authorize.Net AIM payment module does), you need to use another PA-DSS verified software, even if you are not storing the CC info. Or you can still use Authorize.Net AIM in the following cases:

* via a PA-DSS verified application like X-Payments on top of X-Cart.
NOTE: The web-server environment which hosts X-Payments should be PCI-DSS compatible (you should ensure the hosting provider is PCI-DSS compatible).

* via PCI-DSS certified payment system like CRE Secure's Hosted Payment Page, thus outsourcing all cardholder data functions to third-party.

===
Q2:

I've got several sites that use AIM. What am I supposed to do now that all payment processor modules are being removed from X-Cart?

How do I upgrade them and still use authorize.net?

A2:

You can upgrade to 4.4.6, and use one of the possible solutions:

* Authorize.Net AIM via a PA-DSS verified application like X-Payments.
NOTE: The environment which hosts X-Payments should be PCI-DSS compatible.

* CRE Secure's Hosted Payment Page solution (PCI-DSS certified payment system) which support such payment gateways as Chase Paymentech, Authorize.net, PayPal Payflow PRO, PayPal Website Payments PRO, eProcessing Network, PayLeap, SkipJack, USAePay, FirstData.

* Authorize.Net SIM integrated into X-Cart.

===
Q3:

Does Qualiteam have any plans to release Authorize.Net DPM solution for X-Cart?

A3:

We are considering this option at the moment, but have not made a decision yet.

One of the reasons - different QSAs consider solutions like DPM differently, and it is not clear enough if the merchant using X-Cart + Auth.net DPM solution would need to go with completing:

* SAQ A - addressing requirements applicable to merchants who retain only paper reports or receipts with cardholder data, do not store cardholder data in electronic format and do not process or transmit any cardholder data on their systems or premises.

- OR -

* SAQ C - addressing requirements applicable to merchants who process cardholder data via payment applications connected to the Internet, but who do not store cardholder data on any computer system.

We would recommend to consult with your QSA or merchant account provider directly regarding the matter.

NOTE:SAQ C, in contrast to SAQ A, requires merchants to use Payment Applications validated according to PABP/PA-DSS.

===
Q4:

Is X-Payments a PA-DSS validated payment application? And what about X-Cart?

A4:

X-Payments is a PA-DSS validated payment application, but X-Cart is not.

So, in order to meet PCI-DSS merchants should:

1) Outsource all cardholder data processing from X-Cart to an external PCI-DSS compatible system, for example:

* "offsite" or "gateway hosted" payment solutions like Authorize.Net SIM, 2Checkout, PayPal, Checkout by Amazon, SagePay Go (Form integration), etc.
* CRE Secure's Hosted Payment Page PCI-DSS certified payment system
* PCI-DSS compatible hosting + X-Payments PA-DSS validated payment application

= OR =

2) Have their X-Cart application validated according to PA-DSS + have the X-Cart's hosting to be PCI-DSS compatible.

In fact, having the X-Cart software PA-DSS certified and validated is much expensive than the X-Payments's price. Please also note, one X-Payments license allows you to connect up to 10 online stores.

===
Q5:

How many online stores X-Payments installation can be connected to?

A5:

One X-Payments license/installation can be connected up to 10 online stores.

====
To be continued...

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Wow. The PCI Compliance issue is heating up. Sergey, do have any links or information about you comment that PCI compliance is now being "enforced"?
Thanks for keeping us informed.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

> The PCI Compliance issue is heating up. Sergey, do have any
> links or information about you comment that PCI compliance
> is now being "enforced"?

http://usa.visa.com/download/merchants/payment_application_security_mandates_regions.pdf

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

This is major change. Hopefully it will not break anything in XC when 4.4.6 is released. Just a suggestion:

Include a big red text across the screen upon install or upgrade to 4.4.6 that will warn about these changes even if you have to make it with an "agree" checkbox so no one can miss it. Don't count on XC users to read the change log or the forum.

Of course make it look nice and presentable :)

I know some will find it annoying (me too at some point) but better safe than sorry

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

It is indeed being enforced - I have had a number of people come to us who were being penalized $100+/month for non-compliance - and that is just the beginning. If you happen to get hacked and aren't compliant, you are in for a huge amount of liability.

Glad Qualiteam finally taking this matter seriously and not just throwing X-Payments at it. People need to stop storing CC info and using non-compliant carts - it is for the benefit of everyone.

Don't try to lie on your SAQ either, that's an even worse penalty :)

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Hello Sergey -

I have an x-cart instance that uses Authorize.net AIM + DPM which has been approved by a compliance officer at the bank being used. Is there any way for you to investigate Authorize.net AIM + DPM and allow it as a method in 4.4.6 if it meets requirements? It seems that you could get an independent opinion from your auditor about the viability of this method and include it or not.

---

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Dear Gabriel,

Actually, Advanced Integration Method (AIM) and Direct Post Method (DPM) are two different solutions. Please do not mix up these terms.

Authorize.Net Direct Post Method (DPM) is considered to be a solution that supports you to be PCI Compliant, as all Credit Card handling is done directly through Authorize.net, and no Credit Card data is handled/stored/processed on the merchant (X-Cart) server.

Please check the links below to learn how AIM and PDM solutions work:

* http://developer.authorize.net/api/howitworks/dpm
* http://developer.authorize.net/api/howitworks/aim

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Thanks Sergey. DPM and AIM seem to have enough commonality in their set up that when BCSE built their module to support DPM, they appear to have added it to the existing X-CART AIM module set up. We'll have to ask them the impact on their DPM mod with your removal of the support for the exiting AIM module.

Is there any plan at QT for future support of Authorize.net DPM and/or any other gateways who have a similar transparent redirect method, or will you be leaving that space to the 3rd party developers, and offer only x-payments for customers who require the payment page to remain at the shop's url?

---

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

I am sorry, but I don't get this. If a store is not storing credit card information, why must it lose the ability to use Authorizenet AIM? I can understand the denying of use to those storing for subscription payments or the like, but one-off transactions having to now use your $1000 x-payments is beyond possible for small stores. The other option use a butt-ugly payment processor like PayPal, which charges a lot per transaction does not offer any better solution.

Please tell me I am missing a better solution here.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Because X-Cart is not PA-DSS compliant - and as of last year you need to use a PA-DSS certified cart in order to process transactions THROUGH your cart (which AIM does) even if you are not storing the CC info. You can still use AIM, you just need to use X-Payments on top of X-Cart.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

I'm at loss here as well. I've got several sites that use AIM. What am I supposed to do now that all payment processor modules are being removed from X-Cart?

How do I upgrade them and still use authorize.net?

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

We'll be looking into a DPM solution for 4.4.6 and up just FYI. Email us if you are interested.

Thank you,

Carrie

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

You can always just upgrade to 4.4.5 and stay there. Get the upgrade kits now before they are gone. They can't remove the payment methods from an existing cart :)

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

What is the difference between the Authorize.net AIM and Braintree Payments? They sound about the same to me-- take payments on your site, store credit cards, etc.

Braintree is still working in v4.4.6, right?

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

[quote=BCSE]We'll be looking into a DPM solution for 4.4.6 and up just FYI. Contact us if you are interested.

Thank you,

Carrie[/quote
We've your products before. Please keep in touch.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Which probably means x-cart will never be certified, but LightweightCommerce will be. Why did you raise xPayments price so high? Was it because you knew we would have no choice but to pay it? Sounds like a no-win to me for the small business. $1200 per site for gateway. Sheesh.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

If BCSE can workout a solution (which I am anxious to see), why can't -xcart keep it as an option or x-cart license the plug-in for anyone that needs AIM? Just removing it completely seems like a draconian approach.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

I want an answer why x-payments is over twice the price as x-cart pro when they knew we did not really have much of a choice by threat of large fines if we did not use it.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

ended nowhere - http://forum.x-cart.com/showthread.php?t=62022&highlight=x-payments+price

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Because that would be against PA-DSS compliance regs - people would use it WITHOUT the DPM plug-in and be out of compliance. They would need to come up with a way to only enable it if the DPM plug-in is present.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Would the new version of BCSE DPM solution be PA-DSS certified? If not and we use it we can still be fined right? Sometimes I wish I could go back to when we hunted our own food and lived in huts. Why does x-carts home page say 100% pci-dss compliant if we have to go through all this?

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

The DPM module doesn't need to be certified - that's why it is such an elegant solution. You are technically entering the CC data directly into Auth.net, thus taking the cart out of the equation.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Dear Seyfin, could you please fill us in a little more about the USPS API changes. I found the following information below which to me implies that starting April 1st we will no longer be able to give real time rate quotes (domestic) without being on RateV4, and I'm confused about IntlRateV2. Will your upgrade be only for 4.4.6? Will there be a fix for previous x-cart versions? Is there a RateV3 and if so are we all fine? Please advise. Thank you!

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Then x-cart should offer a plug-in themselves for DPM. Just removing an option in return for a $1200 scare-tactic-laden option is wrong. When most people purchased x-cart, they did so with the advertised feature of having payment gateway options from Authorize.net. Furthermore, the customization options that x-cart offers made it seem like we could keep the nice clean behind-the-scenes payment. To remove that and force the polar opposite or a high-priced solution goes against what purchasing x-cart used to be all about. LightweightCommerce is going to be even more confining. Most people bought x-cart to be used as a storefront first and foremost. Removing critical major features in return for a you must buy x-payment or else mentality is getting old.

Despite past misgivings, I just had clientele purchase five new licenses of Pro. Now I am starting to wonder if that was the wrong thing to do. I wanted to keep a little faith, but this throws that faith all alway, almost as much as the switch to LiteCommerce as a core and product name.

I renew my request. I want a justification of the X-Payments price tag if they want any licenses from us or our clientele.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Unfortunately they don't have a choice ynotcreative, you can no longer use a non-compliant cart to process credit cards. If you don't want to comply, that is your right, but the $50,000 fine isn't a scare tactic, it is a reality of the new credit card processing age.

Just install 4.4.5 and you won't have to worry about this.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Because this is about principle. Yes, X-Cart could release a DPM solution, which someone said takes care of the issue elegantly. If BCSE or CFL could write a plug-in, why can't X-Cart?

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

How will using 4.4.5. fix the issue? The option for Authorize.net AIM is still there. I just updated to that version in my dev directory.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Because 4.4.5 still has the credit card processors - 4.4.6 will not.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

If you don't mind me asking, what are doing with your sites balinor?

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

I don't run any sites personally, but we've taken just about every approach with our clients - from DPM to External Gateways like PayPal and Auth.net SIM. Need to weigh the cost/benefit - you want the best solution for your customers that doesn't break the bank for you.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

We don't do any developing for other clients. We just use it for our own company's candle site. I don't want to have to switch to Authorize.net SIM, I set that up in my dev site to mess with and it looks awful. I like the idea of the DPM from BSCE but if I need to upgrade further to 4.4.6 for the USPS real-time shipping fix than I won't have access to the AIM version we currently use. I'm wondering if I can get just the USPS updated files from 4.4.6 and apply them to 4.4.5.??? I already have Paypal as a secondary payment method since so many people like it but don't want it to be the only option.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

I'm sure it will be possible to just upgrade the USPS portion.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

I still don't fully understand why everyone is saying that X-Payments would be the only approach to fixing this other the BCSE building a Authorize.NET module.

Does X-Cart's NEW Braintree Module (http://www.x-cart.com/braintree.html) not provide the same type PCI DSS Level 1 compliance that it needed? http://www.braintreepayments.com/services/pci-compliance

We use this and love it. You can't beat the technology of Braintree, $300-ish module cost, being able to store credit card information in their Vault feature. It's great.

A side not, I personally think that X-Cart's service is un-matched and their dedication to our stores success (including integrating Braintree) has been amazing-- from working late, to chatting via Skype.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

In my very limited sample - still about half of them are not being questioned or informed by their banks of the PCI requirements. To me that is even more scary. (The other half did warn of fines and actively provided information about correctly filling out the SAQ.) But the ones that are not pushing it, I suspect, will be the first to shift all the blame on the merchant if there is an incident of fraud. I do not think it is worth the risk of ignoring the requirement even if they are not aggressively enforcing - but the decision is with the merchant.

Regardless of enforcement by the banks, QT must consider the compliance requirements for those who are serious about adhering to the standards.

If having the non-compliant methods in the software makes X-Cart+X-Payments non compliant, then it has to be removed for the sake of all those who are shelling out large dollars for that solution. You can't just look at how it adversely impacts people who are ignoring compliance requirements, you have to see how it penalizes those who are required by their merchant accounts to be compliant. I think QT has no choice but to make decisions for that group of customers over those who are taking the chance of ignoring the requirements. If you've decided to risk ignoring the requirements, you may as well stick to 4.4.5 and earlier versions. I'd even suggest that QT should name this 4.5.0 as this is a significant change.

This news makes me a bit worried that QT's QSA has advised them that all those methods need to be stripped out for an X-CART+X-Payments to be a valid, certified implementation. That might force an upgrade of current implementations of X-Payment if the rules are to be interpreted strictly - which could be costly. But all this continues to be confusing as X-Payments is what is listed as PCI-PA validated, not its implementation with X-CART. I thought that was outside the scope of QT since X-Payments is separate, but this news seems to bring it back in.

Hence, I continue to try and avoid the X-Payments route if possible. DPM is a nice way to do that for current users of AIM. I suspect for the DPM (or any other transparent redirect method), the solution will all have to be in one addon module. (Just as both BCSE and QT offer modules for BrainTree.) Then, we have something to show to the compliance officers at the banks to get approval. So - QT and/or BCSE could implement the entire DPM module, or maybe even find some way to cooperate with each other. Because this information is new, currently, it is in a limbo state because neither has fully committed to do it, although BCSE is investigating. I imagine they would need to see the 4.4.6 implementation first to gauge the obstacles, so I would not expect an answer until it is released. Hopefully they will resolve it so there is still a lower cost alternative (hopefully much less than the QT Braintree module - which has more features than Authorize.net DPM.)

---

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

I guess it depends of how you look at it. If XC including onsite payments cannot pass validation but passes it without including onsite payments then QT should take them out for the sake of everyone.

It is another question if these payment methods are not enables and used but included in the package - does this makes XC not to pass validation?

I think it is better if XC by default does not include or support "illegal" payment methods. If the XC owner wants to do this and custom code them - let them do it, the liability lies with the owner of the store then.

By the way I have never been asked by my bank or payment gateway to be compliant. I tried to send them info and the answer was: if we need it we will ask you for it. Go figure....

The big guys are looking for any excuse to collect more money from merchants, let's not give them the chance. If XC has to exists with hosted payment gateways only let it be. Better safe then sorry

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

I am writing some FAQs to cover the major questions asked in this forum thread.

UPDATE: moved to the first message in this thread.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Hi folks,

re: DPM - it is a very controversial solution. Note that Auth.net doesn't position is as a way to tick "PA-DSS compliant" checkbox. Just as a way to "reduce your PCI compliance level".

Different QSAs consider solutions like DPM differently. In order to be safe I recommend everyone to consult with their QSA or merchant account provider directly. At least you'll have someone to point at.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

In addition to Alexander's message:

When using the Auth.net DPM solution, the credit card form is created by the shopping cart software (using X-Cart's template files), and this form is hosted on the merchant's server.

When a buyer fills in and submits this form, the entered cardholder's data is then posted directly to Authorize.Net's endpoint.

However, if the merchant's server is compromised, then the X-Cart's credit card form can be also compromised. So, the merchant need to ensure that their server's environment (including the shopping cart software) is PCI-DSS compliant, do not they?

I would recommend to consult with your QSA or merchant account provider directly regarding the matter - if you need to go with SAQ A or SAQ C when using the Auth.net DPM solution.

You can read more about the Auth.net DPM solution at:
* http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Direct-Post-Method-DPM/ba-p/7014

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

I still have not heard an answer to why X-Payments jumped in price to $1200.

Re: Upcoming X-Cart v 4.4.6 & PCI-DSS requirements
 

Just for reference, my business has passed PCI-DSS compliance using manual processing of orders.

My processor was going to start charging additional fees if we were not compliant. After filling out pages upon pages of questions and providing details in how we process orders, how our customers place their orders, how our internal network operates, and making a couple subtle changes, we received a passing grade.

Although we are currently still using X-Cart vers. 4.0.19, manually processing each order from stored data in the X-Cart database, we still passed. It was my intention to continue manual processing with our new 4.4.x site that is nearing completion.

This new requirement, which sounds like the inability to store encrypted data within the xcart database, disturbs me. Although we could use our payment gateway processor (USA ePay) to Auth only each order, the mess being described in this thread sounds like that too may be impossible without some additional ridiculous expense.

Is manual processing still available? Is the default use of included APIs for gateways such as USA ePay still going to work?

I would like to hear some clarity on what these changes are going to be within X-Cart, and how they are going to affect how I currently utilize my online business.