X-Cart forums

[balinor]

@Balinor - the setup fee in my opinion is very much on the high side (come on... even whole server set-ups and moves are cheaper, if we are being honest) i.e. I don't think it was explained at all in the post why this level was required or this approach...
Really, we are intitled to our comments in here Balinor, it is just up to others to decide, if they agree or not.
Remember the whole reason many (I suspect most) of us took the "open source" approach was to avoid endless ongoing monthly fees (so this is not the ultimate solution).

Yes you are entitled to your opinion, what you are NOT entitled to are baseless accusations about things you have no idea about. Do you know what it takes to set up a shared hosting environment? Do you know what it takes to keep thousands of customers updated with the latest information on this mess? Do you have to field 1000 emails a day asking what the options are? No, you don't. So until you do, keep your 'comments' to things you have a clue about. They are entitled to charge whatever they want for a setup fee to try to offset the countless hours they have probably spent getting a handle on this mess. If you don't like recurring fees, you don't need to use their service. Upgrade your own server and host X-Payments there. If you want to bitch about the way X-Cart has handled this rollout, fine. But don't attack one of the hardest working and trustworthy companies you will find in this business. I won't tolerate it and I hope the rest of you who are familiar with BCSE won't either.

[geckoday]

Originally Posted by BCSE

There appears to be some difference of opinion with respect to PCI compliance. BCS Engineering always suggests that you consult with the bank that manages your CC accounts to ensure that the direction you take is in sync with their understanding of security in the CC environment.

I've found even among QSA's there can be significant difference of opinion. So that is good advice as it is your acquirer / payment processor who is responsible for the validation of your compliance. If you ask the PCI-SSC or the card brands for clarification on anything PCI related they will tell you to talk to your acquirer. The down side of this is its hit and miss how much help you'll get as a small merchant. Some acquirers will tell you to hire a QSA if you need help. Or you'll find that the person they designate to talk with small merchants doesn't have any more PCI knowledge than the merchant.

Originally Posted by BCSE

SAQ C – Any merchant that uses their general use PC to transmit credit card transactions. BCSE’s interpretation is that this questionnaire covers systems like Quickbooks, other point of sale systems, or backoff accounting systems that run in a physical location. For example, a store front or office based system.

I have changed the mind of QSA's who interpretated this the way you do because SAQ C part 2D, where applicability is defined, doesn't make any such restrictions speaking only of payment applications. In addition, the SAQ Instructions and Guidelines state "SAQ C has been developed to address requirements applicable to merchants whose payment application systems (for example, point-of-sale or shopping cart systems)...". So its pretty clear that shopping carts such as X-Cart are covered under SAQ C if you meet the other applicability requirements.

Originally Posted by BCSE

We had an organization come to us in the middle of a hacking event; we rebuilt their site and took over hosting it. Their Bank has them filling out SAQ D every year. All indications from that Bank was that they should have been doing that all along. If you talk to the major hosting service providers about a PCI compliant environment they will lead you to the system that is suggested in SAQ D 2.2.1.

Separation of services is a basic security principle. You don’t want a vulnerability in one service to allow a perpetrator to get into another service. We have helped too many customers through events where an out of date blog or content management system has allowed a hacker to get into a store. The whole point of PA-DSS compliance is to minimize the risk of a hacker getting into the front door, but that is a moot point if unpatched X-cart release 4.1 is also on the same server acting as an open back door. Even without the new PCI compliance rules, this is how we recommend running an ecommerce site. We’ve just simply seen too many people get hacked and had CC stolen simply because either their X-cart wasn’t patched or some other unrelated application wasn’t patched.

A QSA from the Society of Payment Security Professionals on their blog refers to 2.2.1 / separation of services as one of the most abused PCI requirements. It is cetainly a requirement that can generate a lot of discussion as it may be just about the vaguest PCI requirement and the PCI-SSC guidance for it is minimal. Then there is what one QSA trainer calls The QSA Connundrum where some well-meaning QSA's tend to inflate requirements. But I haven't run into a QSA that has said apps that aren't PA-DSS certified can't run with PA-DSS certified apps. You just have to treat those non-certified apps just like your payment application with respect to PCI-DSS requirements like patching. What you describe above is a merchant who is not complying with PCI-DSS by not patching the applications on their server - even their payment application! SAQ C and above PCI-DSS compliance (not PA-DSS certification) requires applying critical vendor security patches within 30 days of release. What I hear from QSA's is that 2.2.1 applies to things like seperating out services and applications that need to be accessed from the web from those that don't, not running email servers on firewall servers or using a database server as a workstation to surf the web. But ultimately, 2.2.1 only applies to SAQ D merchants and onsite assesments by a QSA. I feel that small merchant should avoid putting themselves into the position that they have to fill out SAQ D as its a real pain to comply with if you don't have a lot of time to focus on it. I feel that most small ecommerce merchants can meet the requirements to fill out SAQ C as long as they don't store credit card numbers.

