PCI-DSS changes

I overheard from a client there may be some upcoming Credit Card changes that would affect all cart checkout forms by adding yet another "secret code/word" field but there'd be some more apparent validation through the card issuer possibly reducing the overall customization of a site's checkout process.

• double post, sorry *

Yes, I read your post. There is also some speculation about whether this signals the demise of Ubercart. IIRC, at least one consultant said he will no longer be using Ubercart.

I told my client our options may be to 1) help Ubercart get certified, 2) use an external payment gateway like paypal or Google, 3) drop credit card processing from our plans, 4) drop Ubercart.

I should have anticipated this kind of move when Visa bought Cybersource and am trying to get a definitive idea of what is going on.

Which is why I told my client that we could just plain drop taking credit cards if the new standards can't be complied with. This is not a retail store. Processing credit cards is a convenience for our dealers, but not taking them will not result in a loss of business.

Ubercart doesn't store the credit card number anyplace, but it does ask for the credit card number to pass along.

If you have specific questions, please feel free to post them. In my non-Drupal-during-real-work-hours I head up the security team at a financial institution that is also a member of VISA. I'm not a QSA but I have access to one if something specific comes up.

In a nutshell and greatly generalizing here, anything that stores or processes the 16 digit PAN number (which is the number printed on the front of a card) needs to comply with the standard. The departure points as to what type of audits you are dealing with generally splits at how many cards you are handling and whether you are a VISA Member, service provider, etc.

The standards, including FAQs, are all publicly available here:
https://www.pcisecuritystandards.org/index.shtml

One to particularly pay attention to is the Payment Application Data Security Standard which gets into payment applications.

The easiest thing to do is to not get into the PCI business in the first place and use a third-party payment gateway that IS PCI certified. Redirect your users there, allow that organization to accept the card info, and then obtain some type of proof-of-purchase. Stay away from the card numbers if you can.

@rjbrown99

"The easiest thing to do is to not get into the PCI business in the first place"

That is what we are doing- we will be using authorize.net. However rules are changing, VISA is being vague about the changes, and other Ubercart users are panicking as if this rule will no longer be valid. I'm trying to find-out if it is really time to start panicking? If the new rules only affect those in the PCI business, then it wouldn't affect me. But if it affects the shopping-carts themselves then we need to have a plan-of-action.

I assume these changes are an attempt to hold gateways like Heartland to a more rigorous standard, but the timing with VISA buying Cybersource/Authorize.net raises questions about killing competition.

Thank you.

If I understand Ubercart I have it taken care of, but it never hurts to learn more so I'll take you up on the offer.

Will you be at the LADrupal camp?

When would be a good time for you (I'm busy All Tuesday and Friday evening)?

I have a brick & mortar retailer client who is joining the online sales fray for the first time. After a lot of discussion the decision was made to go with PayPal's "PayFlow Link" service (not "PayFlow Pro") which is a payment gateway that uses a client customizable webpage hosted on PayPal's servers. This means the 16 digit PAN number never touches the client's servers which is the single biggest factor towards minimizing your PCI-DSS issues.

Many first time online merchants use PayPal's "Website Payments Standard" or "Website Payments Pro" packages because they are easy to setup but there are a lot of differences. I want to point out just one though...

The big difference is that the Website Payments (WP) options use PayPal as the merchant processing "bank" and so it is PayPal who sets the per transaction % fees, but the PayFlow (PF) options use a gateway to the merchant processor of your choice which means if you already take CC's in your store, you can very likely use the same merchant service arrangement as you do with your swiping machine. This greatly simplifies billing management and if you are already a preferred customer then the per transaction fees may be very nice.

The one strong suggestion I will offer if you go this way is to have your merchant servicer set up a separate (sub)account number for online sales versus swipe sales.

I would like to clarify a few statements above.

1) If your organization accepts credit cards, then you must be PCI compliant. Even if you use PayPal (or equivalent) for payments. PCI has a lot to do with business practices, so it applies to any organization that accepts credit cards.

2) The relevant section of the PCI DSS V2.0 document is Requirement 6 (Develop and maintain secure systems and applications) that mandates commercial credit card applications (shopping carts). OTOH, it is virtually impossible for a individual developer working on a shopping cart/payment application to meet all of the sub-requirements.

3) The disadvantage of a hosted payment solution (e.g., Authorize.net Simple Integration Method) is that the customer is taken off-site. You are unable to have a completely integrated solution that keeps the user on your domain.

4) Visa doesn't know or even care if you have hacked the code. PCI DSS is enforced by the merchant bank. If you don't comply with the bank's requirements, you can't take credit cards (at least through that bank). If you have a release of information, and it is found that you lied on the form; then you will not be able to accept credit cards. Of course, if you are TJ Max or Sony, then this doesn't apply because the credit card companies need you. For the rest of use - well SOL.

Leonard Daly