Best PCI compliant payment module & processor to use for OSC 2.2 MS2?

centerforward
centerforward used Ask the Experts™
on
I started an ecommerce site for a client in 2006, it's an OSC 2.2 MS2 implementation.  The project was abandoned but they'd like to launch it now with integrated credit card payment.

The staging is here:
https://www.thermprocesses.com/index.php

I've implemented SSL just recently.

My client's really own requirement currently is that they want the buyer to enter their credit card info and pay as easily as possible, *on thermprocesses.com*, without leaving the site.

I'm concerned now about OSC 2.2 MS2 being so old, and the "Payment Card Industry Data Security Standard":

How Do I Know If Oscommerce Is Built To Be Pci Compliant?
http://forums.oscommerce.com/topic/266802-how-do-i-know-if-oscommerce-is-built-to-be-pci-compliant/

Can anyone advise me of a solution for payment module + CC processor that is as many of these things as possible:

 - PCI compliant
 - integrated CC payment on the thermprocesses.com side
 - easy module to install (exact name/version and where to get it etc.?)
 - ease-of-setup
 - good rate/value

I figure I must be one of many in this situation, but there seem to be countless overlapping options with vague issues and hacks and fixes and I'm just wondering if someone with experience can recommend a known/clear route?

He has PayPal Pro, but it appears that the IPN is meant to send the visitor TO PayPal, not to collect the cc info on thermprocesses.com (and he doesn't want that).

I'm reading you're "not supposed to store the CVV" so I'm wondering if there's some processor that works with a module over SSL to get the info but not store it (very long? etc.).

I'm also curious about E-Path,
http://e-path.com.au

"One of the advantages of e-Path is your site doesn't need to be PCI DSS compliant because it does not transmit, store or process credit card data. Your site doesn't even touch credit card data."

But I don't know if that's affordable/reasonable for the scale of his store or if it would even integrate with OSC 2.2.

All advice is very much appreciated!!
Thanks,
Alan
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Dave BaldwinFixer of Problems
Most Valuable Expert 2014
Commented:
To be PCI compliant when you accept credit card info on your site,  you also have to sign up for monthly or quarterly PCI scanning service to check for vulnerabilities on the web site.  The CC processor will require it for you to continue to accept credit cards and process them thru their service.  They could also require a PCI audit of the computers in your client's office to ensure that the appropriate physical security is done.

He should rethink the importance of completing the transaction on his own site.  It can get costly for no particular benefit.
There is an approach that many payment processors now offer that is called payment tokenization. It is designed to allow you to utilize your own hosted checkout, while still leveraging a third party payment processor and not taking on a PCI burden around your checkout.

Tokenization typically works as follows:

1. To make a purchase on your website, the customer will enter their payment card information into the designated payment fields on the order page. These payment fields will be hosted by the payment processor, even though the broader site and checkout page is hosted by you. When the customer hits the 'submit' button, the data is immediately encrypted and transmitted directly to the payment processor for storing, processing, and token generation. The payment data never enters your environment.

2.  The payment provider passes you a token number, which is unique to the payment session. When the customer hits 'place order', you pass the token number to the payment processor.

3. The payment provider matches the token number to the the payment card information that it captured in step 1 and then processes the payment.

This methodology is designed to keep your hands clean of payment card information. The only data you ever have access to is the token number.

A number of payment processors provide this capability. I have used Litle and Company's version of this, which is called the Litle Vault. Cybersource and First Data also offers payment tokenization (although First Data is often challenging to work with, from a customer support standpoint).

Please let me know if this helps and if I can provide any additional details.

Brian

Author

Commented:
Both of these responses make total sense and are helpful thank you -----  

It may be wishful thinking but a specific scenario actually known to work with OSC 2.2 MS2 would be wonderful.  Finding modules for that isn't easy because it's not new/current.
JavaScript Best Practices

Save hours in development time and avoid common mistakes by learning the best practices to use for JavaScript.

Developer & EE Moderator
Fellow 2018
Most Valuable Expert 2013
Commented:
Any of the major carts should be ok.  As far as PCI, it will be more about your server set up and apps/software you are using on your server, but not the cart it's self in most cases.  

They key is you have to use the latest version.  Right now, it looks like the most current version of OsCommerce is 2.3.3.4.  When you do your pci survey and scan, this is one of the items that will come up.  The scan looks at everything from what ports are open to what versions of software you are running.   As example, I was a couple versions behind in SmarterMail and one the things I had to do was not be more than one version behind.  

If you are on a shared server from a major hosting company, chances are the server is already good to go.  

As far as storing data, your merchant agreement will read something to the effect you can't store any information that is returned as well as the credit card number and cvv.

To store credit card info for later use, gateways like http://www.authorize.net/ or https://usaepay.info/ and others will send back a transaction id that you are allowed to store and can use that transaction id in lieu of the credit card for subsequent transactions.  Just know this takes on more risk on your part.

I would start with who the merchant processor is and work back.  Some processors allow a choice of gateways and others don't give you a choice or  use their own.  if you are looking for an out the box solution, your next step is to make sure the cart software you are using is compatible with the gateway choices you are authorized for.

If you are used to OsCommerce, why not just upgrade?  OpenCart is free http://www.opencart.com.

As far as your rates go for your merchant account / gateway, it's like buying a used car.  You see many different rate thrown at you but you have to work the math for all of your transactions and you will see they pretty much end up very similar.  

Some processors like paypal and intuit have made pricing a bit more simple.   Intuit offers $19.95 per month with a 3.15% discount rate and 25 cents per transaction.  http://payments.intuit.com/ecommerce-payment-processing/  Although this rate is a bit high, they treat all online transactions as keyed as opposed to swipe.  Some processors will charge an even higher rate for non qualified (Corporate or Miles cards) but their initial rate will be much lower.  

You said your client has paypal pro, that will allow you to process payments on your own site just like a traditional processor https://www.paypal.com/webapps/mpp/compare-business-products and their fees are lower https://www.paypal.com/webapps/mpp/merchant-fees @ 2.9% discount rate plus .30 cents per transaction for low volume accounts.  If you are doing $3k to $10K per month, your discount rate goes to 2.5% and for above $10K volume you are at 2.2%.  

Between paypal and intuit, paypal is the better deal.  If you have $2900 in monthly transactions with an average ticket of $30, your total cost with paypal is $113 vs $115 with Intuit.  If your average ticket was $75, then paypal is at $83 vs $87.  If your volume is higher, your rates with paypal get better.  

It is going to be hard for a small merchant to beat those paypal rates for website payments.    Last year, I seem to remember Intuit's rate was a lot less.  

With a more traditional processor, the rates will be a bit more confusing because their rates are typically broken out in greater detail but the effective rate is what counts.

To summarize, start with the merchant processor.  Once you know who that is, then you can use their own list of approved cart vendors.  Or in the case of a traditional merchant account, start with the gateway.    (PayPal Pro is good with OsCommerce) https://www.paypal.com/cgi-bin/webscr?cmd=_wp-pro-integration-outside.  Lastly, prepare to spend about $100 to $300 for your pci scan and don't be afraid to fight any false positives http://help.comodo.com/topic-208-1-490-5187-.html.  https://www.controlscan.com/pcicompliance.php
Scott FellDeveloper & EE Moderator
Fellow 2018
Most Valuable Expert 2013

Commented:
I should have added in my cost comparison the monthly fee.   With a low volume account, Intuit's rates are just a little bit higher, but their monthly fee is $10 per month lower.  Based on my comparisons, that puts Inuit just a little bit better.  But you can see once you go beyond that low volume, hands down Paypal will be better.

Author

Commented:
I appreciate everyone's help.  I realized I asked a broad question, and I genuinely appreciate everyone's time in communicating that information and context.  With all of this information, I will post next a more specifc request and see if anyone knows the answer ...
Scott FellDeveloper & EE Moderator
Fellow 2018
Most Valuable Expert 2013

Commented:
Final answer on this thread http:Q_28429770.html

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial