Payment Card Industry Data Security Standard (PCI DSS)

The PCI-DSS is a security standard for organizations that handle branded credit cards from the major card including Visa, MasterCard, Amex, Discover, and JCB. It is designed to ensure that ALL companies that process credit card information maintain a secure environment.

PCI applies to organization or merchant, that has a Merchant ID (MID), regardless of size or number of transactions, that accepts credit card.

Merchants will fall into one of the four merchant levels based on Visa transaction volume over a 12-month period.

 

Merchant Level	Description
1	Any merchant — regardless of acceptance channel — processing over 6M Visa transactions per year. Any merchant that Visa, at its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the Visa system.
2	Any merchant — regardless of acceptance channel — processing 1M to 6M Visa transactions per year.
3	Any merchant processing 20,000 to 1M Visa e-commerce transactions per year.
4	Any merchant processing fewer than 20,000 Visa e-commerce transactions per year, and all other merchants — regardless of acceptance channel — processing up to 1M Visa transactions per year.

 

Does is each location required to validate PCI Compliance for multiple business locations?

If a business locations process under the same Tax ID, then you are only required to validate once annually for all locations.

Penalties for non-compliance

The payment brands may fine an acquiring bank $5,000 to $100,000 per month for PCI compliance violations. The banks will pass this fine along until it eventually hits the merchant. The bank will also terminate your relationship or increase transaction fees.

PCI Compliance Manager

To help you achieve and report compliance, we have Trustwave PCI Compliance Manager. It’s an online portal that enables you to understand requirements that apply to your business, and guides you through your self-assessment, step by step.

If you have any questions regarding your PCI Compliance please call our office at 888-996-2273. We would be more than happy to help.

 

 

 

 

Posted in Best Practices for Merchants, Credit Card Security, Payment Card Industry PCI Security Tagged with: banks, credit cards, merchant, PCI-DSS, Security, transactions

UNENCRYPTED PAYMENT CARD DATA

Businesses continue to struggle with the prohibited storage of unencrypted customer payment data. The Payment Card Industry Data Security Standard (PCI DSS), merchants are instructed that, Protection methods are critical components of cardholder data protection in PCI DSS Requirement.

PCI DSS applies to every company that stores, processes or transmits cardholder information. Regardless of the size or type of business you operate, the number of credit card transactions you process annually or the method you use to do so, you must be PCI compliant.

Data breach is not a limited, one-time occurrence. This is why PCI compliance is required across all systems used by merchants.

Encryption and Tokenization is a strong combination to protect cardholder at all points in the transaction lifecycle; in use, in transit and at rest.

National Transaction’s security solutions provide layers of protection, when used in combination with EMV and PCI-DSS compliance.

Encryption is ideally suited for any businesses that processes card transactions in a face to face or card present environment. From the moment a payment card is swiped or inserted at a terminal featuring a hardware-based, tamper resistant security module, encryption protects the card data from fraudsters as it travels across various systems and networks until it is decrypted at secure data center.

Tokenization can be used in card not present environments (travel merchants) such as e-commerce or mail order/telephone order (MOTO), or in conjunction with encryption in card present environments.  Tokens can reside on your POS/PMS or within your e-commerce infrastructure at rest and can be used to make adjustments, add new charges, make reservations, perform recurring transactions, or perform other transactions in use. Tokenization protects card data when it’s in use and at rest. It converts or replaces cardholder data with a unique token ID to be used for subsequent transactions.

The sooner businesses implement encryption and tokenization the sooner stored unencrypted data will become a thing of the past.

 

Posted in Best Practices for Merchants, Travel Agency Agents Tagged with: card, card data, card present, cardholder, compliance, credit card, customer, data, data breach, data security, e-commerce, EMV, encryption, Mail Order/Telephone Order, merchants, moto, payment, Payment Card Industry, PCI-DSS, POS, secure data, Security, terminal, tokenization, tokens, travel, travel merchants

