X-Cart forums

[Jayk]

Originally Posted by exsecror

It may be in your best interests to also support Payment gateways that take the whole processing out entirely but without requiring the customer to go offsite such as Braintree's Transparent Gateway. For many merchants including us it is not an acceptable or viable solution to have our customers redirect off-site (we do thousands of transactions a week). I also do not want to have to be forced to invest unnecessary funds in a completely separate box for a program that may or may not work (plus I don't trust encrypted code because it's security and stability cannot be audited effectively). Nor do I want to deal with the fact that if the program happens to break due to poor QA testing of having downtime till a engineer looks at which would be a problem anyway because I don't allow unauthorized personnel access to our facilities or servers. Granted right now until I transition us over to Braintree we are out of scope since I re-wrote X-Cart's payment core to forcefully truncate the credit card numbers in compliance with PCI but that's something I can't keep doing, hence the Braintree transition.

Braintree looks good. Too bad they don't have Canadian merchant accounts. They mention that they have partners in Canada for merchant accounts to use with their gateway though. I'll have to check it out. Their transparent gateway could be a good solution.

Jason

[Jayk]

In case anyone else was wondering about Braintree (for Canada anyway), I just heard back from them and unfortunately, their partnerships for Canadian merchants require processing volumes in excess of $3 million per year. Way outside of our scope.

Jason

[just wondering]

Originally Posted by zorg

or (if a merchant wants to be responsible for the safety of credit card data):

2) become PCI-DSS certified.

I do believe the first option, being many times easier and cheaper, should be considered by the most of merchants. That's a typical practice anyway.

By choosing the second option a merchant is obliged to comply with strict PCI-DSS standard requiring him to set up a quite complicated environment where cardholder data could be stored or processed safely (i.e. http://help.qtmsoft.com/index.php?title=File:Xpayments_dataflow.png), and then go through the certification process.

By delivering X-Payments, PA-DSS certified solution, we'll be happy to serve merchants who would select the second option.

Becoming PCI-DSS Certified isn't that hard or expensive. All I had to do was fill in a form, register at the company our Bank uses, and that's it.

Maybe other banks have other ways of doing it, but on Streamline it was that easy. The only thing I had to change on X-Cart is that it didn't store all the card details. Keeping the last 4 numbers is ok.

I don't need Server Scans or anything like that.

How much did it cost me? A few hours of my time, tops.

Now we, probably as much as most other people running e-commerce sites, don't like to use the "web version" of payment sites as, unless you've spent countless hours making it look like your own site (if they even let you do that) the address in the address bar changes, which in my opinion puts most people off.

I may not use 4.2, 4.1 or 4.0, but if I did, I'd be fuming. You really, really should make it work on 4.x, not just 4.3.x with some pitiful excuse about making "guidelines and patches" for anything not 4.3.x.

[BritSteve]

I wonder if any developers will step up and create a tie in for x-payments and 4.0/4.1 versions.

It would be nice if one of the developer companies (BCSE, WebsiteCM etc) on here created an alternative to x-payments, I think they would do a better job than x-cart. x-cart seem to have really dropped the ball on this one and left us with very few options.

Steve

[hyper1]

Originally Posted by zorg

Thank you all for your interest in X-Payments application. My name is Yury Zaytsev, I'm CTO at Qualiteam, though haven't been posting much to X-Cart forums previously.



Just to make it clear, X-Payments 1.0 will be released along with a mod for X-Cart 4.3.

Depending on your needs we'll also prepare guidelines and patches on using X-Payments with other X-Cart versions, LiteCommerce and other open source e-commerce software.

The important thing to note is that X-Payments is intended only for the minor part of merchants who want to go through the complete process of PCI-DSS certification. X-Payments, thanks to the PA-DSS compliance, will make it easier for the merchants.

The major part of online stores currently operating could be configured to actually become out of the scope of PCI-DSS certification (in this case a store should not store, process or transfer cardholder data). Guidelines on configuring X-Cart in this manner can be found at http://help.qtmsoft.com/index.php?title=X-Cart:User_manual_contents (see "Configuring X-Cart to meet PCI DSS").

Thank you for the cooperation, and feel free to contact me for further clarification.

In mid-October 2009 the online roadmap from X-cart stated the payment module would be released January 2010. It now shows May 2010. Considering compliance is required a month later that should be more than a concern for v4.3 users, especially since the initial testing is still in planning stages.

The roadmap still states "the module that can be used by X-Cart 4.1/4.2 users with moderate customization of X-Cart source code."

What I read from the CTO is that the roadmap is no longer valid and he has updated the roadmap in this thread with other options, none of which seems viable to most users of these versions.

We have more than an "interest in X-Payments application" and as a CTO you owe more than a closing comment like "contact me for further clarification".

I am sure if you could provide a patch to support older versions you would, and to be clear, it sounds like it is beyond the ability of the team and the application, otherwise you provide it to avoid the concerns of your customers. My only complaint is Qualiteam should have been very clear about that from the beginning. Because you were not, there will be thousands of sites forced to scramble for a reasonable solution.

[geckoday]

Originally Posted by zorg

By taking PCI-DSS into effect in July 2010 VISA is giving merchants only 2 options:

1) configure their stores so that they wouldn't store, process or transmit cardholder data, by using web-based payment gateways.