But you are making an important point. To me it is clear that most small ecommerce merchants have enough on their plate running their business without having to worry about maintaining the security of their server. Good security requires a real focus on the details and a certain amount of fanatical dedication to following up on everything regularly. I don't think its makes sense for any small ecommerce merchant (and even most larger merchants) to have credit card numbers flow through their server much less store them. Outsourcing card number handling to someone who has a focus on security as their business is the way to go. I am happy to see X-Cart 4.4 is including a Quantum gateway iframe payment module - the first payment module to be included in X-Cart that allows outsourcing the card handling to a gateway without forcing the customer to a seperate page. Hopefully, this will be a trend and we'll get the USA ePay redirect API added soon and my favorite (but less well known) the NMI redirect API. And hopefully other gateways will develop similar API's.

In the mean time outsourcing X-Payments to BCSE or another service provider so you can continue to use the Authorize.Net AIM or other gateway that your processor provides makes sense. Or going to a gateway hosted payment page like Authorize.Net SIM.

Originally Posted by BCSE

What would be really nice to see happen is if a certified PCI security auditor would make an online web presentation to the X-cart community to clear issues up.

I agree that would be nice. It should be someone who has focused on small merchants as part of the problem that I have run into with QSA's is that they don't focus on that aspect of PCI-DSS. They are focused on the big merchant that needs an on-site PCI-DSS Report on Compliance. Therefore they don't spend a lot of time (or any time) looking at the SAQ's and understanding how they apply. They tend to give you the same answers that would apply if they were on-site auditing a large merchant. Another thing I struggle with QSA's over is exactly what is required vs. what they think is a good idea. I want to know the line I can't cross and as for whatever else is recommended I want to know what the risks are it mitigates, the likelihood of that risk and what the cost is so I can make a business decision as to how much insurance I want to buy (how much security to implement) above the minimum.

I should also point out that I am not a QSA. Before buying the business I run today, my background for nearly 20 years was retail IT for a couple of large nationwide retailers and was at times the technical manager responsible for large ecommerce sites. I was worrying about credit card security years before PCI-DSS was created and worked with some very good security auditors including one who did some serious spook stuff for the military. I've also monitored a few PCI related sites for the last couple of years. So I have a good background for understanding the PCI-DSS and PA-DSS standards. But my interpretations and opinions are just that. Ultimately, you need to review the PCI-DSS and PA-DSS information produced by the PCI-SSC and the card brands to decide if you agree. You should also talk with your acquirer / payment processor for assistance if you need it as ultimately if you have a breach they are the ones who will be going after you for fines and costs associated with the breach if you are not compliant with the standards.

[ambal]

Hi Everyone,

I see this was said here already, but I'll post anyway:
I contacted some payment gateways about their PCI-DSS deadlines as we integrate with them and general type of response I got was this:

"We do not have requirements for the PCI-DSS compliance deadline, we have nothing to do with that as it is set by VISA and Co. Contact you bank or your merchant account provider."

[ambal]

> I wonder did QT ever hired you at least as an advisor.

We are opened for any offer from anyone. E.g. if someone offers some services on the theme of this topic we will be glad to have them listed in X-Cart Marketplace.

Alex

[dmr8448]

So has anyone here actually installed x-payments and x-payments connector and have it fully working with x-cart.

When we install the connector and set it up, will this make the old way of checking out via x-cart automatically stop working?

We have a live site that we need to install this on and I just want to make sure that it will not make the store stop working before we can fully test it.

[cflsystems]

Yes I did with 4.2.1. With 4.3.x should be no pain installation. X-Connector is a module so it won;t break your cart. All other methods will continue to work as tehy are right now. I would suggest - install X-Payments and X-Connector. Configure the module in xcart. Take a note of the paymentid associated with the module. Modify your checkout page to show this paymentid method only to one customer login (you login so you can test). That why the module will be active for this one customer only and you can do testing before turning it on for all customers.

[kevinrm]

Yes, I have it installed and working. I have tested it, it works fine in 4.3.1. I currently don't have it "live" at the moment because no one has as of yet forced me to. I can take it live at a moments notice though.

After you install x-connector, you go into modules>x-connector and configure that. It helps to have multiple tabs on your browser open - one on x-payments and one on x-connector. You have to cut-n-paste the keys from x-payments into x-connector. Then in x-connector, you will have to "import" the payment method into your cart. Then you go into "payment methods" section of x-cart and enable it. To be compliant, you need to turn "off" your old payment method but actually you can run them both at the same time for testing purposes. I put "TESTING - DO NOT USE" under the payment method description when I was testing it, then once I had it working I took it back offline. When a customer checks out, it comes up as a payment method but behaves a little differently than the old way. When they hit the "submit" button, a new page pops up where they enter the credit card info. It's pretty smooth. "One page checkout" it is not, however.

[dmr8448]

we have installed x-payments and the connector and have gone through the entire process and gotten everything setup. We have done the "request payment methods" and the "import payment methods" and it shows "Payment methods have been successfully imported".

However when we go to the payment methods page and then go to to the "payment gateways" area. The X-Payment methods do not show up in the drop down list.

Does anyone know why the new payment method would not be showing in the drop down list?

Thanks
David

[DogByteMan]

It shows up as x-payments xxxxxxxxx at the very end of the dropdown list.

[dmr8448]

Originally Posted by DogByteMan

It shows up as x-payments xxxxxxxxx at the very end of the dropdown list.

I have scrolled all through the drop down list multiple times and it is not there.