Combat Fraud!

Combat Fraud With Layered Approach!

Encryption and Tokenization a strong combination to protect cardholder data at all points in the transaction cycle.

Encryption – the strongest protection for card data when it’s in transit. From the moment a payment card is swiped or dipped at a terminal featuring a hardware-based, tamper resistant security module. Encryption protects the card data from fraudsters as it travels across various systems and networks until it is decrypted at secure data center. Encryption is ideally suited for any businesses that processes card transactions in a face to face or card present environment.

Tokenization – protects card data when it’s in use and at rest. It converts or replaces cardholder data with a unique token ID to be used for subsequent transactions. This eliminates the possibility of having card data stolen because it no longer exists within your environment. Tokens can be used in card not present environments such as e-commerce or mail order/telephone order (MOTO), or in conjunction with encryption in card present environments. Tokens can reside on your POS/PMS or within your e-commerce infrastructure at rest and can be used to make adjustments, add new charges, make reservations, perform recurring transactions, or perform other transactions in use.

A layered approach can be the most effective way to combat fraud. Security solutions that provide layers of protection, when used in combination with EMV and PCI-DSS compliance; to ensure you’re doing all you can to protect cardholder data from increasingly complex and evolving security threats.

Posted in Best Practices for Merchants, Credit Card Security, e-commerce & m-commerce, EMV EuroPay MasterCard Visa, Mail Order Telephone Order, Mobile Point of Sale, Payment Card Industry PCI Security, Point of Sale Tagged with: card data, card present, card transactions, card-not-present, cardholder, e-commerce, EMV, encryption, mail order, moto, payment card, PCI-DSS, PMS, POS, telephone order, terminal, tokenization, tokens

Know Your Business

There are numbers of guidelines issued for accepting card payments, and merchants are expected to understand them all. To avoid issues down the road know a few basic rules in order to keep your business going without being penalized.

There’s a lot of ways to process a credit card: In-store, online, and by phone. There’s also different ways to pay and different brands of cards.

In-store and Card-not-present policies.

In-Store Policies:

• Always verify that the person presenting the card is the cardholder
• Ask for a 2nd ID for comparison
• Cards are non-transferable, cardholder MUST be present for purchase
• Compare the signature on the back of the card with that of the person who presents the card
• Inspect the card to confirm that it’s not visibly altered or mutilated
• Validate the card’s expiration date

Online/Phone Payment Policies: Card-not-present transactions

• Card account number
• Card billing address
• CID (3 digits on back of card OR 4 on the front)
• Card expiration date
• Card member’s home or billing telephone number
• Card member name (as it appears on the Card)

Rules for Visa, MasterCard and Amex that merchants need to know:

• Never store cardholder data on any systems to help minimize the risk of fraud and protect your business from potential chargebacks.

Complying with Federal Laws, State Laws and PCI

• A merchant should be familiar with and abide by Federal Laws regarding accepting credit cards. The Fair Credit Reporting Act is the federal law that establishes the foundation of consumer credit rights. This law regulates the collection and use of consumer credit information by merchants.
• Check state laws on the use of consumer credit information and accepting credit cards. Not all states have additional laws that regulate credit card practices, but some (such as California) prohibit merchants from requesting/requiring a customer to provide any personal information (like their address or telephone number) on any form involved with their credit card transaction. So, it is advised that merchants inquire about further information in their particular state.
• The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that all companies processing, storing, or transmitting credit card information uphold a secure environment. These rules essentially apply to any merchant that has a Merchant ID (MID). If you are a merchant that accepts credit card payments, you are required to comply with the PCI Data Security Standard, large or small businesses.

EMV Liability Shift Set By Visa and MasterCard as of October 1^st

U.S. banks and credit card companies are now using the EMV (Europay, MasterCard, and Visa) technology. The EMV liability shift for fraud carried out in physical stores with counterfeit cards belongs to the merchant if it has not yet upgraded its POS system to accept EMV-enabled chip cards. While issuers absorb losses under card-network rules, that burden will shift to acquirers in cases where the fraud occurs at merchants unprepared for EMV.

It’s good to know every aspect of your business. The above guidelines are part of a business that every merchants should be familiar with. The main reason for these rules is to protect your business and keep your customer’s payment card data safe and secure.

To start accepting more credit cards give us a call now at 888-996-2273. We have the latest terminals that’s EMV/NFC capable.

 

 

Posted in Best Practices for Merchants, Credit Card Security, EMV EuroPay MasterCard Visa, Payment Card Industry PCI Security Tagged with: amex, card network, card payments, card-not-present, chargebacks, chip cards, credit card, credit card companies, Data Security Standard, EMV, EuroPay, MasterCard, merchants, MID, Payment Card Industry, PCI-DSS, POS system, U.S. banks, visa

Changes In PCI DSS

When the PCI Security Standards Council (PCI SSC) launched PCI DSS v3.0 in January 2014, businesses were given one year to implement the updated global standard. Now that the deadline is fast approaching, interest is picking up in what v3.0 entails. On Jan. 1, 2015, version 3.0 of the Payment Card Industry (PCI) Data Security Standard (DSS) will reach year one of its three-year lifecycle.

Trustwave, a global data security firm, is on the frontlines of helping secure the networks of merchants and other businesses on the electronic payments value chain against data breaches. As an approved scanning vendor, Trustwave is used by businesses to achieve and validate PCI DSS compliance.

PCI DSS v3.0 is business as usual for the most part, except for a few changes from v2.0 that considers impactful for large swaths of merchants. The top three changes involve e-commerce businesses that redirect consumers to third-party payment providers. The expansion of penetration testing requirements and the data security responsibilities of third-party service providers.

Penetration testing

Penetration testing is the way in which merchants can assess the security of their networks by pretending to be hackers and probing networks for weaknesses. V3.0 of the PCI DSS mandates that merchants follow a formal methodology in conducting penetration tests, and that the methodology goes well beyond what merchants can accomplish using off-the-shelf penetration testing software solutions.

Merchants that are self assessing and using such software are going to be surprised by the rigorous new methodology they are now expected to follow.

Additionally, penetration testing requirements in v3.0 raises the compliance bar for small merchants who self assess. Those merchants could lower the scope of their compliance responsibilities by segmenting their networks, which essentially walls off data-sensitive areas of networks from the larger network. In this way merchants could reduce their compliance burdens and not have to undergo penetration testing.

Not so in v3.0. If you do something to try to reduce the scope of the PCI DSS to your systems, you now need to perform a penetration test to prove that those boundaries are in fact rigid.

Redirecting merchants

The new redirect mandate as affecting some, but not all, e-commerce merchants that redirect customers, typically when they are ready to pay for online purchases to a third party to collect payment details. If you are a customer and you are going to a website and you add something to your shopping cart, when it comes time to enter in your credit card, this redirect says I’m going to send you off to this third party.

The redirect can come in several forms. It can be a direct link from the e-commerce merchant’s website to another website, such as in a PayPal Inc. scenario, or it can be done more silently.

An example of the silent method is the use of an iframe, HTML code used to display one website within another website. Real Estate on the merchant’s website is used by the third-party in such a way that consumers don’t even know that the payment details they input are being collected and processed, not by the e-commerce site, but by the third party.

Another redirect strategy is accomplished via pop-up windows for the collection of payments in such environments as online or mobile games. In-game pop-up windows are typically used to get gamers to pay a little money to purchase an enhancement to their gaming avatars or advance to the next level of game activity.

For merchants that employ these types of redirect strategies, PCI DSS v3.0 makes compliance much more complicated. In v2.0, such merchants that opted to take Self Assessment Questionnaires (SAQs), in lieu of undergoing on-site data security assessments, had to fill out the shortest of the eight SAQs. But in v3.0, such redirect merchants have to take the second longest SAQ, which entails over 100 security controls.

The PCI SSC made this change because of the steady uptick in the number and severity of e-commerce breaches, with hackers zeroing in on exploiting weaknesses in redirect strategies to steal cardholder data. Also, redirecting merchants may be putting themselves into greater data breach jeopardy when they believe that third-party payment providers on the receiving end of redirects are reducing merchants’ compliance responsibilities, when that may not, in fact, be the case.

Service providers

Service provider is any entity that stores, processes or transmits payment card data. Examples include gateways, web hosting companies, back-up facilities and call centers. The update to the standard directs service providers to clearly articulate in writing which PCI requirements they are addressing and what areas of the PCI DSS is the responsibility of merchants.

A web hosting company may tell a merchant that the hosting company is PCI compliant. The merchant thought, they have nothing left to do. The reality is there is still always something a merchant needs to do, they just didn’t always recognize what that was.

In v3.0, service providers, specifically value-added resellers (VARs), also need to assign unique passwords, as well as employ two-factor authentication, to each of their merchants in order to remotely access the networks of those merchants. VARs often employ weak passwords or use one password to access multiple networks, which makes it easier for fraudsters to breach multiple systems.

The PCI SSC is trying to at least make it more difficult for the bad guys to break into one site and then move to the hub, so to speak, and then go to all the other different spokes with the same attack.

Overall, v3.0 is more granular by more accurately matching appropriate security controls to specific types of merchants, even though the approach may add complexity to merchants’ compliance obligations. On the whole a lot of these changes are very positive.

 

Posted in Best Practices for Merchants, Credit Card Security, Payment Card Industry PCI Security Tagged with: (PCI SSC), call centers, cardholder data, consumers, credit-card, customers, data breaches, data security assessments, Data Security Standard, e-commerce breaches, e-commerce businesses, e-commerce merchant's website, electronic payments, global data security, global standard, Merchant's, merchant’s website, mobile, networks, payment, payment card data, Payment Card Industry, payment providers, PCI Security Standards Council, PCI-DSS, Penetration testing, Service providers, shopping cart, software solutions, web hosting, website

More about CVV Number

The CVV Number (Card Verification Value) on your credit card or debit card is a 3 digit number on VISA, MasterCard and Discover branded credit and debit cards. On your American Express branded credit or debit card it is a 4 digit numeric code.

The codes have different names:

American Express – CID or unique card code.

Debit Card – CSC or card security code.

Discover  – card identification number (CID)

Master Card – card validation code (CVC2)

Visa  – card verification value (CVV2) 

CVV numbers are NOT your card’s secret PIN (Personal Identification Number).

You should never enter your PIN number when asked to provide your CVV. (PIN numbers allow you to use your credit or debit card at an ATM or when making an in-person purchase with your debit card or a cash advance with any credit card.)

Types of security codes:

CVC1 or CVV1, is encoded on track-2 of the magnetic stripe  of the card and used for card present transactions. The purpose of the code is to verify that a payment card is actually in the hand of the merchant. This code is automatically retrieved when the magnetic stripe of a card is swiped on a point-of-sale (card present) device and is verified by the issuer. A limitation is that if the entire card has been duplicated and the magnetic stripe copied, then the code is still valid.

The most cited, is CVV2 or CVC2. This code is often sought by merchants for card not present transactions occurring by mail or fax or over the telephone or Internet. In some countries in Western Europe, card issuers require a merchant to obtain the code when the cardholder is not present in person.

Contactless card and chip cards may supply their own codes generated electronically, such as iCVV or Dynamic CVV.

Code Location:

The card security code is typically the last three or four digits printed, not embossed like the card number, on the signature strip on the back of the card. On American Express cards, the card security code is the four digits printed (not embossed) on the front towards the right. The card security code is not encoded on the magnetic stripe but is printed flat.

