Posted 29 January 2011 - 09:25 PM
Posted 29 January 2011 - 10:33 PM
If your client wants to accept credit card information electronically (email, website, text) they MUST be PCI DSS compliant. I am fairly certain your client will NOT want to pay the $6000 - $10,000 cost to become compliant. (none of my clients do)
You can read more about PCI DSS Compliance here
Posted 30 January 2011 - 01:45 PM
Posted 10 March 2011 - 07:33 PM
If my client already has a subscription to Verisign and uses SSL, can I integrate Verisign into my osc as a payment method (module??) and collect the info for her to process offline? Verisign is compliant and uses secure servers, so would I be following the rules or breaking them if I tried to continue this way?
Sorry I'm not eloquent - I thought I understood the PCI compliance but I can't figure out how to do payment modules for osc without actually processing the credit cards live and without a merchant account. My client actually uses a 3rd-party to process payments.
For example: my client gets an order, records customer information for her records (but not credit card info), passes the order to her distributor. The distributor then processes the payment, fulfills the order, and handles shipping. The distributor is then the one who has the payment gateway or merchant account (I may be confusing the two)... As long as we collect the data using SSL and Verisign, will we (my client and myself as developer) be OK?
And, then ... HOW do I integrate Verisign into osc? I can't find any info on Verisign in any of the forums or contributions. I am so confused!!!
Thanks so much for any help you can give me. I'm feeling rather overwhelmed by it all now.
Posted 10 March 2011 - 08:44 PM
PCI DSS Compliance means your client (the store owner) can NOT receive ANY credit card information digitally without your clients website being PCI DSS Compliant. If your client is currently using a hosted cart, perhaps the hosted cart is PCI DSS compliant and if not, then they too are in violation of the PCS DSS Compliance Act. Verisign is NOT a compliance agency, nor do they guarantee PCI DSS compliance, they simply offer a service that verifies the person who owns the website has been checked out and is believed to be the person they say they are. Which really means nothing except they checked the store owners ID.
For your client to accept credit cards, they must sign up with an ONLINE processing company such as PayPal Payment Pro, Authorize.net, Linkpoint or Beanstream to name a few. If your client is currently receiving digital information and manually processing the information, they are breaking the law.
Edited by DunWeb, 10 March 2011 - 08:46 PM.
Posted 10 March 2011 - 09:08 PM
Thank you for your help!
My client also has Security Metrics, which runs scans and is supposed to ensure her site is secure.
I think because she has an account with them, her current site must be compliant. Although, I probably have to look into it further using her account login at Security Metrics to make sure an SAQ was filled out...
So, regarding Verisign, is that an unnecessary expense? If it's not a payment gateway and does not guarantee PCI DSS compliance, then it isn't doing anything for her. I thought that was the payment gateway or processor.
Is Security Metrics an online payment processing company? I just can't tell - I believe they offer it but I'm not sure if it's included in their Quarterly Site Certification. Obviously I need to look into this more. I don't want my client to pay for Security Metrics and Verisign, and then tell her she needs to also pay a payment gateway or payment processor.
My client's publisher (the company that fulfills the orders) processes credit card payments manually. I don't see anything on their site about PCI DSS compliance, even when I go to view my shopping cart. They do have SSL, but I don't see any credential-like certificates or even mention of PCI compliance or security. If my client passes info to her pub to charge credit cards, is THAT against the law ... and/or is that going to get either my client or me into trouble?
Sorry for all the questions - I am just spinning around all the issues and have been for about a month. I feel like I get further from implemenatation every day! There's an option to "just use their shopping cart" but then we aren't compliant if they aren't - ugh!
Thanks again for helping!
Posted 10 March 2011 - 09:22 PM
Verisign is designed to make customers feel better about making online purchases. Personally, I don't recommend it or use it as it's just another expense.
Security Metrics IS a PCI DSS compliance agency. If your client currently has their seal on the site, then your clients current site is more than likely PCI DSS Compliant. However, that does not mean that the new website you want to create is PCI DSS compliant. You would have to retain the services of Security Metrics to certify the new site. This is costly !! Because your clients current site is using a hosted cart, I would guess the hosting service has become PCI DSS compliant on all their servers through Security Metrics.
The current system of processing credit cards sounds like the hosted cart provider is taking care of all of that. Again, I will assume they are compliant.
If you create a website for your client and set it up to receive credit card information without being PCI DSS compliant, your client will be personally liable for ANY security breaches on the website. If your client will be using shared hosting, breaches are inevitable. Because your client has retained you to create the website and you knowingly add a credit card processing system without PCI DSS compliance, you MAY and I say MAY because I have only heard of one case so far about a company that was not compliant being charged criminally and civilly, also be held liable. I suggest you CYA if your client insists on pursuing the payment system.
Posted 10 March 2011 - 10:00 PM
So let me see if I understand all the points:
1. Even though we are not PROCESSING the credit cards, because we are collecting the info, we need to sign up with an online processing company such as Authorize.net, Paypal, (at whatever that cost is) to be compliant.
Most of what I've seen from these companies is a %-based fee based on the total charged. If my client processes offline, then they are effectively paying double fees or commission (once with the online processing company, once through their own manual merchant account). Can you recommend any payment processing companies that would be better suited to my client's usage (processing offline at a later time)?2. We need to have and pay for a dedicated SSL (unless it is part of the payment processing company's fee)
3. Do we also need to be certified by Security Metrics or another compliance agency? Or, is it enough to make sure I use SSL and a reputable processing company that is PCI DSS compliant, such as Linkpoint or Paypal or other? My client says it costs her about $100 a year for the Security Metrics seal. This might be a package deal through the hosted shopping cart system, so I don't want to all of a sudden be in for $1699 to check the site!
4. What is a typical cost for setting up the payment processing and security (is it roughly $100-$200 or much more)? I think she pays about $30/month for her hosted cart, plus Security Metrics (~$100+) and Verisign (?). We wanted a more robust system to suit her store (more product fields, better able to design our own site). Have I unleashed a monster in terms of cost now? (yikes!)
I am worried how to get everything in order - I'll check for other forum posts that outline steps for how to add payment processing correctly.
Thank you so much for your expertise. I want to create a secure and compliant site. I am afraid I'm in over my head (either that or I am overthinking)! Is it as daunting as I think, or is it really just a matter of signing up with Authorize.net or Beanstream?
Posted 10 March 2011 - 10:27 PM
If I were setting this up for a client I would:
1) Use version 2.3.1 to create a custom template for the client to achieve their aesthetic needs.
2) Modify the cart to include the functionality the client requires.
3) Sign up with one of the recommended processing companies (authorize.net, PayPal PP, Linkpoint, Beanstream)
4) Purchase and install an SSL
Quite honestly, I would recommend the client use one of the online processors to avoid any liability issues and to make it simple. Most companies would charge $30-50 plus a percentage fee a month that is compatible with most merchant accounts for brick and mortar stores. Using the above steps, PCI DSS Compliance is NOT required, saving the client money.
Posted 10 March 2011 - 11:12 PM
I wish I could make it that simple. One thing I didn't mention - since the publisher processes credit card payments and receives the funds, the publisher then pays my client based on products sold. She did not want to change that arrangement. If we were to process payments on her new site, she would have to pay her publisher to fill the orders, which would be a deal-breaker. So I will need to sign up with a processing company that offers a "don't process payment now" option - so she can process the payment offline. But that would mean storing the cc numbers as she currently does, and then we'd have to be PCI Compliant, correct? If the processing company is PCI DSS compliant and I verify that the publisher is also PCI compliant, is that enough to continue her current method and meet PCI standards?
Thanks for listing your steps. I installed 2.3.1 and am adding features needed. I've got products_extra_fields (thanks to Gergely Toth!!) working properly, more than 400 products uploaded (about 1/4 have photos), and design comps are now in revision. My stumbling blocks for functionality are [credit cards/payment], and the shipping module [table rate-based on order total, but I need to customize it further to allow choice of UPS Ground, UPS air, USPS, FedEx ground, FedEx air, etc..., each with unique table rates]. I'm hoping to have the functionality ready to show my client, but these two things (with the offline cc processing and 5-6 custom shipping tables) are holding me back.
Posted 10 March 2011 - 11:30 PM
I fear that PCI DSS compliance will be your downfall. Your client can NOT manually process credit card information without PCI DSS compliance. I have gone through the process of PCI DSS compliance with two clients in the past, first one was just over $9000.00 USD and the second was $5350.00 USD. Both clients were from Arizona and both went through hoops to meet compliance standards. (federal and state)
Just a thought, if the publisher had an account with one of the online processors previously mentioned (or control of the account for which payments are received), then the publisher could issue payment to the client once the item shipped. This would mimic the current relationship.
Posted 11 March 2011 - 03:52 PM
It's hard to believe any company would be PCI DSS compliant if they had to pay that much. I imagine they all just process the cards online immediately so they don't have to deal with it. Either that or the merchant companies that store credit card info are so large that PCI DSS compliance costs are just part of doing business for them.
Thank you for your time and suggestions. I will need to verify my client's publisher's data security standards and make sure they are compliant before we use their system. Otherwise my client (and I) would be liable. The publisher has told me before that they manually enter the credit card charges that my client sends them, so I assume they have BOTH an onsite (card present) merchant account AND an online processing company for their own shopping cart system. If they accept info online via their own cart and also enter numbers manually, that would be the only compliant solution. And they would still need to be PCI DSS compliant because they store numbers in order to enter them manually. I sure hope they are!!!
Thanks again, your help has made a HUGE difference to me!
Posted 07 August 2011 - 03:05 PM
You've hit the nail on the head regards PCI, however ....
... is not entirely correct.
Check out http://e-path.com.au - new breed of PCI compliant manual payment gateway enables site owners to receive credit card payment charge authorisations online for them to process offline - just like phone, fax and via physical mail order.
Posted 07 August 2011 - 11:39 PM
The information I posted was North American store owners. Australia and other countries may have their own governing laws.
The credit card accepting convention is pretty well uniform around the world but different countires may enfore rules differently or view different aspects more seriously than others.
If a business accepts a credit card payment over the phone, by fax or by mail order (physical mail) they are most certainly NOT breaking the law. But their merchant account service must be approved for them to accept and charge card not present payments received - I believe this is applicable in any country.
Posted 07 August 2011 - 11:49 PM
Posted 08 August 2011 - 12:31 AM