X-Cart forums

[bigredseo]

Nice work Ralph. Would love to see X-Cart hire you as a consultant to head up getting the Audits in line!

[xplorer]

Hi folks!

It is impossible to certify each X-Cart/LiteCommerce version that is in use today. And it is impossible to force all X-Cart and LC users to upgrade their stores to a new "PA-DSS certified" version of X-Cart. That's why we will release and certify X-Payments, not X-Cart. X-Payments is a solution that enables X-Cart 4.x and LiteCommerce users (wanting a payment form to be shown on their website domain) to get their stores PCI compliant with minimal efforts.

If you believe that your acquirer will accept your SAQ C when X-Payments runs on a single shared hosting account with X-Cart, just install it in a subdirectory of X-Cart. In this case the payment form will be on the very same URL path as other store pages. Or you can make the X-Payments payment form shown on a sub-domain of your store: http://www.store.com for store pages and https://payment.store.com for the payment form. Neither the first nor the second option is possible with the Authorize.Net SIM module built into X-Cart and LiteCommerce today.

[Dongan]

Originally Posted by xplorer

Hi folks!

It is impossible to certify each X-Cart/LiteCommerce version that is in use today. And it is impossible to force all X-Cart and LC users to upgrade their stores to a new "PA-DSS certified" version of X-Cart.

Finally trapped & have your own limitations of releasing many branches/releases. This was sought at numerous occasions & noone was listened to. Now, trapped yourself. ok. is there any possibility to get certification for some major & stable releases rather than all releases. For example, 4.0.14/18 (which is considered more stable in 4.0.x releases & more stores that are running in 4.0.x versions using this release only). Similarly 4.1.10 & 4.1.12 in 4.1.x version. 4.3.0 in 4.3.x releases. so, if 4.0.18, is ceritified, anyone at 4.0.10 can easily upgrade to 4.0.18, not a big jump to 4.3.0. This will give some breath & save some cost.

X-Cart is not ready to spend money to certify all versions due to the budget. Similarly, X-Cart customers is not ready to spend big money due to the budget just for only one thing, compliance!

My thought/suggestion is: instead of dropping the option of each version support, i would recommend to support for all the modules. Release this x-payments as an paid add-on. In this way, the cost for certification can be shared & the burden will be reduced. As a customer, i am willing to buy the module which costs 100$ rather than upgrading to latest version that is costing 1000$ at least to get a free module/solution which is a must. Everyone knows that it is a must add-on. I am sure everyone should buy this module to run their store successfully.

[xplorer]

Originally Posted by Dongan

My thought/suggestion is: instead of dropping the option of each version support, i would recommend to support for all the modules. Release this x-payments as an paid add-on. In this way, the cost for certification can be shared & the burden will be reduced. As a customer, i am willing to buy the module which costs 100$ rather than upgrading to latest version that is costing 1000$ at least to get a free module/solution which is a must.

This is exactly what we are going to do. Instead of upgrading to a new version you just disable CC functions in your X-Cart version, install free X-Payments and connect it to your X-Cart store via a connector module. A free connector module will be released for X-Cart 4.3.x. Most likely this module will work for X-Cart 4.2.x (with a few modifications). For older X-Cart versions we can develop a custom connector module (and it will cost less than upgrading these versions to the most recent one).

Or you can just switch to a payment gateway that handles the entire payment processing job so that it doesn't matter whether X-Cart is a PA-DSS verified application, or not (as long as CC functions are disabled in X-Cart). This is the integration method recommended by most payment gateways today.

[groovico]

I feel I need to throw my 2 cents in here.

Xplorer, we've been with x-cart for a very long time now (personally it's been 8 years for me), we've got software and mods that support x-cart 3 all the way through to the latest branches.

One issue we've always had with x-cart is the upgrade methodology, it's been very hap-hazzard on occasion.

We've seen many people panic (as you can see from this thread) as X-cart is tied into their financial income, their sites are also reliant on alot of custom work to skins, to mods, to the working of it to get it working how they need. Anytime an announcement like this is made (and it's almost always as soon as one release has just come out) it make people anxious on what's wrong with the current release or next big release.

X-cart has always needed a focus on the core code rather than all the extra features, in the past few years it's improved but at the same time it's become more and more code and resource intensive.

The problem with that is larger x-cart sites get slower (try comparing the brute speed of an x-cart 3 site with 60,000 customer records/200,000 orders/5000 products to an x-cart 4.X site with the same size of DB).

