43 replies to this topic

[HappyPappy]

Hi All,

Must share this in case others are stuck.

If your cart stores or transmits credit card data, even if it is to a proper payment gateway, your cart, hosting, network, the whole box and dice needs to be PCI compliant certified. There's no getting around it anymore.

I spent a few weeks going back and forth to Visa, my bank and I even got a vulnerability scan on my hosting (terrible failed results cause I've got normal shared hosting), and a quote from a company that does auditing. I was left feeling the whole thing is just insane. But these are the rules now. A good friend of mine is paying off a $15,000.00 fine so ain't no way I want to risk it.

Anyway, was about an inch away from walking away from everything and I read some blurbs on these new PCI manual payment gateways out now. A little bit of the too good to be true scenario but I jumped in and have not looked back.

For those wanting a detailed explanation I should mention I can only report on the one I am now with, which is the e-Path Payment Gateway (http://e-path.com.au) Don't know about the others.

With a manual payment gateway your cart never sees or touches credit card details so you offload the liability completely. There is NO PCI DSS compliance needed for your osc because your gateway is already PCI DSS compliant and under SSL.

Suppose its like a glorified remotely hosted payment page except every gateway is unique to each owner and has its own encryption/decryption systems.

I enter credit cards directly into my merchant account at my bank to charge the cards, which is a manual process but I've been able to id every single fake payment attempt recieved and delete them. So far I haven't transacted a single fake payment which is pretty remarkable considering last year fraud and charge backs cost me a little under 2 grand.

So now I accept credit cards and am totally PCI DSS compliant and I haven't spent a cent on getting dedicated hosting, vulnerability scanning, auditing etc, etc, etc or any other rediculous stuff.

e-Path have osc payment modules for their gateway. osc should have these built in as a PCI compliant manual option. I know heaps like to do things manually for offline transacting and these new gateways allow you to still do it that way and be totally PCI DSS complaint.

Anyway, the message is if you don't mind doing things manually then you can be PCI DSS compliant very cheaply.

Hope this info helps some who may be in a panic about PCI.

Bye

Edited by HappyPappy, 09 August 2008, 18:09.

[toyicebear]

That is one of the solutions available for those who wish to do manual processing of cc. (There are other companies besides the one mentioned abow offering the same solution to where they store the cc info on their PCI compliant server system for you)

But even if you use such a system or a payment gateway solution , you still have to fill certain parts of the PCI compliancy simply because you collect and transmit cc info at your site.

Edited by toyicebear, 10 August 2008, 01:25.

[WoodsWalker]

Thanks for the post, Peter!

It sounds as if this solution has most things covered, if the customer actually goes to the payment gateway site to enter their info.

Yes, with all the new requirements and fees for internet security, such useful services are bound to pop up.

I myself opted to go through the entire circus of PCI compliance, plus SSL for my site of course. I did this because our business makes six figures per year on the web (well, just), and I wanted ultimate flexibility in how the interface looked and functioned. But others with smaller operations, or who are just starting out, will certainly want to consider services such as you describe.

For those considering the other route, here's my posting on my adventure getting a PCI certificate.

[Vger]

Quote

I enter credit cards directly into my merchant account at my bank to charge the cards

Which is in violation of your agreement with the Credit Card companies unless you have an Internet Merchant ID.

Quote

With a manual payment gateway your cart never sees or touches credit card details so you offload the liability completely. There is NO PCI DSS compliance needed for your osc because your gateway is already PCI DSS compliant and under SSL.

I'm sorry, but you are talking total nonsense. PCI doesn't just cover storage of card data.

Your post reads more like an advert for the scanning company than a genuinely helpful post on the subject.

Vger

[WoodsWalker]

There is a lot of confusion on this topic, which is a very bad thing since it is so important.

I don't understand the whole thing myself, which is one of the reasons I opted to toe the line and be fully compliant.

However, what Peter says make sense to the likes of me and many others. It doesn't sound like nonsense at all.

Can someone with sufficient knowledge of the subject please clarify this: if you use a payment gateway, in which all of the customer info is gathered (rather than your own site, which simply links to it), and if the service you use is PCI compliant and uses SSL, and if you view your data on this site's pages and don't store info on your own PC, where is the security breach?

I'm not questioning that there may be a security issue here; I'm just curious as to where it lies. With this knowledge we can make responsible choices.

~Wendy

Edited by WoodsWalker, 10 August 2008, 20:07.

[Vger]

Quote

Can someone with sufficient knowledge of the subject please clarify this

Someone just did. My company has 6 dedicated servers running and we've had to get several of them certified for PCI compliance, so I know exactly what is involved.

It's not just the website which has to be certified compliant, but the server the website is hosted on. For instance, even something as simple as keeping backup files online which have been renamed to use .bak as the file extension on your website will get your site failed. Having SSL v2 enabled for SFTP or SSH access on the server will cause a fail. Some scanning companies will fail the server if SSL v2 is built into POP3/IMAP services - even though it is not used. Having TRACK/TRACE enabled on the server will cause a fail.

Even if you do not store card data on your website you do store other customer data which has to be kept secure, such as Name, Address, County/State, Zip Code, Country, Email Address and Password for account access. For instance, is someone can hack the site they can get all transactions changed to different Shipping addresses than those chosen by the customers - effectively hijacking the shipments.

Some fools use the osCommerce Credit Card module, which does store card data in the database (unencrypted), and they then run them through an EPOS machine in a bricks and mortar shop they own. They do this because they've already paid for a Merchant Account and don't want to pay again to get a valid Internet Mercant Account - so they break their agreement with the card companies and use their EPOS terminal to process web based transactions.

You'll see posts on these forums from people wanting to capture and store the CVV number as well as normal card data, so that they can be run through an EPOS terminal. Storing CVV data on a Shared Server is completely against PCI regs and even against the law in many countries (the United Kindom for one). The United States is very tough on PCI compliancy now.

Unfortunately the scanning companies used for PCI compliance testing do not operate any common standard, so the conditions that have to be met will vary with each company.

Vger

[WoodsWalker]

Thanks, Vger; that clears up quite a few questions.

It looks as if the service that Peter has found covers most of the bases, but still leaves his osCommerce installation and database, which sits on his host's server, vulnerable unless this server is PCI compliant. Personal data that was entrusted to you by your customers could be stolen and misused; orders could be rerouted.

For those using services like PayPal - this means you, too.

My advice is: don't think it can't happen to you, because it _has_ happened many times (just search this forum!). Better safe than sorry, which means PCI compliance for the server your osCommerce is on.

~Wendy

[HappyPappy]

WoodsWalker, on Aug 11 2008, 03:29 PM, said:

It looks as if the service that Peter has found covers most of the bases, but still leaves his osCommerce installation and database, which sits on his host's server, vulnerable unless this server is PCI compliant. Personal data that was entrusted to you by your customers could be stolen and misused; orders could be rerouted.

No quite but close. Because my oscommerce site doesn't touch or even see credit card data there is absolutely no risk and PCI DSS is not needed for my site at all.

Here is an actual quote from the PCI DSS ....

"PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply"

My oscommerce site doesn't store, process or transmit the PAN. It never sees credit card data.

I don't know what Vger is on but his comments are off the planet. My merchant account comes with an internet interface that allows me to enter credit cards payments I get over the phone or by my fax machine as well as through my manual payment gateway. And where he says I'm talking rubbish about not needing PCI compliance for my oscommerce cart/website then he is saying the exact opposite to the PCI standards. For his benefit let me repeat what I said earlier, if your website or shopping cart does not transmit, store or process credit cards then it does NOT require PCI DSS compliance. End of story, that's the way it is and it is in black and white within the actual PCI DSS standards (v 1.1).

All I did was get e-Path and adhere to the SAQ that I signed which was part of the manual merchant account facility I have with my bank. That's all there is to it. I accept credit card payments totally 100% in compliance to PCI and I haven't spent a cent on all the hassles of going through the PCI processes for my oscommerce cart/website/hosting account.

All I'm saying is there is no need for people to be worried, there are solutions out there that can make it easy to do things legally without needing to spend big money.

Thanks

Edited by HappyPappy, 11 August 2008, 19:55.

[perfectpassion]

Quote

I enter credit cards directly into my merchant account at my bank to charge the cards

From Aug 10 2008, 05:45 PM:

Which is in violation of your agreement with the Credit Card companies unless you have an Internet Merchant ID.

HappyPappy said:

My merchant account comes with an internet interface that allows me to enter credit cards payments I get over the phone or by my fax machine as well as through my manual payment gateway.

Your merchant account may permit you to use the virtual interface to process as MOTO (mail-order, telephone-order) transaction but it is unlikely to allow you to process e-commerce transactions. E-commerce has a very different level of fraud risk hence must be flagged as such and the merchant account will often have different fee levels.

Each different type of transaction (standard, MOTO, e-commerce, continuous authority etc) has to be flagged as such and usually (though not always) needs a separate merchant number.

Hence processing transactions in the manner you describe is likely to be in breach of your merchant account.

[Vger]

Quote

My merchant account comes with an internet interface that allows me to enter credit cards payments I get over the phone or by my fax machine as well as through my manual payment gateway.

As Tom said, credit card companies require that you have an Internet Merchant ID if you process card payments taken over the Internet.

The setup you refer to is not like Pay Pal where they take the details, process the card payment, running all of the checks and deposit the money in your Pay Pal account, and then you elect at some point in time to transfer the funds from Pay Pal to your bank account as a simple Bank Transfer.

What you appear to have is a hybrid system, where the ePath company takes the card details for you (online) and you then process them using your Merchant ID. If I'm wrong on the way their system works then feel free to correct me.

Vger

Edited by Vger, 11 August 2008, 23:07.

[rhubarb]

Vger, on Aug 12 2008, 12:06 AM, said:

Even if you do not store card data on your website you do store other customer data which has to be kept secure, such as Name, Address, County/State, Zip Code, Country, Email Address and Password for account access. For instance, is someone can hack the site they can get all transactions changed to different Shipping addresses than those chosen by the customers - effectively hijacking the shipments.

Some payment gateways offer the following systems:
1. collection of card details integrated into the merchants website
2. the checkout on the merchant's website transfers to the secure PCI DSS payment gateway website for collection of card data.

For a long time I've realised that option 1 would require the web server to be PCI DSS compliant and therefore require auditing (a situation over-looked by some). However I thought option 2, which is most commonly used on the net by small traders, didn't require the webserver to be PCI DSS compliant and therefore didn't require an audit. What Vger says above is somewhat alarming. Is there a difference of opinion due to different interpretations of the PCI DSS requirements by PCI advisors? My understanding was that if your website or shopping cart does not transmit, store or process credit card data then your website and webserver do not need to be PCI DSS compliant. If this is not so and if Vger is correct then I bet the majority of ecommerce websites are in breach of the PCI DSS requirements.

Quote

credit card companies require that you have an Internet Merchant ID if you process card payments taken over the Internet.

In the UK my understanding was that some credit card companies used to allow a small percentage of transactions to be from online orders and taken as Card Holder Not Present, but maybe this has changed.

[rhubarb]

The PCI DSS version 1.1 dated September 2006 does clearly state in the Preface paragraph 3 that "PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply."

[WoodsWalker]

There are two issues here, as I see it.

1) What I realized when I read Vger's post was that although the cc# may be collected at the gateway's site, the customer's other information (name, address, whatever else you collect) is not. It sits in your osCommerce database, on your host's server. That's why I said that customer data was therefore vulnerable. It's something to think about, since a hacker could enter your database, pirate name and address information, or even change addresses so that he/she received the goods.

2) Does Peter's merchant agreement actually allow him to process internet-based transaction with his MOTO arrangement? I thought I would do this very same thing, until I read the rules of my own agreement. I can't answer this, of course, as every banking arrangement is different, but it tends not to be allowed, currently.

All this being said, I value the information Peter has shared about this service, as it does cut out some of the complication and uncertainty of collecting cc# on one's own site.

~Wendy

Edited by WoodsWalker, 12 August 2008, 14:21.

[toyicebear]

By using a payment metode which sends the customer to the payment processors site where the whole cc info process is done on the payment processors server , your site/hosting does not have to be PCI compliant.

Examples of such would be...

Google checkout
PayPal Express Checkout
PayPal Standard
PayPal IPN
2Checkout
Nochex

But for anyone using metodes where the cc info is in eighter way processed, or transmitted, the site have to be PCI compliant.

Examples of such would be...

PayPal Pro
Authorize.Net
++++

In such cases its fairly easy to get PCI compliant, if your hosting are not willing to make sure the enviroment is PCI Compliant..then change hosting....


For anyone who are considering to store cc info, its very difficult to be PCI compliant and you can not be so using shared hosting.

You will need atleast 1 dedicated server and have to follow alot of security regulations.

For those who wish to manually process cc info metodes such as using 3 party providers for storing the cc info is an easy and safe way to proceed.

There are several providers who offer services where the cc info is stored on a PCI compliant server inviroment and you can access it and process it manually at your convinience. (One example is the service mentioned in the opening post of this tread)

Edited by toyicebear, 12 August 2008, 14:30.

