Payment Card Industry Data Security Standards and the Law

PCI DSS continues to create questions for our merchants. 

Who created the standards? Are they law ? (very nice but do we have to?) who's enforcing all this stuff? and so on.

The standards are developed by a security council comprised of the major card brands and most everything you need to know can be found on their site -  PCI Security Standards Council.  You can find merchant requirements by size right here on our PCI DSS blog.

Enforcement and the law are other issues.

Currently PCI DSS is "enforced" by the card brands and put in place by payment processors.  The processor works with each merchant and merchant account to ensure standards are met and the merchant is charged for the cost of compliance.  Merchants found to be out of compliance, who experience a data breach, can be fined by Visa or MasterCard and risk losing credit card processing privileges (think livelihood folks).

Two issues stand out when it comes to the law, merchants and securing the confidential data of consumers using credit cards to purchase goods and services - notification of data breaches and PCI DSS compliance. 

Data Breach Notification.  If a breach is detected by a merchant...do they have to tell and WHO do they have to tell?  Currently and amazingly, there is no federal law legislating actions regarding a data breach though they are in the works.  S.139 - the Data Breach Notification Act is still alive but hasn't gone any further since November of 2009, H.R.2221 Data Accountability and Trust Act - last point of action- was passed in the House in Dec. 2009.  These things take time. 

Your state may be another story.  Since 2002 and California's SB1386, many states have enacted notification laws requiring companys to notify consumers if their data has been lost or "compromised".  Typically the laws address what must be reported to the consumer - type of data compromised, who must report the breach, how consumers will be notified (electronically, in writing, etc.) and how quickly. 

To see if your state has a law regarding security breaches check this list from the National Conference of State Legislatures - almost all do. 

While each law is different, in addition to notification - legislature seems to be moving towards merchant liability in security breaches (maybe data security ISN'T such a bad idea!).  In other words, states are also enacting PCI DSS compliance law.

The state of Minnesota is the first to make merchants (2007) not compliant with PCI DSS liable for associated financial institution costs in instances of security breaches (i.e. reissuing cards, customer refunds for unauthorized charges, closing and reopening accounts, etc.).  Could be costly.

In 2009 Nevada updated its encryption law to mandate all businesses in the state that accept credit and debit cards be PCI DSS compliant - pretty strong statement.  In March of 2010, Washington enacted merchant liability laws relevant to PCI DSS compliance similar to that of Minnesota.  Businesses with a breach, found to be out of compliance, will be held financially responsible for costs associated from the incident.  Merchants take note - these laws apply to out of state businesses transacting business in the state. 

It's worth noting here I guess that some of these new laws are relevant only to merchants handling a large number of transactions or level I merchants.  We suspect however, that not only will other states follow suit but to some degree, eventually - all levels of merchants will be held liable for compliance.

Moral of the story?  PCI DSS is not going away.  Expect standards to get tougher if anything and while the federal government is lagging - states are taking steps to protect consumer card data.  If you're a credit card processing merchant - you should be too.

 

 

 

 

 

Mobile Merchant Accounts, P2P, Square and All That Jazz

All of the December 2009 and January 2010 credit card processing industry rags are touting mobile payments as "the thing" in 2010.  Growth, applications, and opportunities are arriving rapid fire - and so we're going to try help our merchants sort it all out (I'm dancing as fast as I can).

So....let's launch with the newest gadgetry that's creating a great deal of buzz...Square.

Jack Dorsey, founder of twitter (very cool we agree) -announced a new venture - development of mobile payment technology compatible with Apple's iPhone called Square.  The hardware and service is in "beta" mode (just testing so chill folks) but it sure has raised a ruckus of attention in the online community. 

The ruckus is two fold -

One is WOW that's mobility in a small convenient package.  The Square, is little, plugs directly into the IPhone, and allows the iPhone user to accept a credit card payment from anyone, anywhere - swiped (lower risk).

Two - it comes with the merchant account with a simple, flat rate transaction fee (no rates on the website so we only have rumors and tweets for info).  Excuse me?  No application, no underwriting?  Fascinating.

Jeff Green, Editor-in-Chief of Payments Source - talks about the device and service in his Editors Letter in the January/February 2010 issue. It's exciting and Dorsey's getting a lot of publicity, but things are all quite vague when it comes to the payments processing and Green notes in his letter that perhaps Square will act as an payments aggregator, such as PayPal, running all of the transactions through their own merchant account.  All still up in the air - but a quick gander at the site turns up a few vital points for our small business friends always looking to reduce costs we know -