or (if a merchant wants to be responsible for the safety of credit card data):

2) become PCI-DSS certified.

I do believe the first option, being many times easier and cheaper, should be considered by the most of merchants. That's a typical practice anyway.

By choosing the second option a merchant is obliged to comply with strict PCI-DSS standard requiring him to set up a quite complicated environment where cardholder data could be stored or processed safely (i.e. http://help.qtmsoft.com/index.php?title=File:Xpayments_dataflow.png), and then go through the certification process.

By delivering X-Payments, PA-DSS certified solution, we'll be happy to serve merchants who would select the second option.

It seems like you don't understand whats really going on. Merchants are already required to comply with PCI-DSS and have been for years. What is changing in July is that VISA is requiring merchants to only use software purchased from a third party that the third party has had PA-DSS certified. Therefore, there are really 4 options come July for merchants:

1) Use a gateway hosted payment page so you don't store, process or transmit card numbers
2) Use a transparent redirect gateway API like NMI (Braintree and others) or USAePay. This allows you to host the payment page but when the customer submits the page the data goes direct to the gateway server instead of your server.
3) Convince your shopping cart vendor to get PA-DSS certification for their payment module that uses a payment page on your server that submits the data to your server where it is then sent to the gateway.
4) Write your own payment module to use a payment page on your server that submits the data to your server where it is then sent to the gateway. Or you can have someone else write it for you as a one-off module (it can't be something they sell to multiple clients).

If you choose 1) or 2) you get to fill out the simplest of PCI-DSS Self Assessment Questionnaires since you never handle card number yourself.

If you choose 3) or 4) the complex setup in your diagram is not required by PCI-DSS. A large company may want to do it that way to reduce the systems in scope for their PCI-DSS assessment. But for your typical X-Cart shop that is a PCI level 3 or 4 merchant there is really no gain in doing it that way. In fact, it just complicates their life and costs them more money. In either 3) or 4) the merchant will probably have to fill out SAQ C or D depending on whether or not they store card numbers. No other certification is required unless the merchant is large and falls into level 1 or 2, in which case they will need an outside certification of PCI-DSS compliance no matter how they handle payments.

[geckoday]

Originally Posted by Jayk

In case anyone else was wondering about Braintree (for Canada anyway), I just heard back from them and unfortunately, their partnerships for Canadian merchants require processing volumes in excess of $3 million per year. Way outside of our scope.

Jason

