X-Cart forums

[geckoday]

Originally Posted by Steel

Just so I understand what you are saying, only in the event that you physically host your own server will you be able to avoid the SAQ "tar pit". If someone hosts this server for you, then they will be considered a service provider, and in scope, and in the "tar pit"?

Yes, your host is in the tar pit as service providers are only eligible for SAQ D. But that only applies to the services they provide. What you do in your domain on a shared host falls under your PCI assessment which would still be SAQ C. As part of your processes required by SAQ C you must monitor your hosts PCI-DSS compliance. This can mean either your host doing their own PCI-DSS assessment and giving you a copy or you asking them questions to establish their PCI compliance as part of your annual filling out of your SAQ. If you're hosting with a quality host then they shouldn't have a problem with meeting the PCI-DSS requirements.

[geckoday]

This has generated a few thoughts and requests on the X-Payments implementation.:

1. It was mentioned that X-Payments would serve up its own payment page which would mess up a good one page checkout. This isn't required to properly separate out the payment module from the core. Take a look at the Transparent Redirect method Braintree talks about for their gateway (rebranded Network Merchants, Inc. gateway). X-Payments could work the same way. The payment form on the one page checkout can post to the X-Payments module which then redirects back to the core X-Cart receipt page. Simple and makes the breaking out of X-Payments transparent. I do this today with the Network Merchants gateway to completely remove my web server from PCI scope.

2. If you decide to follow my suggestion in #1 above, why not generically support any browser redirect gateway API? USAePay, Network Merchants and others support this type of API and it has the HUGE advantage of taking your web server completely out of scope for PCI-DSS while keeping it transparent to the customer (i.e. no gateway hosted payment page driving customers away). I modified X-Cart to support the Network Merchants browser redirect API and it works great. And it looks no different to the customer than when I was using Authorize.Net AIM. The idea here is the X-Cart core will allow you to choose USAePay browser redirect, Network Merchants browser redirect, etc or X-Payments. You choose X-Payments for gateways like Authorize.Net AIM where payment data will post to your server.

3. Gateway vaults. Many of us use other backend systems to handle order management. Often we need to charge additional amounts to a customer card for upgrades to shipping, add-ons to an order or reorders over the phone. Some gateways, like Network Merchants, allow referencing a prior transaction ID to create a new transaction. But most, like the ever popular Authorize.Net, don't. More common are "vaults" (Authorize.Net CIM for example) to store all of your customer information including payment information that allow you to reuse the payment information to create new transactions. You separately submit the payment transaction and a transaction to store the information in the vault. Some allow combining the two transactions but it still requires adding additional information to the payment transaction. To eliminate storing card numbers and passing them to the backend systems X-Cart needs to have an option to store the payment information in a gateway vault and store the vault id information in X-Cart so exports to backend systems have the data they need to charge additional amounts to cards.

4. The ubiquitous Authorize.Net. Yup, its the big boy out there. So much so that many competing gateways (Network Merchants, CDG Commerce Quantum, etc.) offer Authorize.Net emulation. The problem is X-Cart has the Authorize.Net URL hard-coded. How about making that URL a configuration parameter in X-Payments?

5. Network Merchants Inc. (NMI) gateway. If you haven't figured it out by now I'm a big fan of the NMI gateway . You may not have heard of it before because they don't offer it directly. They specialize in allowing merchant service providers to rebrand their gateway with the MSP's own name. I use Network Merchants through my card processor Alpha Card Services. They call their gateway Alpha Card Gateway but its really NMI. Same with Braintree and a whole bunch more. So how about supporting it, particularly the Transparent/Browser Redirect API. I really love having my web server out of scope for PCI compliance and would love it more if it was supported by X-Cart. I'd be happy to send you my code to jump start it.

[happyscott]

This whole thing is doing my head in, I can't understand why qualiteam are not making this a simple thing for us, at the end fo the day if you make ecommerce software it's your job to know and help customers be able to implement this with ease no?.

Does anyone know of any other shopping cart systems which are already pci-dss compliant please?

I think it's time to switch can't be doing with this.

[xplorer]

Originally Posted by geckoday