• Square touts No contracts - I printed 17 pages worth of Square "Service Agreements and Payment Services Agreements" right off the site.  Most of us don't need to check with an attorney to know what that means - legal agreement = contract.  There might not be a length of service contract but anybody taking money from and delivering to, bank accounts electronically is working on a contract - has to be.  In this case apparently there may even be two - one with square and if they deem it so, one directly with the payment processor.

The Square Service Agreement -

• No warranty - this one's pretty clear - at this poing in time Square does not guarantee it's service - for availability, dependability or risk. No mention of PCI DSS. 
• Communications - electronic only currently - no matter what your question or issue - no calling'em.

The Payment Services Agreement-

• Reserves - "Reasonably determined" - new accounts have to have one (I'm guessing that's everybody) equal to 14 days of sales activity plus pending disputes.  The reserve could be raised or removed based on activity, credit reviews etc.   If you don't keep sufficient funds in the reserve it may get funded from your Square Account, i.e. credit card processing sales.
• Transaction limits - Square accounts have transaction limits - no idea what these are yet - stay tuned.
• You need to provide a written receipt to your customers for any transaction over $15 - you can give the customer the option to decline it of course and you can offer an email receipt, but not in lieu of.
• Availability of Funds - doesn't say when you get your money - 2 days? 3? 5?  just that Square can limit your access to your Square account funds if they feel they are at financial risk or other agreement parameters are in dispute.
• Fees - doesn't say. 

Ok - so remember Square is in Beta - I'm sure they'll work out these kinks but at quick glance we can't help but think these current questions raise some real issues for businesses.  The application does seem fun for P2P (person to person) payments - think garage sales, girl scout cookies, PTA fundraisers, etc. or maybe the handyman, lawn guy, tupperware and avon lady, that doesn't do enough processing to warrant their own merchant account but wants to offer the convenience of credit card sales.  That's cool. 

The term small business is pretty broad though.  Most merchants we service need electronic payments professionals to navigate POS equipment, funding and value added services above and beyond the "merchant account". 

Today there are a number of overwhelming factors that impact a merchant's ability to process credit cards securely AND profitably.  Merchant account agreements are indeed complex and typically include 8-12 types of fees depending on the type of card used in the sale as well as the method and equipment used in the processing.  Cash flow, prompt funding, fees and rates, PCI DSS are essentials for processing success and a casual approach isn't recommended. 

We'll be hearing more about Square for sure - I'll keep you posted - in the mean time - think payments professional to answer your processing questions about rates, equipment and "going mobile with your business".

 

 

 

Ecommerce, SSL and SSL Certificates

I've put this blog off - it can be confusing stuff.  But frankly, given the number of merchants involved in online sales or ecommerce - now's the time.  You need an SSL certificate if you sell online, supply a site log in, process sensitive data or simply want to instill trust.

SSL was introduced in 1994 - and stands for Secure Socket Layer.  SSL is the standard for ecommerce transaction security enabling encryption of all of your customers sensitive data, including credit card and other uniquely identifying information.  Todays recommended minimum encryption standard is 128 bit and in order to provide this you'll need a SSL certificate with SGC (server grade cryptography) capability.

SSL Certificates.  This digital certificate sits on your secure web server and is used to to perform the actual encryption. Each certificate has what is called a private and public key.  The private key encrypts data, the public key deciphers it.  When a customers web browser points to a certified domain - the SSL technology authenticates both the domain and the browser.  A unique session  "key" is established as is an encryption method and a secure transaction can be made. 

There are different types of SSL Certificates such as -

• organizational validated (ov)
• domain validated (dv)
• most recent - extended validated (ev)

SSL Certificates trigger the browser to display a closed padlock and the https prefix in the browser window.  With an EV certificate, besides a more vigorous application process, the browser bar is color coded green to indicate the top validation in SSL and turns red when an unsecure or untrustworthy site is encountered.

Where do you get an SSL certificate?  XBS recommends SSL certificates issued by CA's or certificate authorities.  These businesses verify your domain name, your business and your authority to apply for such a certificate amongst other things based on the type of certificate applied for. 

Your e-commerce payment gateway can make life a little simpler by providing you, the online merchant, with a customizable payments page hosted on their site.  This is the least expensive method, as it uses the gateways SSL certificate (shared) instead of your own.  In addition, the gateway's server stores the sensitive data on it's own PCI DSS compliant server leaving the merchant risk free (regarding data storage). There's a few cons though, the biggest one being your customer leaves your site at the time of payment, as well as a loss of control in the order process.  This might be a great, cost effective approach for a new online merchant. 