[HappyPappy]

Vger, on Aug 12 2008, 09:06 AM, said:

The setup you refer to is not like Pay Pal where they take the details, process the card payment, running all of the checks and deposit the money in your Pay Pal account, and then you elect at some point in time to transfer the funds from Pay Pal to your bank account as a simple Bank Transfer.

What you appear to have is a hybrid system, where the ePath company takes the card details for you (online) and you then process them using your Merchant ID. If I'm wrong on the way their system works then feel free to correct me.

Correct. There are not too many solutions that allow you to accept credit cards online for processing into your offline merchant account but e-Path is one that is OK and is PCI approved. Trust me I've looked into it heaps.

The reason why internet based transactions have to be flagged as such is because they are anonymous, the risk is insane. This only relates to real time processors because anyone, anywhere can enter any credit card number and with a real time processor its transacted. The transaction will either be approved or declined. Hence internet based transactions are the highest risk ones of all and are the most expensive to transact. That's not the case with the manual payment gateway I have. Nothing is transacted live on the net anonymously with a manual gateway.

I can only relate from my own experience but I have picked up on a number of fake transactions received and I just delete them. Maybe those would have been processed and I would have sent out my product if I was using a real time payment processor and then have to deal with rat-bag charge backs. Been there, done that, NEVER again.

