My Merchant Account Blog

Credit Transaction

Tuesday, December 30, 2008

There might be a time where you need to refund a customer, however the transaction is not on the electronic payment gateway.  For example, you might have change electronic payment gateways or the customer no longer has the credit card that was used to purchase the merchandise. 

This feature is usually disabled because of the risks involved.  For example, the merchant could abuse this privilege by crediting his own credit card.  You might have an individual that does the billing, and that person could credit his own credit card, skip town - leaving you with an empty bank account.  Or you might accidentally enter the wrong credit card number in the virtual terminal, thus crediting another person instead of your customer.

In the electronic payment gateway's virtual terminal, look for Credit (instead of Sale).  You should be able to enter the correct information to credit your customer's credit card.  If you do not see this option, contact your merchant account provider to have permission to do a credit transaction.

PCI Myths

Thursday, December 11, 2008

Now that we have talked about PCI Compliance and the six cores:

1. Build and Maintain a Secure Network
2. Protect Cardholder Data
3. Maintain a Vulnerability Management Program
4. Implement Strong Access Control Measures
5. Regularly Monitor and Test Networks
6. Maintain an Information Security Policy

Let us look at a few myths.  These myths could cost you thousands of dollars in fines.

Hackers Only Target Large Companies

Some merchants might think that breaches only happen to the large corporations.  Part of this is true - breaches do happen to large corporations, but smaller merchants are just as vulnerable.  If you have a shopping cart and the code is not kept up-to-date, this could leave you wide open for a data compromise.  If you are storing any cardholder data (the primary account number along with the cardholder's name or expiration date), you need to be PCI compliant.

Processing is Done on the Gateway (or Third Party)

The transaction is done on the electronic payment gateway's secure website or third party processor (3PP) / Internet Payment Service Provider (IPSP) and they are PCI compliant.  This does not mean you are compliant or exempt.  PCI Compliancy is an ongoing process.  The PCI DSS requirements and security assessment procedures include the data security, physical security, and your security policies.

For example, the CISP Compliant list from Visa (3 May 2007), shows that Google Checkout was late in reporting their compliancy to Visa.  And on the 15 Jul 07 CISP Compliant list, Google Checkout was removed because they were over 90 days to file their report.  On the 15 Nov 08 Visa CISP Compliant list, Google Checkout is listed

The Shopping Cart and Hosting Company are PCI Compliant

The shopping cart and hosting company are just a part of being PCI Compliant.  As stated above, it covers your security policies and how you handle the transactions.  For example, your security policy should address how your employees handle cardholder data if an order is taken over the phone.

PCI Only Applies to the IT Department

Unfortunately, this is not the case.  In the example above, the employee handling the order on the telephone is in the sales department.  PCI Compliancy covers all individuals in your company that handle, process, store, or transmit the cardholder data.

We Only Handle Two Orders a Month

Breaches can happen to any company, no matter the size.  Since your company has access to cardholder data, you need to be PCI Compliant.

PCI Compliancy Is Too Much

While the guidelines seem intimidating, most of them are probably already being done by your company.  The guidelines help you with the specifics and an effective way to secure cardholder data.

We Are PCI Compliant

Just because you have completed the self-assessment questionnaire and had a company scan your website does not mean you are protected from breaches.  Compromises can still happen to a PCI Compliant merchant.

Maintain an Information Security Policy

Monday, December 08, 2008

The last core of Payment Card Industry Data Security Standard (PCI DSS) only has one requirement

• Maintain an Information Security Policy

Companies should have a strong security policy in place that all employees should sign and abide to.  The employees should understand the sensitivity of the data and what their responsibilities are in protecting this data.  The security policy should be followed stringently.  New employees should be made aware of the security policies and made to sign they understand their duties and responsibilities.

The policy should assign a team or individual to security management to ensure policies are disseminated accordingly.

The policy should address what happens when a compromise occurs.  It should help to identify who should be called, no matter the time of day.  The plan should include continuity procedures, data backup processes, roles and responsibilities, and a contact strategy (for example, contacting the credit card associations).

You should also review the PCI DSS Requirements and Security Assessment Procedures for the complete requirement.  It will go into complete detail of what your information security policy should contain.

Regularly Monitor and Test Networks

Sunday, December 07, 2008

The fifth core of Payment Card Industry Data Security Standard (PCI DSS) consists of two requirements:

• Track and monitor all access to network resources and cardholder data
• Regularly test security systems and processes

Track and Monitor All Access to Network Resources and Cardholder Data

We have said it in the past few posts, but it bears saying again.  Audit trail history should be retained for at least one.  These logs should provide the company with a

• Unique User Identification
• Type of Event
• Date and Time
• Origination of Event
• Success or Failure Indication
• Identity / Name of Affected Data, System Components, Resources

These logs should be secure and unable to be altered by anyone and have limited viewing.  Times on all systems should be synchronized.  Logs should be reviewed daily for unknown events.  It sometimes takes days or weeks before a breach is reported by a cardholder.

Regularly Test Security Systems and Processes

Systems should be scanned to discover potential vulnerabilities.  A vulnerability scan is an automated tool run against external and internal access points and servers on the network that will help identify ports and vulnerabilities that could be exploited by hackers.  If any vulnerabilities are detected, steps should be taken to fix them immediately.  Network intrusion detection systems should also be in place.

Approved Scanning Vendor

Most merchants will be required to do have a quarterly scan completed by an Approved Scanning Vendor (ASV). Approved Scanning Vendors (ASV) can complete the quarterly scan for your company.  Only choose a vendor that is listed Approved Scanning Vendors web page.  Otherwise, you might compromise your data or the scan will not be accepted by the council.  The scan requirements are quite rigid - all 65,535 ports will be scanned.  Any vulnerability that is rated between three to five must be fixed.  You will also get two reports:

• An executive summary report with a PCI approved compliance statement suitable for submission to acquiring banks for validation
• A technical report that details all vulnerabilities detected with solutions

Selecting a PCI Network Security Testing Service

While there are a number of Approved Scanning Vendors listed, there are three critical things to look for when choosing a company:

1. Accuracy:  False positives can increase the activities and costs that are associated with these false positives (and even false positives).  You do not want the company to generate a large number of false positives / false negatives that will increase the amount of time you have to work through each issue.
2. Efficient Vulnerability Remediation Process:  The company should offer technical support to fix each issue found.
3. Automated Report Preparation and On-Line Filing:  This will reduce your work and time you spend on getting PCI compliance if the company offers automatic preparation and electronically filing.

Qualified Security Assessor

Large merchants that are considered Level One (or merchants that have had a data breach) are required to have an on-site security audit performed by a Qualified Security Assessor (QSV).  These vendors are authorized to perform the annual audits. QSAs are companies that assist organizations in reviewing the security of its payments transaction systems and have trained personnel and processes to assess and validate compliance with PCI DSS.

Payment Card Industry Data Security Standard

The Payment Card Industry Data Security Standard (PCI DSS) is the global standard that any business of any size should abide by in order to accept credit cards.  This includes storing or processing any cardholder data.

Businesses should access any type of vulnerability that might pose a compromise of cardholder data.  This vulnerability could be in the process or transmission of the cardholder information.  It could also be when the card is given to an employee to scan. 

Once the vulnerabilities are identified, steps should be taken immediately to fix any vulnerabilities, i.e. software code and updates.  All steps should be documented and back-out procedures in place just in case.

Regular reports are required to be submitted to the acquiring bank and card associations.  A quarterly scan report is required by a Approved Scanning Vendor (ASV).  Businesses that do have a high number of transactions might also be required to have a annual on-site audit by a Qualified Security Assessor (QSA).

Complying with PCI DSS

While the card organizations came together to help form the PCI DSS council to help set the standards, each card association (brand) has its own security program for compliance:

• MasterCard Worldwide: Standard Data Protection (SDP)
• American Express: Data Security Operating Policy (DSOP)
• Discover Financial Services: Discover Information Security & Compliance (DISC)
• Visa Incorporated: Cardholder Information Security Program (CISP)
• JCB International: JCB Data Security Program

Implement Strong Access Control Measures

Saturday, December 06, 2008

The fourth core of PCI DSS is Implement Strong Access Control Measures and is comprised of three requirements:

• Restrict access to cardholder data by business need-to-know
• Assign a unique ID to each person with computer access
• Restrict physical access to cardholder data

This can be accomplished easily by ensuring each employee has his / her own unique ID to sign into the systems.  Ensure that the employee has access to only what he / she needs.  For example, an employee who is assigned to enter / update product information and inventory does not have the need to see the customer / cardholder data.

Restrict Access to Cardholder Data by Business Need-To-Know

As with the example above, the employees' duties need to be fully documented. These duties will help to explain what data the employees needs to have access.  Limiting access to those with a strong business reason for the access will help your organization prevent mishandling of cardholder data through inexperience or malicious intentions.

Assign a Unique ID to Each Person with Computer Access

Each employee should have his / her own unique ID to access your system.  By ensuring each employee has his / her own unique ID, an organization can maintain individual responsibility for actions and have an audit trail per employee.  Do not create generic IDs, i.e. billing, stocking, etc.  Create unique IDs based on the individual, not the job.

The employees should not share their passwords with anyone.  Other methods to authenticate users can be biometrics or token devices.  Two factor authentication should be used for remote access for additional security.  Passwords should always be encrypted during transmission and storage.  Do not allow employees to email their passwords.  Also, verify the identity of the individual before changing a password.  Some hackers might call the help desk claiming they cannot access their account.  Passwords should also be unique for each new individual.  If you use the same password, it might easily be discovered used to gain access.

Terminated employees should be removed from the system immediately.  Policies should be in place by human resources to let the proper department know of the termination.  Accounts should also be monitored for inactivity.  If activity has not occurred within 90 days, the account should be deleted.

As discussed on Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters, passwords should consist of both numeric and alphabetic characters.  Passwords should be at least seven characters and changed every 90 days.  Individuals should not be allowed to use any of the last four passwords.

Restrict Physical Access to Cardholder Data

Facility entry controls should be used and enforced by the organization where cardholder data is stored, processed, or transmitted.  Logs of entry should be maintained for at least three months unless otherwise restricted by law.  Cameras should also be used to monitor sensitive areas.

Visitors

Procedures should be in place to help distinguish between employees and visitors.  A visitor log should be used to maintain a physical audit trail and kept for at least three months (unless prohibited by law). 

Visitors should:

1. Be authorized before entering any area where cardholder data is processed or maintained
2. Be given a badge or access key the specific areas he / she needs to be in and the badge should expire
3. Ensure the visitor returns the badge before leaving

Management and Storage of Paper and Electronic Media

This also includes backups which may contain cardholder data.  You can contract with a commercial data-storage facility or for a smaller entity, consider a safe-deposit box.  Computers, electronic media, networking and communications hardware, telecommunication lines, paper receipts, paper reports, and faxes are some examples that will need to be secured.

The media should be marked confidential and send the media only with a secure courier.  Do not use a system where a tracking system is not in place.  Cardholder data that leaves the facility should be signed for by an authorized person.  Strict control over the storage and accessibility of the media should be maintained at all times.

If the cardholder data is no longer needed for business purposes, it should be destroyed.  Paper can be cross-cut, burned, or turned into pulp.  Electronic media should be purged, degaussed, or shredded so data can no longer be accessed.

Maintain a Vulnerability Management Program

Friday, December 05, 2008

There are two requirements in this third core of PCI DSS (Maintain a Vulnerability Management Program):

• Use and regularly update anti-virus software or programs
• Develop and maintain secure systems and applications

In this core, it helps to know your vulnerabilities / weaknesses and how you can fix them before problems will occur.

Use and Regularly Update Anti-Virus Software or Programs

Anti-virus programs should be installed on each computer that uses your mail server and should be updated consistently.  The anti-virus program should be able to generate logs for you to review to ensure the updates have been applied and if any potential threats were received.  The logs should also be able to tell you what happened to these threats. 

The anti-virus program should also protect your systems of any other malicious software, including spyware, malware, adware.

Develop and Maintain Secure Systems and Applications

Hackers are consistently attempting to find vulnerabilities in software and components.  Security patches should be installed as soon as possible, but no later than one month of its release.  You should subscribe to a service that will inform you of any potential vulnerabilities, like the Multi-State Information Sharing and Analysis Center (MS-ISAC) or CERT.

Development, testing, and production environments should be completely separate since the staging environment is sometimes less secure than the production environment.  Personnel duties should be separated as well to limit the access to cardholder data.  When testing, PANs should not be used.  Some electronic payment gateways will allow you to replicate the transaction process using test credit card numbers.  When you are ready to go live, all test data and custom application accounts / usernames / passwords should be removed.

Change of Record

Change control procedures should be regimented and documented.  These procedures should include:

• Documentation of impact
• Management sign-off by appropriate parties
• Testing of operational functionality
• Back-out procedures

Without the proper change controls in place, a breach could potential occur.  This breach could inadvertently happen based on the employee's experience or background.  Background checks should be adequate to prevent untrustworthy or untrained individuals access to software code.

Secure Coding Guidelines

Software applications and code should be built based on the industry's best practice of secure coding - consider the guidelines at the Open Web Application Security Project (OWASP) or CERT Secure Coding Standards.  Data should be validated before being sent to the web application.  Error handling should also be reviewed.  For example, a username and password is entered into your web application.  An error message is produced saying "incorrect password".  This lets the hacker to assume he now has a username to gain access, and he should focus on a password.  Using more generic error messages like "data could not be verified" would be better.

Build and Maintain a Secure Network

Thursday, December 04, 2008

There are two requirements in the first core of PCI DSS (Build and Maintain a Secure Network)

1. Install and maintain a firewall configuration to protect cardholder data.
2. Do not use vendor-supplied defaults for system passwords and other security parameters.

Firewalls can be either hardware or software, but firewall hardware usually tends to be more secure.  Firewalls though are key in helping to protects your servers from hackers.  The firewall should examine all networking traffic and block traffic that does not meet certain requirements.

When you first buy a shopping cart or download a free one, you need a way to access the database.  Usually this is done via web interface in the admin section of the cart.  Most carts give an easy password to enter, like password or 123456.  Merchants must change this password immediately and only allow certain employees access to the data.  Some carts will also allow you to set up users to have access to just specific data, i.e. inventory, mailing list, etc.  If your cart supports this, consider using it as well.

Install and Maintain a Firewall Configuration to Protect Cardholder Data

Usually this requirement is done at the hosting or data center level.  Some hosting and data center companies will tell you they are PCI compliant.  This usually will mean their firewall is set up properly to allow certain protocols besides the Hypertext Transfer Protocol (HTTP), Secure Shell (SSH), Secure Sockets Layer (SSL), Virtual Private Network (VPN), and File Transfer Protocol (FTP).  Compromises usually will happen on unused or insecure ports (remember there are over 60,000 ports and most need to be blocked to avoid exploitations.

There are many protocols that a company might need (or the protocol is enabled by default).  These protocols are used by hackers to breach security in a network.  The protocols should be well documented and justified and security features should be in place, documented, and implemented.  The firewall rules should be reviewed every quarter.

You should also prohibit direct public access between the external networks and any system that might store cardholder data like logs, databases, trace files.

Do Not Use Vendor-Supplied Defaults for System Passwords and Other Security Parameters

Usually the first step a hacker might try to gain access into your system is the default passwords (password, test, 123456, admin, etc).  These passwords are usually also found on the shopping cart vendor's website FAQ section or in the cart download.  These passwords should be changed before installation or immediately after (to help prevent hackers from possibly creating another administrator user account.

The password that you create should consider of numbers, letters, and special characters.  Try not to use birthdays and family, city and street names.  Your password should be changed at least every six months.  Try not to use your password on any computer that is accessible to the public (library, Internet shop, etc).  Ask your shopping cart vendor if any special characters are not allowed, like ",:,^,&,\,/.  And find out if the password is case sensitive.  This will help to increase the security of your passwords.  Some examples of passwords could be something like

• 0t4ly31p (using numbers and lowercase letters)
• AI6GQ44O (using numbers and uppercase letters)
• lSwSOpf1 (using number and lowercase / uppercase letters
• uq6"=~$i (using number, lower case letters, and symbols)
• 9R1`~hF6x (using numbers, lowercase / uppercase letters, and symbols)

As you can see, these would be more difficult for hackers.  And don't keep your password written down on your desk or anything.

Your server should serve one primary function, i.e. as a web server or database server.  Having your database server on your web server could be at risk since the web server is directly connected to the Internet.

Shared Hosting

Most Level 4 Merchants and some Level 3 Merchants might rely on a hosting company.  Usually these hosting companies will put hundreds, if not thousands, of other websites on the same server.  This is commonly known as shared hosting.  There are some steps the shared hosting company needs to comply with to help you get PCI Compliant:

• If a merchant is allowed to run an application on the server, that application should be ran with that merchant's ID and not a privileged user (which would possibly have access to other merchant's cardholder data.  To ensure that the merchant only has access to their own information
  1. Privileges of the merchant's web server ID
  2. Permissions granted to read, write, and execute files
  3. Permissions granted to write to system binaries
  4. Permissions granted to the merchant's log files
  5. Controls to ensure one merchant cannot monopolize the system resources
• Logs specific to the merchant's cardholder data should be made available to the merchant to ensure no compromises have occurred
• The hosting company must enable a process to provide quick and easy response in the event that a forensic investigation is needed for a potential compromise that is specific to that merchant

Payment Processing Recommendation and Integrating

Experts Exchange is a collaboration of experts and IT professionals from around world helping to solve problems and share knowledge.  Experts Exchange has over 900 zones currently.  They recognize the experts on a point-based system.  One of the writers on this blog, Corey Bryant, has achieved guru status for Payment Processing Recommendation and Integrating.

Protect Cardholder Data

There are two requirements in this second core of PCI DSS (Protect Cardholder Data):

1. Protect stored cardholder data
2. Encrypt transmission of cardholder data across open, public networks

The Primary Account Number (PAN) should be protected at all times.  The PAN should not be stored unless it is absolutely necessary and should always be encrypted wherever it is stored.

Protect Stored Cardholder Data

A data retention and disposal policy should be created.  Storage and retention should be limited to the time required for business, legal, or regulatory purposes.  However, the CVV2 / CVC2 / CID / CAV2 should not be stored / retained for any purpose.  If this data is stored, it violates the card associations regulations which can lead to fines and penalties.  Your merchant account provider might even add you to the MATCH / TMF list.

It is understood that some employees will have the need to see the PAN from time to time in the course of their duties at work.  Encryption keys should be used to view the PAN.  Key distribution and storage should be secure.  Keys should be changed at least once a year and old keys destroyed.  If you suspect a key has been compromised, it should be replaced immediately.

If for some reason the company is unable to encrypt the cardholder data, refer to Self-Assessment Questionnaire A and Attestation of Compliance: Appendix B.

Encrypt Transmission of Cardholder Data Across Open, Public Networks

Sensitive information must be encrypted during transmission over networks because it is easy for hackers to intercept / divert traffic during the transmission.  Never send unencrypted account numbers by e-mail. 

Cardholder Data and Sensitive Authentication Data Elements

Cardholder data includes the Primary Account Number (PAN), cardholder name, expiration date, service code, the CAV2 / CVC2 / CID / CVV2, PIN, and other sensitive information that is found on the full magnetic stripe.  There are certain fields that cannot be stored and other fields that can be stored as long as it is encrypted.

Never store the  CAV2 / CVC2 / CID / CVV2 in your database or logs.  This is a direct violation of the requirements.  If you have to store the PAN for any reason, it should always be encrypted.  If it needs to be displayed, it should be masked unless the personnel is authorized with a specific need to see the full account number.  You can display the first six digits and the last four digits if necessary, but that is the maximum number of digits that you should display.  Some websites might show the customer the last four digits just so he can confirm what card number is on file with the merchant.

The cardholder name, service code, and expiration date can be stored, but must be encrypted if this information is stored in conjunction with the PAN.  PCI DSS does not apply if PANs are not stored, processed or transmitted. 

The PAN should be unreadable anywhere it is stored, for example backups, logs, or any other type of media that is used to store the numbers.  Developers can consider using truncation, strong cryptography, index tokens and securely stored pads, or a one-way hash based on strong cryptography.

The PAN should never be sent in unencrypted emails (which almost all emails are just plain text), instant messaging, instant chats, or over any unsecured transmission.  If you are asking customers to send you’re their PAN via a form to email method, you must make sure the email is secure.  Just because they are submitting the form with an https:  in the URL does not mean the email is secure and encrypted.

Card Validation Value or Code

The card association developed a three or four digit code to help prevent fraud on all keyed transactions. This code is uniquely assigned to each card and ties the card account number to the card itself.

• CVV2: Card Verification Value 2 (Visa)
• CVC2: Card Validation Code 2 (MasterCard)
• CID: Card Identification Number (American Express and Discover)
• CAV2: Card Authentication Value 2 (JCB)

Winning the PCI Compliancy War

Wednesday, December 03, 2008

A lot of merchants hear PCI DSS (Payment Card Industry Data Security Standard) and figure they don't have anything to worry about.  Unfortunately that is not the case.  Every merchant needs to start reading and learning about PCI.

Let's start with just the basics and later we can talk about the requirements.  MasterCard created their own plan called Security Data Protection (SDP).  Visa actually had two programs: (international) Account Information Security (AIS) and Cardholder Information Security Plan (CISP).  In 2006, five card associations (payment brands) including Visa International, MasterCard, JCB, Discover Financial Services, and American Express came together to jointly form the PCI Security Standards Council.

The PCI DSS requirements apply to merchants, network members, and service provider that store, hold, process, or transmit cardholder data.  There are twelve requirements divided into six categories:

• Build and Maintain a Secure Network
• Protect Cardholder Data
• Maintain a Vulnerability Management Program
• Implement Strong Access Control Measures
• Regularly Monitor and Test Networks
• Maintain an Information Security Policy

By now, you should know what level you are.  Chances are you are probably Level 4 or maybe Level 3.  In any event, you will need to complete the Self-Assessment Questionnaire A and Attestation of Compliance (PCI DSS version 1.2 PDF) unless you are a Level One merchant.

Approved Scanning Vendors

Approved Scanning Vendors (ASV) can complete the quarterly scan for your company.  Only choose a vendor that is listed Approved Scanning Vendors web page.  Otherwise, you might compromise your data or the scan will not be accepted by the council.  The scan requirements are quite rigid - all 65,535 ports will be scanned.  Any vulnerability that is rated between three to five must be fixed.  You will also get two reports:

• An executive summary report with a PCI approved compliance statement suitable for submission to acquiring banks for validation
• A technical report that details all vulnerabilities detected with solutions

Selecting a PCI Network Security Testing Service

While there are a number of Approved Scanning Vendors listed, there are three critical things to look for when choosing a company:

1. Accuracy:  False positives can increase the activities and costs that are associated with these false positives (and even false positives).  You do not want the company to generate a large number of false positives / false negatives that will increase the amount of time you have to work through each issue.
2. Efficient Vulnerability Remediation Process:  The company should offer technical support to fix each issue found.
3. Automated Report Preparation and On-Line Filing:  This will reduce your work and time you spend on getting PCI compliance if the company offers automatic preparation and electronically filing.

Complying with PCI DSS

While the card organizations came together to help form the PCI DSS council to help set the standards, each card association (brand) has its own security program for compliance:

• MasterCard Worldwide: Standard Data Protection (SDP)
• American Express: Data Security Operating Policy (DSOP)
• Discover Financial Services: Discover Information Security & Compliance (DISC)
• Visa Incorporated: Cardholder Information Security Program (CISP)
• JCB International: JCB Data Security Program

Breaking Down the Levels of PCI DSS

Tuesday, December 02, 2008

The Payment Card Industry Data Security Standard ((PCI DSS) helps to ensure that cardholder data is secure, whether in processing the transaction or storing the credit card number.  PCI has been around for quite a few years, but now more and more merchants are hearing about it.

PCI DSS Merchant Levels

Merchants are divided into four categories:

• Level One: Processing more than six million transactions per year or has had a security breach with cardholder data compromised
• Level Two: Processing less than six million but more than 150,000 per year
• Level Three: Processing less than 150,000 but more than 20,000 transactions per year
• Level Four: Processing less than 20,000 transactions per year

When version 1.1 was released, it combined all transactions instead of separating between Visa and MasterCard transactions.  Also these transactions are determined by your company, not per merchant account.  So let's say Merchant Account A is processing 80,000 transactions a year and Merchant Account B is processing 100,000 transactions a year, you would be considered a Level Two Merchant.

Level One Merchants

Compliance validation has been required for merchants that process over 6 million (Visa) transactions a year since September 30, 2004.  MasterCard required Level One merchants be compliant by June 30, 2005.  An on-site security audit is also required annually with a network scan every quarter.

Level Two Merchants

Visa required Level Two merchants be PCI compliant by September 20, 2007. MasterCard is requiring the Level Two merchants be compliant by December 31, 2008.

Level Three Merchants

Both Visa and MasterCard required Level Three merchants to be compliant by June 30, 2005.

Level Four Merchants

There is no set date for Level Four merchants.  This is determined by your merchant account provider or the acquiring bank.  However, if you are not compliant and a breach occurs, you can be fined $500,000 or more by the card associations.  If you are compliant and compromised, those fees might be waived or reduced.  It would be in your best interest to become compliant if you have not already.

PCI DSS Version 1.2

Beginning on October 1, 2008, the PCI Security Standards Council released version 1.2 (see summary of PCI changes).  You can review the Self-Assessment Questionnaire A and Attestation of Compliance to help you get started.  Typically, Levels Two, Three, and Four Merchants will need to complete this Questionnaire.