Braintree uses the Network Merchants, Inc. (NMI) gateway. Its not exclusive to Braintree, they just market the transparent redirect feature really well. NMI doesn't sell their gateway direct to merchants. Instead they sell it to merchant service providers (MSP) and let them brand it with their company name. So you have to hunt a little to figure out who is using NMI. Try googling for ISpyFraud and "Quick Click Shopping Cart" - both are parts of the NMI gateway. A quick google for ISpyFraud Canada turns up:

http://www.canadamerchantaccount.ca/internet-merchant-accounts.php
http://www.msicanada.net/safepay.php

and a couple of more on the first page. If you don't want to switch from your current MSP you can get the NMI gateway by itself and keep your MSP:

http://www.planetauthorize.net/

Just verify with any MSP that they are rebranding the NMI gateway and you will be good to go with the transparent redirect API.

[hyper1]

Originally Posted by geckoday

It seems like you don't understand whats really going on. Merchants are already required to comply with PCI-DSS and have been for years. What is changing in July is that VISA is requiring merchants to only use software purchased from a third party that the third party has had PA-DSS certified. Therefore, there are really 4 options come July for merchants:

1) Use a gateway hosted payment page so you don't store, process or transmit card numbers
2) Use a transparent redirect gateway API like NMI (Braintree and others) or USAePay. This allows you to host the payment page but when the customer submits the page the data goes direct to the gateway server instead of your server.
3) Convince your shopping cart vendor to get PA-DSS certification for their payment module that uses a payment page on your server that submits the data to your server where it is then sent to the gateway.
4) Write your own payment module to use a payment page on your server that submits the data to your server where it is then sent to the gateway. Or you can have someone else write it for you as a one-off module (it can't be something they sell to multiple clients).

If you choose 1) or 2) you get to fill out the simplest of PCI-DSS Self Assessment Questionnaires since you never handle card number yourself.

If you choose 3) or 4) the complex setup in your diagram is not required by PCI-DSS. A large company may want to do it that way to reduce the systems in scope for their PCI-DSS assessment. But for your typical X-Cart shop that is a PCI level 3 or 4 merchant there is really no gain in doing it that way. In fact, it just complicates their life and costs them more money. In either 3) or 4) the merchant will probably have to fill out SAQ C or D depending on whether or not they store card numbers. No other certification is required unless the merchant is large and falls into level 1 or 2, in which case they will need an outside certification of PCI-DSS compliance no matter how they handle payments.

Thanks Ralph. I am only interested in option 3 - option 1 and 2 are not even a consideration. I understand the implications of option 3 and the increased annual cost to comply. My shopping cart vendor is x-cart, and I am convinced I have not received due diligence from x-cart in their communication regarding their efforts to bring v4.1+ into a position of compliance...until now.

[cflsystems]

This is getting interesting. At the same time - just 3 months left and it seems like QT thinks this is enough time for the payment module to be released, every merchant to install it, and the module to work without bugs right out of the box. And of course because the code will be closed (encrypted) QT will have to do all the customizations so stores below 4.3 can use the module. How long will this take when there are thousands of xcart stores?

[BCSE]

Originally Posted by hyper1

After months of deceitful thread responses and answering questions in a way that never obligates x-cart to provide a fully functional payment option for pci compliance, I am at least happy to see the CTO finally state they have no intention of meeting our requirements. It has finally forced us to realize we must choose to spend a lot of money to upgrade to an interim solution (v4.3), which has little or no benefits over 4.1.x, or leave. The latter option is looking much better than it did before the CTO response. It took months, but it is finally clear. Thanks

We have many clients needing to stick with earlier versions of X-cart for various reasons. We'll likely create a way to use X-payments with the earlier versions. From my understanding it's the connector between X-payments is what needs to be changed, not X-payments. So we wouldn't have to touch any code that needs to be certified. We're researching this now so we can have a full plan for our customers. Feel free to drop us an email if you want to be notified when we have several options available to help people with this transition.

Thank you,

Carrie