Quote:
|
Due to PCI-DSS requirements being enforced over last months
|
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.)
---