If you have a busy site though - you'll probably want your own payments page with your own SSL Certificate.  Pricing is all over the place, and providers offer a variety of types of certificates - so due diligence as usual.   Your web developer or merchant account provider (XBS) can easily assist you in your purchase. Certificates must be renewed.  Some gateways such as authorize.net provide certificates at deeply discounted prices through partnerships with providers.

SSL technology is not an option for ecommerce merchants, it's a must have.  This article only touches on the basics of secure socket layer technology.  Statistics show that our customers are becoming internet savvy and will increasingly refuse to do business with ecommerce merchants who don't display SSL basics and signage. 

So be secure and prosper.

Pin Pads, Benefits of Pin Debit and New PCI DSS Requirements

The acceptance of debit cards is a vital requirement for merchant success. 

Consider VISA's announcement in May of 2009 that for the first time in the company's history, the volume of debit payments surpassed that of credit cards.  Recession news continues to bolster this trend - whether it is due to the diminished availability of credit or a wise consumer approach - all the card networks are reporting healthy growth.

Merchants accept debit cards one of two ways - online - requires a pin pad (PED - pin entry device) or offline (requires a customer signature).  Unless the merchants primary sale or average ticket is less than $25 pin debit costs less than signature debit.

So let's talk pin pads which are an indisputable, worthwhile merchant investment given what you've just read.

Pin pads can be stand along devices - connected by cable directly to your credit card processing terminal and set up for easy customer access and interface or integrated within the credit card terminal itself.  The debit card is swiped through the pin pad and  a 4 digit pin is entered by the customer to authorize the transaction.  The transaction is processed through the ACH processing network and the merchant is funded immediately.  

Each pin pad has a unique encryption security code.  When the pin is entered the pin pad encrypts the number at the point of sale through to the bank, for verification and payment. 

Top pin based debit benefits -

• Reduced Processing Fees
• Fast settlement of funds
• Fewer chargebacks - PIN based debits are not subject to chargebacks
• Transactions cannot be downgraded - as they often are with credit card transactions that don't qualify for the best rates

If you already have a pin pad - you should be on alert that in July 2010 new VISA equipment compliance requirements will be in effect.  Is your equipment up to date? See the PCI Security Standards website list if you're not sure - your PED must be an exact match with the specs on the site.  If you have don't see your device listed, you have the wrong version or you have questions about whether your pin pad is meeting PCI DSS standards - don't wait until July - call XBS @800-347-1090.

PED security is a real issue.  It doesn't take much imagination to grasp the value of cardholder data combined with a debit PIN - the information would give thieves the ability to drain a bank account.  The technical savvy of today's criminal is mind boggling and apparently encryption cracking services and decoding ability has kept pace with security measures.

NOT ONLY does your POS PED need to be on the list - but VISA is further mandating an update of the PED with what's called TDES (triple data encryption standard)- a stronger, more robust encryption standard that serves to reduce further risk of theft of valuable cardholder data.   

Many recently deployed integrated PED's are TDES capable but still must have the TDES keys injected.  Older integrated PED's may not support the new standards and will have to be upgraded to more recent equipment, integrated or, possibly an external pin pad, with a TDES key injected prior to use/shipment.

Moral of the story?  Secure, pin based debit can increase your revenues and cash flow.

• Start processing pin debit and lower your processing costs 
• Ensure your current or new device meets all upcoming July 2010 VISA mandated security requirements and is PCI DSS compliant.

WIN WITH PIN!