There are times when I wonder what x-cart admin is doing when I'm wanting to display a hundred orders, it acts as if you've asked it to run a marthon, even though the servers are more powerful these days the net speeds are faster etc

I'm all for future x-cart development, I'd rather x-cart 5 was a solid continuation of the x-cart series, I recall litecommerce was supposed to be x-cart Lite, years ago, which fell by the wayside.

X-cart is very well established, there's a real danger of alienating both customers and developers if it's development and announcments are not handled well.

[exsecror]

Originally Posted by groovico

The problem with that is larger x-cart sites get slower (try comparing the brute speed of an x-cart 3 site with 60,000 customer records/200,000 orders/5000 products to an x-cart 4.X site with the same size of DB).

That's not entirely true about the speed groovico our site is a lot larger than that and we have no speed problems (we deal close to 200k unique visitors a month). Then again there are a few things that have to be taken into account:

- I re-optimized and cleaned up a lot of procedural code
- I re-optimized the SQL tables and queries to be ANSI compliant
- Our database software is static custom compiled and aggressively tuned. [Current cart is on MySQL but the new one is flipping over to PostgreSQL for integration reasons]

I've done this both for our current cart (4.1.12) and the new one (4.2.3) making significantly large clean ups. X-Cart can house a large shop it just has to be tuned for it. Now let's take into account how big our database for the cart is (this does not include our internal databases where we process everything for shipments, etc):

141,818 Products
6,424 Categories
1,000+ Special Offers
110,000+ Customers
250,000+ Orders