I guess it depends on whether you want automation and run the risks that come with that or go for the manual system where you are in control of things. I prefer the later not only because its a lot cheaper but also because with PCI I am covered. But hey, if I was doing a big number of transactions every day I reckon I'd be snowed under. I like my system but I can't see it being no good if I start to do a lot of orders every day.

And about your other comment, I didn't come in here to 'advertise' any company. I only wanted to share something that for me made things real easy to be handling credit cards and be PCI compliant.

Thanks

[Vger]

The two should not be confused, but they are complementary - PCI and 3D Secure.

If you were UK based and used a system like Protx Direct, where the customer remains on your website and it's only the card data which goes between your site, Protx, your Bank, back to Protx and back to your site, then you'd need to be PCI compliant - even though you don't store the card details. But if you also use 3D Secure on this system and the card passes the 3D Secure checks then there's no chargeback even if it's fraud, because with a successful 3D Secure check the legal responsibility passes from you to your Bank.

I know of some banks which will contact the site owner and say "This transaction was fraudulent. Will you approve a chargeback?" and I know site owners who reply "Yes, actually we do mind. It passed your 3D Secure checks and so the responsibility is now yours."

In Europe all Maestro (Debit Card) transactions now have to be 3D Secure authorised, and it won't be long before Visa, Mastercard etc. rules are the same.

