55 replies to this topic

[mrgg]

Awesome ty =')

[dbibby]

Thank you very much

[justinswaa]

Here's a boost for the glass half full crowd....

Apparently (in the UK at least) the credit card companies will soon (possibly in the next 3 or 4 months) require PHP 5.3 for servers to pass their PCI compliance test, so this will force the hand of hosts to upgrade...

[osccoder]

Wow Wow Wow

I just downloaded OSCOM 3.0 on to a MacBook Pro with MAMP PRO, Debian Squeeze with tweaks, and now working on an Alpha Processor Based System - not done yet.

The code works, thus far, flawlessly --- Excellent Job and Work!!  

To the development team - worth waiting for!!!!!!!!!!!!!

Regards to all,
osccoder

[GemRock]

justinswaa, on 01 April 2011 - 12:46 PM, said:

Here's a boost ......

not quite. how many onlineshops need pci? very few and only those who is big enough to have a dedicated server, and if you have a dedicated server, do whatever you like.
for argument sake, paypal (which i dont like btw) speaks loud and clear its taken the pci hassle out of majority of online shops by having its server(s) pci'ed so that you dont have to, unless for some bizarre reason you want to use its so-called 'direct payment'.
and so is true for other payment processing providers.
bottom line: if you do not store card details in your database on the server, pci is irrelevant, and so is php v5.3.x.
ken

Edited by GemRock, 02 April 2011 - 11:07 PM.

[Harald Ponce de Leon]

Hi Ken..

GemRock, on 02 April 2011 - 11:05 PM, said:

if you do not store card details in your database on the server, pci is irrelevant, and so is php v5.3.x.

Until when? PHP 5.2 reached its end of life with 5.2.16 released on 16th Dec 2010, and PCI requires the software used to be kept up to date regarding security fixes.

This isn't an issue yet as PHP 5.2.17 was released on the 6th Jan 2011 with a "critical issue" fix. But how long will PHP bring out security or critical fixes for 5.2?

Kind regards,

Edited by Harald Ponce de Leon, 02 April 2011 - 11:26 PM.
fixed the quote

[toyicebear]

GemRock, on 02 April 2011 - 11:05 PM, said:

not quite. how many onlineshops need pci? very few and only those who is big enough to have a dedicated server, and if you have a dedicated server, do whatever you like.
for argument sake, paypal (which i dont like btw) speaks loud and clear its taken the pci hassle out of majority of online shops by having its server(s) pci'ed so that you dont have to, unless for some bizarre reason you want to use its so-called 'direct payment'.
and so is true for other payment processing providers.
bottom line: if you do not store card details in your database on the server, pci is irrelevant, and so is php v5.3.x.
ken

Not quite right, even if you just transmit cc details you are also required to be PCI compliant. (ie. the customer enters the cc info on your site, you do not store this info in the db, but the cc info is transmitted to the payment processor for further processing)

Ie. using your own merchant account and a payment processor like authorize.net, PayPal Pro, PayPal Payflow or similar you are still required to be PCI compliant.

Its only when using a payment processor where the cc info is entered on the payment processors servers that you don't need to be PCI compliant. (like standard PayPal, Moneybookers, 2checkout, Nochex or similar)

[justinswaa]

toyicebear, on 02 April 2011 - 11:30 PM, said:

Not quite right, even if you just transmit cc details you are also required to be PCI compliant. (ie. the customer enters the cc info on your site, you do not store this info in the db, but the cc info is transmitted to the payment processor for further processing)

Ie. using your own merchant account and a payment processor like authorize.net, PayPal Pro, PayPal Payflow or similar you are still required to be PCI compliant.

Its only when using a payment processor where the cc info is entered on the payment processors servers that you don't need to be PCI compliant. (like standard PayPal, Moneybookers, 2checkout, Nochex or similar)

No, if you use a gateway like worldpay or paypal, the customer is diverted to their server before entering cc details, so nothing is entered on your own site. It's possible that you still would need compliancy for your own site though, even just to handle name and address details. PCI compliance forms are a nightmare. My shared host have said that they will upgrade in the next 2 or 3 months because of PCI compliance. I suppose there only need to be 1 or 2 out of maybe a few thousand who need the server to be compliant for them to need the upgrade. Small stores are often the one that store data and process offline to avaoid the high commissions of gateways

[toyicebear]

justinswaa, on 04 April 2011 - 08:48 AM, said:

No, if you use a gateway like worldpay or paypal, the customer is diverted to their server before entering cc details, so nothing is entered on your own site. It's possible that you still would need compliancy for your own site though, even just to handle name and address details. PCI compliance forms are a nightmare. My shared host have said that they will upgrade in the next 2 or 3 months because of PCI compliance. I suppose there only need to be 1 or 2 out of maybe a few thousand who need the server to be compliant for them to need the upgrade. Small stores are often the one that store data and process offline to avaoid the high commissions of gateways

If you read my post before replying you would see that i already said that some processors offer a solution where you are sent to their site/server to input the cc info and that if you use one of those for your payment then you would not be required to be PCI compliant.

BUT for instance PayPal offer several payment modules, and only some will work like that. PayPal Standard, PayPal IPN and PayPal Express.

WHILE PayPal Pro and PayPal PayFlow does not sent the customer to the paypal servers, and the cc info is transmitted via your website if you use one of those..and hence you will need to be PCI compliant.

WorldPay also have several optional ways of doing transactions, and if you use a module for their direct methods you will also need to be PCI compliant.

Its very easy to check for yourself what "style" module you are using, go through your own checkout and if you are asked to input cc info there you are using a "direct" module and need to be PCI compliant.