(couldn't resist!)

 

 

Recent PCI DSS Breach Focuses on Merchant Responsibility

Recent news that a group of restaurants are pushing a class action lawsuit against Radiant Systems - a Georgia POS vendor and it's Louisiana reseller for allegedly installing a non compliant POS payment processing program and POS equipment- brings culpability to the forefront. 

The restaurants or merchants were notified by the card associations that their systems had been hacked and credit card information had been stolen.  Apparently card data was allegedly being stored by the program - a breach of PCI DSS basics. 

The big news is the card associations immediately penalized the merchants for the breach.  They were not only fined, but charged for the forensic audits and a number of other costs associated with the fraud. Ouch.  Could your business or restaurant sustain the financial drain as well as the reputation damage of such an event? Should it have to? (the essence of the suit is no - that's what the payment processor and POS vendor is for!).

Jury's out still - but either way - it's probably not an issue any size business that is processing credit cards can afford to be lackadaisical about.  Restaurants are typically level III or IV merchants when it comes to compliance - a PCI DSS level with it's fair share of inherent risk.

Merchants should ensure all of the integral parts of their payment processes are PCI DSS compliant - today's pain could be tomorrows relief!

 

 

 

PCI DSS, Compliance and Fraud

If you are currently a merchant in the USA processing credit cards, you should be aware by now that PCI DSS (Payment Card Industry Data Security Standards) are no longer an option.  All merchants, even those that process a single transaction - must become compliant. 

Merchants will pay for the process - a monthly fee passed along by the processor or a single, annual fee.  While XBS is passing along minimal cost to merchants - we are not in any way profiting from the charge.  Our cost is your cost. 

The payment industry has long been dealing with the repercussions, including the substantial costs, of fraud and theft, an issue that intensified with the growth of wireless capability and technology.   The Privacy Rights Clearinghouse - a non- profit consumer advocacy group keeps a chronological report of all data breaches in the US since 2005 - the list is large. Hackers, dishonest employees, stolen laptops etc. - the breadth and depth of incidences is astounding. 

Fraud and theft is an inherent risk in all business - electronic payments is but a singular risk facet in commerce.  There are many others.  We still contend at XBS, that the benefits far outweigh the risks and there seems to be little possibility of a pull back in the industry - customers will not be resorting to "cash" anytime soon.  

It is only too typical that the majority (honest) pay for the minority whom persist in ill gotten gains or dishonest pursuits. 

Our merchants should see our blog on the basics of PCI DSS compliance and make sure they take their SAQ - Self Assessment Questionnaire as advised by their processor or compliance costs will be higher than necessary.  If you have questions about "what to do" please call - credit card processing is an essential business tool, and a privilege.

PCI DSS

The Basics.

PCI DSS (Payment Card Industry Data Security Standards) is now at the forefront of the electronic payments industry.  The proliferation of fraud and risk associated with credit card processing makes these standards to secure cardholder data that is stored, processed or transmitted by merchants and processors an absolute necessity.

PCI DSS is not an option - no matter what size merchant you are.  While the standards are not law - they are being developed by the PCI Data Security Council, an entity founded by American Express, MasterCard, VISA,  DISCOVER and JCB International.  Merchants found not to be in compliance with these standards could end up paying hefty fines or worse, lose the privilege of card processing.

PCI DSS differentiates compliance requirements based primarily on a merchants annual number of card transactions.  Most XBS merchants fall into the level 4 category - see below:

• Level 1 - Merchants from whom cardholder data has been compromised and/or merchants with more than 6 million transactions   annually across all channels - including e-commerce.
• Level 2 - Merchants with between 1 and 6 million credit card transactions annually.
• Level 3 - Merchants with between 20,000 and 1 million credit card transactions annually.
• Level 4 - ALL other merchants.

Compliance for each merchant level:

• Level 1 - Annual onsite PCI data security assessment and quarterly network scans
• Level 2 - Annual self-assessment and quarterly network scans
• Level 3 - Annual self-assessment and quarterly network scans
• Level 4 - Annual self-assessment and annual network scans

PCI DSS is built around a core group of principles and their requirements for all merchants to follow, a number of which represent best business practices for all business and may hopefully, already be in place. They are -

Build and Maintain a Secure Network.

Requirement 1 - Install and maintain a firewall configuration to protect cardholder data.

Requirement 2- Do not use vendor supplied defaults for system passwords and other security parameters

Protect Cardholder Data.

Requirement 3 - Protect stored cardholder data

Requirement 4 - Encrypt transmission of cardholder data across open, public networks.

Maintain a Vulnerability Management Program.

Requirement 5 - Use and regularly update anti-virus software.

Requirement 6 - Develop and maintain secure systems and applications

Implement Strong Access Control Measures.

Requirement 7 - Restrict access to cardholder data by business need to know.

Requirement 8 - Assign a unique ID to each person with computer access

Requirement 9 - Restrict physical access to cardholder data

Regularly Monitor and Test Networks.

Requirement 10- Track and monitor all access to network resources and cardholder data

Requirement 11- Regularly test security systems and processes.

Maintain an Information Security Policy.

Requirement 12: Maintain a policy that addresses information security.