When it comes down to it, most of X-Cart's bottle necks are actually in it's database design. If a large portion of the SQL database was repaired and the badly written queries were eliminated the software would be fine. I found at least 20+ core critical queries that were badly written that had to be repaired (and 70% of the tables missing required indexes). Granted the code base isn't any cleaner, I had to completely re-write most of the modules due to inefficient coding (X-SpecialOffers is the one that had the most bugs). There's also a lot of what X-Cart can do that should be transferred over to SQL Triggers and Stored Procedures. Using an interpreted language to do SQL maintenance is a DB no-no (for instance the Rebuild Cache for quick_prices, quick_flags, subcounts, etc should be a native SQL function, we're already doing that) simply because SQL can do it a lot faster.

[rrf]

Originally Posted by geckoday

Answer me this:

Why would anyone use X-Payments to connect to Authorize.Net AIM when Authorize.Net offers SIM which does exactly what you are building X-Payments to do?

[lots of text]

I agree with your point. Moreover, that's precisely our approach to PCI DSS / PA DSS.

If you use PayPal, Google Checkout, Authorize.NET SIM or any other payment method in which PAN (credit card number) is handled by your gateway only, you don't need X-Payments and you are out of scope of PCI DSS / PA DSS requirements. Here is the excerpt from the standard:


The Primary Account Number (PAN) is the defining factor in the applicability of PCI DSS requirements and PA-DSS. If PAN is not stored, processed, or transmitted, PCI DSS and PA-DSS do not apply.


from :
https://www.pcisecuritystandards.org/pdfs/navigating_pci_dss_v1-1.pdf



So, you only need a PA DSS compliant software if it is used in direct conjunction with customer PAN, i.e. if it processes credit cards directly. I must say, this is not a good idea for an average web store in the first place. But if you do want to handle customer credit card data yourself, you need to comply with PCI DSS requirements. PA DSS compliant software makes it easier to fulfill PCI DSS requirements, and X-Payments is just that. It isolates the PAN processing scope.

And it is fully integrated with X-Cart.

PS: Oops, only after posting I noticed that Xplorer has written basically the same thing above.

[Steel]

Originally Posted by rrf

If you use PayPal, Google Checkout, Authorize.NET SIM or any other payment method in which PAN (credit card number) is handled by your gateway only, you don't need X-Payments and you are out of scope of PCI DSS / PA DSS requirements.

Hello Ruslan,

This whole PCI DSS / PA DSS issue is not clear at all.

PayPal literature implies that if a merchant is using Website Payments Pro, Payflow Pro, or Virtual Terminal they (PayPal) will not be responsible for PCI Compliance.
https://www.paypal.com/us/cgi-bin/webscr?cmd=xpt/cps/merchant/PCICompliance-outside

So, as an example, is it possible for an X-Cart user, on a shared hosting server, to implement Website Payments Pro as an X-Cart additional payment option, and qualify for SAQ C compliance? And, if so, does that not require X-Cart to be PA DSS compliant?

If not, then perhaps the various payment options need to come with a warning label.

[geckoday]

Originally Posted by rrf

... Here is the excerpt from the standard:


The Primary Account Number (PAN) is the defining factor in the applicability of PCI DSS requirements and PA-DSS. If PAN is not stored, processed, or transmitted, PCI DSS and PA-DSS do not apply.


from :
https://www.pcisecuritystandards.org/pdfs/navigating_pci_dss_v1-1.pdf

The quote may be valid but you linked to a version of the standard that is over 2 years old. PCI-DSS was updated to 1.2 in October 2008 and then to 1.2.1 last March. The correct current link is https://www.pcisecuritystandards.org/pdfs/pci_dss_saq_instr_guide.pdf

Originally Posted by rrf

...It isolates the PAN processing scope.

You've just made my point about security people turning your house into an armored bunker when deadbolts and a home security system are all that is required. Your customers want PA-DSS compliance. You added your own requirement to isolate the PAN processing scope which is not required for PA-DSS compliance nor for PCI-DSS compliance. How many of your customers have asked for this? Of those who did, if any, how many of them want it at the expense of running a second server that does have to be PCI-DSS compliant? Even if you remove X-Cart from PCI-DSS compliance you still have to secure your X-Cart server and come pretty close to PCI-DSS compliance anyway. You just doubled the pain and cost of running an X-Cart store, complicated the setup and drastically decreased integration. Even if a merchant chooses to run X-Payments on the same server as X-Cart they are still stuck with the setup complexity and drastically decreased integration.

Originally Posted by rrf

And it is fully integrated with X-Cart.

Now you've come to the crux of my issue with your approach. I've been testing X-Payments alpha. X-Payments is definitely not "fully integrated", its a loosely integrated bolt-on extra. First you setup your gateway settings in "Payment Configurations" in X-Payments. Then you copy over several X-Payments generated settings over to the X-Payments connector settings in X-Cart. Then as part of the X-Payments connector configuration in X-Cart you must import the "Payment Methods" from X-Payments (a two step process - request payment methods then actually import them into X-Cart). Wait, wasn't that "Payment Configurations" over in X-Payments? Then you have to do the X-Cart setup. Go to X-Cart "Payment Methods" and under "Payment Gateways" you select an "X-Payments payment method" to add it as an X-Cart "Payment Method". If you ever change Payment Methods, I mean Payment Gateways, no I mean Payment Configurations in X-Payments you must reimport and setup in X-Cart again. So you're configuring 3 different modules - X-Payments, X-Payments connector and X-Cart - that's not "fully integrated" in my book. But wait there's more. You need to build an X-Payments template to match your site design. And it doesn't use the same template system as X-Cart so its not just a cut and paste.

Lets compare it with the existing Authorize.Net AIM module? For setup, go to the X-Cart "Payment Methods" and under "Payment Gateways" add a "Credit Card Processor" of Authorize.Net AIM. Go up to the new Authorize.Net "Payment Method" you created and configure your gateway settings. Done. One module to setup. No new template to build. Lets look at the final checkout page for the existing AIM module.

AIM.pdf

Order summary and a form for payment information and a Submit Order button. Straightforward and fully integrated. This is the type of PA-DSS compliant solution your competitors are offering.

OK, now the "final" checkout page for X-Cart using the X-Payments connector.

XPay1.pdf

Order summary and a submit order button. Where's the payment form? There's a submit order button and no indication up in the checkout step indicator thingy that there is any other step for payment. OK, I guess I'll submit the order and see if I get it for free! Great, I get a wait while I'm submitting your order page. Oh darn now there is a payment page, I guess I have to pay for it.

XPay2.jpg

What happened, this doesn't even look like the same site. Why didn't that "fully integrated" system use my store template?

If you don't provide a PA-DSS certified solution that in checkout looks exactly like the current AIM module then you have failed to meet your customers needs. If it isn't as easy to setup as the current AIM module you have failed to meet your customers needs. If it doesn't simply install with X-Cart on a single server with the only configuration required being which gateway to use and the gateway connection parameters you have failed to meet your customers needs.

[cflsystems]

I can't say it any better. Thanks Ralph