If on the other hand you are not asked to input any cc info on your site but are redirected to the payment processors web pages to input the cc info, then you are not required to be PCI compliant.

Edited by toyicebear, 04 April 2011 - 09:42 AM.

[justinswaa]

toyicebear, on 04 April 2011 - 09:41 AM, said:

If you read my post before replying you would see that i already said that some processors offer a solution where you are sent to their site/server to input the cc info and that if you use one of those for your payment then you would not be required to be PCI compliant.

BUT for instance PayPal offer several payment modules, and only some will work like that. PayPal Standard, PayPal IPN and PayPal Express.

WHILE PayPal Pro and PayPal PayFlow does not sent the customer to the paypal servers, and the cc info is transmitted via your website if you use one of those..and hence you will need to be PCI compliant.

WorldPay also have several optional ways of doing transactions, and if you use a module for their direct methods you will also need to be PCI compliant.

Its very easy to check for yourself what "style" module you are using, go through your own checkout and if you are asked to input cc info there you are using a "direct" module and need to be PCI compliant.

If on the other hand you are not asked to input any cc info on your site but are redirected to the payment processors web pages to input the cc info, then you are not required to be PCI compliant.

Didn't realise that. Seems to defeat the purpose of a payment gateway if people are inputting card data on a website that is not part of the payment gateway. I would guess that this is the less common scenario though..

[toyicebear]

justinswaa, on 04 April 2011 - 12:20 PM, said:

Didn't realise that. Seems to defeat the purpose of a payment gateway if people are inputting card data on a website that is not part of the payment gateway. I would guess that this is the less common scenario though..

Its actually quite a common scenario for shops one level up from mom-and-pop style shops.

BUT since you do not store the cc info in the db (or send it by email or any other such variants), its also quite easy to get PCI compliance in such a scenario.

Note: for those wanting to store the cc info, the criteria for PCI compliance is "staggering" and not to mention expensive.

To sum up.

Easy way, PCI Compliance not needed, use a payment processor where the customer is sent away from your website and to the payment processors website to input and complete the payment there. (When payment is completed the customer is sent back to your website again)

A little hazel, PCI Compliance needed, use a payment module that let the customer input cc info on your site while the data is transmitted "invisibly" to a payment processor who validates and processes the transaction in real-time.


BIG hazel, PCI Compliance needed, store cc info to use for manual processing. This has a lot of conditions to fulfill, is a very costly to complete and to maintain.

(For those who desperately want to process cc payment manually, there are companies like for instance E-Path (www.e-path.com.au) , which lets you do so without your site having to be PCI compliant.)

[GemRock]

toyicebear, on 02 April 2011 - 11:30 PM, said:

Not quite right, ...

i think you somehow missed this bit in my post:

Quote

...unless for some bizarre reason you want to use its so-called 'direct payment'...

thats a typical example of entering card details on your web shop.

@ Harald: i dont know when but would reckon some time in the future, not something that would happen in the next few months. as for php.net's position of abandoning php v5.2.x, i think its a bit of irresponsicible given the large user base (just think about how many osc2.2 shops in the past nearly 10 yrs time, let alone other apps) of v 5.3's earlier versions, and it knowingly creates incompatibility between the old and the new.
"if it aint broke, dont fix it", after all.

Ken

Edited by GemRock, 04 April 2011 - 03:45 PM.

[Harald Ponce de Leon]

Hi Ken..

I don't recall any fatal errors occuring with running v2.2 (not v2.3) on PHP 5.3, only that error notices were being logged due to certain functions being deprecated. As long as display_errors is off it will be fine running v2.2 on PHP 5.3. (This is the same for most other software)

Kind regards,

[GemRock]

hi Harald

were you testing the out of box standard osc 2.2 , whereas in my mind i am thinking about those heavily added-on shops. my concern is to do with the 'mayhem' created by the upgrade of mysql from v4 to v5 just a couple of years ago when i spent, or rather, wasted, lots of time updating scripts.

btw, it seams osc2.3.1 still uses the "array_merge($sql_data_array, $insert_sql_data)" the same as the earlier osc versions. dont if theres some magic somewhere in v2.3.1 that i am aware of?
dont get me wrong. i am not against technical progress. just feel like it has to do slowly, and i think sometimes the progess is made by purely peer to peer review or pressure.

Ken

Edited by GemRock, 04 April 2011 - 06:42 PM.

[justinswaa]

just a suggestion...for all those who aren't hard core programmers and just want to download the latest production version of OSC that will run on their server, a little explanation about the current versions available for download would be helpful and save a lot of forum questions...

[Taipo]

GemRock, on 04 April 2011 - 06:35 PM, said:

hi Harald

were you testing the out of box standard osc 2.2 , whereas in my mind i am thinking about those heavily added-on shops. my concern is to do with the 'mayhem' created by the upgrade of mysql from v4 to v5 just a couple of years ago when i spent, or rather, wasted, lots of time updating scripts.

btw, it seams osc2.3.1 still uses the "array_merge($sql_data_array, $insert_sql_data)" the same as the earlier osc versions. dont if theres some magic somewhere in v2.3.1 that i am aware of?
dont get me wrong. i am not against technical progress. just feel like it has to do slowly, and i think sometimes the progess is made by purely peer to peer review or pressure.

Ken

The general rule of thumb is that a script coded in an older version of PHP will still work on a newer version of PHP except you may get depreciation errors. However script that is coded specifically for the latest version of PHP will probably break when installed on a server using an older version of PHP.