This has generated a few thoughts and requests on the X-Payments implementation.:

1. It was mentioned that X-Payments would serve up its own payment page which would mess up a good one page checkout.

Just a side note: there is no a trustworthy study confirming that putting all the fields on one page increases conversion. One-page checkout looks cool, but it doesn't guarantee that you will get more sales.

Originally Posted by geckoday

This isn't required to properly separate out the payment module from the core. Take a look at the Transparent Redirect method Braintree talks about for their gateway (rebranded Network Merchants, Inc. gateway). X-Payments could work the same way. The payment form on the one page checkout can post to the X-Payments module which then redirects back to the core X-Cart receipt page. Simple and makes the breaking out of X-Payments transparent. I do this today with the Network Merchants gateway to completely remove my web server from PCI scope.

Are you sure that you remove your server from PCI scope? Yes, a browser submitting the data to your gateway is out of the scope. But behavior of the payment form is determined by X-Cart, not the browser. X-Cart is the party that decides where the credit card data will be send. And I guess it will be considered as a payment application that must be verified against PCI DSS requirements: just a small change in a template file of X-Cart will result in sending all credit cards though a hacker's proxy server.

[geckoday]

Originally Posted by xplorer

Just a side note: there is no a trustworthy study confirming that putting all the fields on one page increases conversion. One-page checkout looks cool, but it doesn't guarantee that you will get more sales.

So its OK if you don't support it when there is no evidence either way and your customers want it?

Originally Posted by xplorer

Are you sure that you remove your server from PCI scope? Yes, a browser submitting the data to your gateway is out of the scope. But behavior of the payment form is determined by X-Cart, not the browser. X-Cart is the party that decides where the credit card data will be send. And I guess it will be considered as a payment application that must be verified against PCI DSS requirements: just a small change in a template file of X-Cart will result in sending all credit cards though a hacker's proxy server.

The test for scope is: store, process or transmit cardholder data. My server does none of those so its out of scope. I asked quite a few questions of Braintree about this and they have had it approved by every QSA they have worked with as removing the server from PCI-DSS scope. By your logic even a merchant that uses Paypal or Authorize.Net SIM would have their server in scope because they could be hacked to send customers to a phishing site. Or even a site that says only call us with your credit card information could be hacked to add a card input page or link to a phishing site. Whether or not their are risks doesn't relate to scoping - there are always risks. Scoping just separates the high risk from the lower risk environments. Certainly no merchant should neglect securing their servers - in scope or out of scope.

[xplorer]

Originally Posted by geckoday

So its OK if you don't support it when there is no evidence either way and your customers want it?

Future X-Cart versions will feature one-step checkout provided it is not against PCI-DSS or PA-DSS. You can share your thoughts on this feature at ideas.x-cart.com

Originally Posted by geckoday

The test for scope is: store, process or transmit cardholder data. My server does none of those so its out of scope. I asked quite a few questions of Braintree about this and they have had it approved by every QSA they have worked with as removing the server from PCI-DSS scope. By your logic even a merchant that uses Paypal or Authorize.Net SIM would have their server in scope because they could be hacked to send customers to a phishing site. Or even a site that says only call us with your credit card information could be hacked to add a card input page or link to a phishing site. Whether or not their are risks doesn't relate to scoping - there are always risks. Scoping just separates the high risk from the lower risk environments. Certainly no merchant should neglect securing their servers - in scope or out of scope.

Yes, your server neither stores, nor processes, nor transmits CC data. However, X-Cart is a client-server software. And the payment page is a part of X-Cart. Unfortunately, PA-DSS doesn't give a clear answer on this question.

[geckoday]

Originally Posted by xplorer

Future X-Cart versions will feature one-step checkout provided it is not against PCI-DSS or PA-DSS.

You have multiple PA-DSS certified competitors with one-page checkout already. Google "PA-DSS one page checkout" and you'll find two of them on page 1.

Originally Posted by xplorer

Yes, your server neither stores, nor processes, nor transmits CC data. However, X-Cart is a client-server software. And the payment page is a part of X-Cart. Unfortunately, PA-DSS doesn't give a clear answer on this question.