Vger

[WoodsWalker]

Sounds good! What a great thread - we're really getting into the nitty gritty!

Here in North America, debit card transactions on the internet are handled very conservatively, and the VISA counterpart is the Verified-by-Visa program where the customer uses a PIN. It's all very good stuff and not hard to implement.

I'm still a little uneasy about customer names and addresses sitting on an unsecured server - but that's not a PCI issue per se. If one chose to go through PCI certification anyway, it might add another layer of certainty.

Thanks again for starting th thread, Peter, and to all who've contributed.

~Wendy

[HappyPappy]

Having 3D secure does NOT get you out of having to be PCI DSS compliant certified. If a site stores, transacts or transmits credit card data, even if your system uses 3D secure, your site still MUST get PCI DSS certification. If you aren't getting PCI DSS because you have 3D secure then you had better buy some lotto tickets becase you are risking being hit with huge fines.

The whole idea of leaving your merchant account open on the internet for your real time payment gateway to transact live into it without you knowing is just pure insanity in my opinion.

Before getting the manual payment gateway I struggled with different things to reduce charge backs. I had things enabled for Verified By Visa and Master Card Secure Code. I didn't get one fraud one in the three months I had them. BUT, I noticed almost immediately my sales went from average three per day to three per month!@! People were just not going through with making payment after ordering. Aparently this is a well known and common experience. Cardholders registered into with scheme number less than 1%.

I had Verified by Visa and Master Card Secure Code removed from my system and overnight I was back to receiving payments again with my online gateway processor so it was back to Russian roulette with getting fake payments again. Geez I hated that and an so darn happy to be finished with all that crap now.

Its good I can talk about things in a positive way now because a while back I was seriously in a terrible state as my online business is my main source of income.

Anyway, I've revealed a bit more here than usual but hey if my experience can help others then way to go.

[Vger]

Quote

Having 3D secure does NOT get you out of having to be PCI DSS compliant certified

I didn't say it did. What I said was that if you use a system like Protx Direct then, depending on your Bank, you may also have to have the server and site PCI compliant. In the UK at the moment it is only Barclays Bank which insists on being PCI compliant if you use Protx Direct.

However, you have no choice about payments made with the Maestro Debit Card (which used to be called Switch) having to be done via 3D Secure. That's now a requirement within the European Union countries.

What I also said was that if you use 3D Secure and the transaction passes the 3d Secure checks then the liability, if it laters proves to be fraudulent, passes to your Bank.

Within the UK, if you are on a website which uses 3D Secure, you can opt to bypass it on 3 occasions, but by the 4th occasion you must register for the scheme if you wish to buy from sites which use it.

Yes, there's no doubt that for many sites using 3D Secure means a drop in sales - which is not good by anyone's imagination. However, for sites which sell high-value items and routinely ship all around the world it's an absolute necessity. You don't want to ship something worth £5,000 ($10,000) and then get charged back on it.

Vger

Edited by Vger, 13 August 2008, 14:08.

[WoodsWalker]

Interesting info. I've been encouraged by my payment processor (Moneris, in Canada) to implement Verified-by-Visa and Mastercard SecureCode, but haven't taken that step yet.

We are on a system that allows us to vet the orders before they are put through to the card. What goes on behind the scenes is that when a customer's order is accepted through the website, it has in fact only been "pre-authorized". We must then go through our internet Moneris terminal to "capture" the transaction - that is, to make it a sale. In the meantime, we can scrutinize the name and address and order details and make sure everything is correct and makes sense. I'm hoping this would eliminate most fraud before it happens.

After about a month and 100 transactions, we have not had to weed out any fraudulent or suspicious transactions - yet. I hope it does not come to pass. We used the phone to process MOTO transactions (phone- and mail-orders) for many years, and never had any fraud - only the occasional deadbeat customer who backed out of a sale by lying to VISA instead of by contacting us, which is a different matter.

Best of luck to all,
~Wendy

Edited by WoodsWalker, 13 August 2008, 14:36.