X-Cart forums

[dmr8448]

I just did a fresh install of X-cart 4.3.2 and I am trying to do a test install of X-Payments and I get the following reason for the install failing:

Web Location settingsweb :<Missing parameter> (this shows as missing even though I have it filled in correctly in the config file)


Critical dependenciespdo PHP extension:disabledRequired: enabledpdo_mysql PHP extension:disabledRequired: enabled
What does this mean and how would we enable it?

Thanks
David

[kevinrm]

It pops up another screen where you enter your credit card info. You can't really tell that you are taken out of x-cart, it looks pretty seamless.

My problem with it so far is skinning it. The default skin is "okay" but generic. There is a xp-skin-generator.php file that will supposedly generate a skin that matches your site. I can generate the skin, but I can't get it to work save my life. The supplied instructions are lacking, I've had more problems with this part than any other area of x-payments.

I have mine installed and ready to go. I don't have x-payments "live" at the moment because I don't have the skin thing working, but should I have to go "live", I can do so. Just waiting to be forced into it.

Originally Posted by dmr8448

Does any one have an example of how the x-payments works during the checkout process of x-cart. So if someone selects "credit card" as there payment option...what happens.

Is the user then taken to the x-payments system and are they totally out of x-cart then.

Will this still look seamless to the end user that is shopping on the site?

[kevinrm]

I made a completely new thread for discussing installation in the "x-cart add ons" area of the forum, seems like that would be a more appropriate area to post in but no one seems to care so I guess I'll address this here.

First, you are running PHP 5.3.x, right? If that is the case, then you should be able to go into your control panel and adjust the PHP settings. You may have to do it with unix commands. Or, you may have to have an admin do that, depending on your situation. Seems like mine just worked when I had PHP 5.3.2 installed.

Another area that was confusing was using the " " in the config file - you need to use the quotes for most of the settings.

Originally Posted by dmr8448

I just did a fresh install of X-cart 4.3.2 and I am trying to do a test install of X-Payments and I get the following reason for the install failing:

Web Location settingsweb :<Missing parameter> (this shows as missing even though I have it filled in correctly in the config file)


Critical dependenciespdo PHP extension:disabledRequired: enabledpdo_mysql PHP extension:disabledRequired: enabled
What does this mean and how would we enable it?

Thanks
David

[dmr8448]

Originally Posted by kevinrm

I made a completely new thread for discussing installation in the "x-cart add ons" area of the forum, seems like that would be a more appropriate area to post in but no one seems to care so I guess I'll address this here.

First, you are running PHP 5.3.x, right? If that is the case, then you should be able to go into your control panel and adjust the PHP settings. You may have to do it with unix commands. Or, you may have to have an admin do that, depending on your situation. Seems like mine just worked when I had PHP 5.3.2 installed.

Another area that was confusing was using the " " in the config file - you need to use the quotes for most of the settings.

I am running 5.3.2 and my host says that the PDO items are enabled, but the install script shows them as disabled. IS there a way for me to check if they are enabled? Will that show in a phpinfo.php file?

[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.

BCS Engineering is taking a very conservative view on the PCI compliance interpretation. When fines of $100,000 or more are involved we would much rather take the more security approach.

Each SAQ lists the eligibility items in section 2D, except for SAQ D which is meant for any Merchant system that doesn▓t fit into the other 3. We see the SAQ schedules as follows:

SAQ A √ Any Merchant that uses an offsite processor (Paypal, Authorize.net SIM, 2checkout) to handle credit card transactions.

SAQ B √ Any Merchant that uses paper receipts or dedicated standalone dialup or internet connected terminals.

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.

SAQ D - This is the catch-all if you don▓t fit into one of the other questionnaires.

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.

BCSE Engineering is not a PCI compliance auditor and cannot even be one because we create web application software. What we presented in our document is what we feel to be a conservative and natural security progression for ecommerce sites. 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.

[DogByteMan]

Originally Posted by BCSE

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.

Then I would assume you sure would not want to put a gold mine of X-Payments linked to X-Carts together on one server and call them as separate. One person gets careless, everyone on that X-Payments server goes down with them.

[dmr8448]

Originally Posted by dmr8448

I am running 5.3.2 and my host says that the PDO items are enabled, but the install script shows them as disabled. IS there a way for me to check if they are enabled? Will that show in a phpinfo.php file?

My php.ini files shows

extension=pdo.so
extension=pdo_mysql.so

Does that mean these are enabled? Most host says they are enabled, but when I try and run the X-Payments install script it says these are disabled and will not let it install.

[cflsystems]

Originally Posted by BCSE

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.

But the shared hosting is just that - many users on one server and if one of them gets hacked "simply because either their X-cart wasn▓t patched or some other unrelated application wasn▓t patched" it is possible all of them to get hacked. So where is the difference then? What makes you recommend X-Payments on a separate server but before X-Payments all of these carts shared space and resources and were collecting CC info, with some of them even saving that info in their database. I see your point of getting everything as secure as possible but do not see the reason for X-Payments being on a separate server. (not attacking you just looking for answers in that whole mess)

[Asiaplay]

lol - Only because that way they can charge outrageous prices for hosting X-Payments... crazy, but true...

Cheers - Asiaplay

PS: Germany did well tonight in world cup - 4:0 - wow!!!!!

[EN4U]

Here we talk just about payment mods...... etc.... What about the store itself and all of its mods. Do they all need to be upgraded? I know in my Miva store there were mods that needed updating, all free.. yet there were some. Also some code changes here and there.

This goes way beyond a payment setup to become PCI complaint. This is truly more of a mess than i think is even recognized.