PA-DSS is derived from PCI-DSS. Same test as PCI-DSS. From the PA-DSS Requirements and security document under Scope of PA-DSS:

"The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data"

You might want to read a good article on a trend of inflating PCI-DSS requirements, The QSA Connundrum. Its easy to expand what needs to be done saying its more secure. But ultimately, its the PCI-DSS or PA-DSS standard we are required to meet - everything else is optional. When selling software, that option should be the customers option not something forced by the software vendor.

[xplorer]

Originally Posted by geckoday

PA-DSS is derived from PCI-DSS. Same test as PCI-DSS. From the PA-DSS Requirements and security document under Scope of PA-DSS:

"The PA-DSS applies to software vendors and others who develop payment applications that store, process, or transmit cardholder data"

You might want to read a good article on a trend of inflating PCI-DSS requirements, The QSA Connundrum. Its easy to expand what needs to be done saying its more secure. But ultimately, its the PCI-DSS or PA-DSS standard we are required to meet - everything else is optional. When selling software, that option should be the customers option not something forced by the software vendor.

I've received an unofficial response from our PA-QSA (they haven't investigated it in details) that, although it is an insecure method of integration, it is not against PCI-DSS. So, most likely the next X-Payments version will support displaying of the payment form in X-Cart, not in X-Payments.

Thanks!

[cflsystems]

Can someone (Ralph Day or someone else with good understanding of this) explain which SAQ will apply for most xcart owners - A,B,C, or D - as I am getting really confused by that whole thing. For example an ecommerce store that sells only online and has only one server with only xcart on it and accepts cc payments on that server without storing any cc data? Or same but processing cc data offsite on the payment gateway page? How about a store connected to POS for face-to-face transactions where cc is physically present at time of purchase?

[Steel]

Originally Posted by cflsystems

Can someone (Ralph Day or someone else with good understanding of this) explain which SAQ will apply for most xcart owners - A,B,C, or D - as I am getting really confused by that whole thing. For example an ecommerce store that sells only online and has only one server with only xcart on it and accepts cc payments on that server without storing any cc data? Or same but processing cc data offsite on the payment gateway page? How about a store connected to POS for face-to-face transactions where cc is physically present at time of purchase?

Hello Steve,

1) An ecommerce store that sells only online and has only one server with only xcart on it and accepts cc payments on that server without storing any cc data? Answer: Could possibly qualify for C or D.
2) Same but processing cc data offsite on the payment gateway page? Answer: Could possibly qualify for A or C.
3) A store connected to POS for face-to-face transactions where cc is physically present at time of purchase? Answer: Could possibly qualify for B, C, or D.
You would need to supply additional information for your questions to be answered.

The PCI information is here: https://www.pcisecuritystandards.org/pdfs/pci_dss_saq_instr_guide.pdf

For simplification, I look at this as a process of elimination.

From the information Ralph has posted earlier in this thread, http://forum.x-cart.com/showpost.php?p=269106&postcount=37
http://forum.x-cart.com/showpost.php?p=273460&postcount=76
and other information I have read, I have concluded that SAQ Validation Type 5 / SAQ D is unrealistic for most businesses. If your company does not have someone that can comprehend and implement procedures/solutions for most of the questions asked in SAQ Validation Type 5 / SAQ D, then you could be looking at $10,000+/year for compliance. And, if you have staff that can comprehend and implement procedures/solutions, then perhaps you can get by on a budget of $1,000 to $10,000/year for compliance. So, for the majority, I suspect SAQ Validation Type 5 / SAQ D is out.

The other practical options for the small internet merchant, as Ralph stated, are SAQ A & C; and, unless you have a third party handle ALL creditcard data functions (internet, phone, fax, mail, and card present), SAQ A is also out.

SAQ Validation Type 1 / SAQ A: Card-not-present, All Cardholder Data Functions Outsourced
SAQ A has been developed to address 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 premises.

So, our business will focus on what requirements/procedures we will need to change in order to meet SAQ Validation Type 4 / SAQ C. It would be helpful to have detailed discussions on the various options available for all aspects.