American Express cards have a four-digit code printed on the front side of the card above the number.

MasterCard, Visa, Diners Club,  Discover, and JCB credit and debit cards have a three-digit card security code. The code is the final group of numbers printed on the back signature panel of the card.

New North American MasterCard and Visa cards feature the code in a separate panel to the right of the signature strip. This has been done to prevent overwriting of the numbers by signing the card.

Benefits when it comes to security:

As a security measure, merchants who require the CVV2 for card not present payment card transactions are required by the card issuer not to store the CVV2 once the individual transaction is authorized and completed. This way, if a database of transactions is compromised, the CVV2 is not included, and the stolen card numbers are less useful. Virtual Terminals and payment gateways do not store the CVV2 code, therefore employees and customer service representatives with access to these web-based payment interfaces who otherwise have access to complete card numbers, expiration dates, and other information still lack the CVV2 code.

The Payment Card Industry Data Security Standard (PCI DSS) also prohibits the storage of CSC (and other sensitive authorization data) post transaction authorization. This applies globally to anyone who stores, processes or transmits card holder data. Since the CSC is not contained on the magnetic stripe of the card, it is not typically included in the transaction when the card is used face to face at a merchant. However, some merchants in North America require the code. For American Express cards, this has been an invariable practice (for card not present transactions) in European Union (EU) states like Ireland and the United Kingdom since the start of 2005. This provides a level of protection to the bank/cardholder, in that a fraudulent merchant or employee cannot simply capture the magnetic stripe details of a card and use them later for card not present  purchases over the phone, mail order or Internet. To do this, a merchant or its employee would also have to note the CVV2 visually and record it, which is more likely to arouse the cardholder’s suspicion.

Supplying the CSC code in a transaction is intended to verify that the customer has the card in their possession. Knowledge of the code proves that the customer has seen the card, or has seen a record made by somebody who saw the card.

 

Posted in Best Practices for Merchants, EMV EuroPay MasterCard Visa, Point of Sale, Visa MasterCard American Express Tagged with: (Card Verification Value), (CVC2), American Express, atm, authorization data, bank/cardholder, card holder data, card identification number, card issuers, Card Not Present transactions, card number, card numbers, card security code, card validation code, card-not-present, card-present transactions, cardholder, cards, cash advance, chip cards, CID, code, Contactless card, credit, credit-card, CSC, customer, customer service, CVC1, CVV Number, CVV1, CVV2, Data Security Standard, debit, debit card, debit cards, device, Diners Club, Discover, fax, gateways, iCVV or Dynamic CVV, individual transaction, internet, issuer, JCB credit, magnetic stripe, mail, MasterCard, merchant, payment card, Payment Card Industry, payment card transactions, payment gateways, PCI-DSS, Personal Identification Number, PIN, point of sale, post transaction authorization, security codes, telephone, terminals, unique card code, virtual terminals, visa, web-based payment

PCI security on third party guidance

Businesses are rapidly adopting a third-party operations model that can put payment data at risk. Today, the PCI Security Standards Council, an open global forum for the development of payment card security standards, published guidance to help organizations and their business partners reduce this risk by better understanding their respective roles in securing card data. Developed by a PCI Special Interest Group (SIG) including merchants, banks and third-party service providers, the information supplement provides recommendations for meeting PCI Data Security Standard (PCI DSS) requirement 12.8 to ensure payment data and systems entrusted to third parties are maintained in a secure and compliant manner.

Breach reports continue to highlight security vulnerabilities introduced by third parties as a leading cause of data compromise. The leading mistake organizations make when entrusting sensitive and confidential consumer information to third-party vendors is not applying the same level of rigor to information security in vendor networks as they do in their own. Per PCI DSS Requirement 12.8, if a merchant or entity shares cardholder data with a third- party service provider, certain requirements apply to ensure continued protection of this data will be enforced by such providers. The Third-Party Security Assurance Information Supplement focuses on helping organizations and their business partners achieve this by implementing a robust third-party assurance program.

Produced with the expertise and real-world experience of more than 160 organizations involved in the Special Interest Group, the guidance includes practical recommendations on how to:

Conduct due diligence and risk assessment when engaging third party service providers to help organizations understand the services provided and how PCI DSS requirements will be met for those services.

Develop appropriate agreements, policies and procedures with third-party service providers that include considerations for the most common issues that arise in this type of relationship. 

Implement a consistent process for engaging third-parties that includes setting expectations, establishing a communication plan, and mapping third-party services and responsibilities to applicable PCI DSS requirements.

Implement an ongoing process for maintaining and managing third-party relationships throughout the lifetime of the engagement, including the development of a robust monitoring program. 

The guidance includes high-level suggestions and discussion points for clarifying how responsibilities for PCI DSS requirements may be shared between an entity and its third-party service provider, as well as a sample PCI DSS responsibility matrix that can assist in determining who will be responsible for each specific control area.

PCI Special Interest Groups are PCI community-selected and developed initiatives that provide additional guidance and clarifications or improvements to the PCI Standards and supporting programs. As part of its initial proposal, the group also made specific recommendations that were incorporated into PCI DSS requirements 12.8 and 12.9 in version 3.0 of the standard.One of the big focus areas in PCI DSS 3.0 is security as a shared responsibility. This guidance is an excellent companion document to the standard in helping merchants and their business partners work together to protect consumers’ valuable payment information.

Posted in Best Practices for Merchants, Credit Card Security, Payment Card Industry PCI Security Tagged with: banks, Breach, card, card data, cardholder, consumer, data, data security, Merchant's, networks, payment, payment card security, payment data, payment information, PCI, PCI-DSS, provider's, Security, Security Assurance, security standards, security standards council, Service providers, services

FCA Regulations and PCI Compliance

Compliance with a single set of regulations is often taxing enough, without other regulations causing a conflict, but this is exactly the situation that the insurance industry finds itself in with its contact centres.

PCI-DSS compliance insists that sensitive information in particular credit card numbers, must be protected and cannot be stored. However, the Financial Conduct Authority (FCA), the UK regulator for the financial services industry, demands that insurers keep sufficient detail of their transactions.

In insurance contact centres, FCA recommendations are met by recording calls. So in order to comply with PCI-DSS regulations, some contact centres simply pause recordings while the card information is read out, and resume recording once the payment process is complete. There’s a very big problem with this method,  it undermines the very reason calls are recorded. The call recording is there to provide an unequivocal record of the circumstances under which the policy is granted. A gap in this record creates doubt. What was said during this time? If a customer is claiming a policy is mis-sold or they were misinformed in some way, a complete record to refute this claim no longer exists. Because of situations such as this, the insurance industry has an inherent dependence on contact centres and person-to-person interaction when selling policies, though in the process has to somehow comply with both regulations. But how? One way is to get the sensitive card information directly and securely to the bank’s payment gateway without storing it. Online, this is done quite easily, insurers can embed a secure payment page into a website and the customer can enter information securely that way. By phone a similar method can be used. A caller can input information directly on their telephone keypad and the tones are only transmitted to the credit card payment gateway not the contact centre. This solves the paradox of the conflicting regulations.

Insurance contact centres need to walk a very fine line, ensuring that they comply with all of the relevant regulations from multiple regulators – even those that, at first glance, contradict each other.

 

Posted in Best Practices for Merchants, Credit Card Security, Payment Card Industry PCI Security Tagged with: (FCA), card information, compliance, contact centres, credit card payment, credit-card, customer, Financial Conduct Authority, financial services industry, insurance industry, payment gateway, payment process, PCI-DSS, phone, regulations, secure payment, taxing, telephone keypad, transactions, website