December 18th, 2015 by Elma Jane
A leading provider of mobile point of sale and mobile payment technology, published today the EMV Migration Tracker.
Many merchants have deployed EMV capable terminals while cardholders have received cards with EMV chips, but not much data has been published about the real world use of EMV chip card technology in the U.S. Most published statistics rely on surveys or forecasts rather than real transactional data.
The EMV Migration Tracker shows new data and insights since the October 1 liability shift, including:
- Over 50% of all cards in use now have EMV chips on them. From October to November, the percent grew 5% as banks and card issuers accelerated their rollout of new chip cards.
- Over 83% of American Express cards have EMV chips, while Discover lags at 40%
- Over 63% of the cards used in Hawaii have EMV chips, but Mississippi sees just 11% penetration of chip cards.
While EMV chip card technology has been implemented in Europe years ago, the rollout of EMV in the U.S is just beginning. The rollout came earlier this year with the October 1 liability shift in card present transaction, meaning that merchants who have not upgraded their POS system can become liable for counterfeit card fraud losses that occur at their stores. This is an early step in an ongoing process that the Payments Security Task Force predicts will lead to 98 percent of U.S. credit and debit cards containing EMV chips by the end of 2017.
http://www.finextra.com/news/announcement.aspx?pressreleaseid=62506
Posted in Best Practices for Merchants Tagged with: American Express, banks, card issuers, card present, card technology, cardholders, chip cards, credit, data, debit, Discover, EMV, EMV chips, merchants, mobile payment, mobile point of sale, payment technology, point of sale, POS, provider
November 30th, 2015 by Elma Jane
Cybercriminals will continue to look for opportunities to steal payment information. Despite the superior security features associated with EMV technology, chip cards may still be vulnerable to certain types of fraud.
An EMV chip does not stop lost or stolen cards from being used in card-not-present transactions. Merchants who deal in card-not-present transactions like sales over the telephone or via the Internet are encouraged to adopt additional security measures to ensure the authenticity of cards used for transactions. The strength of the U.S. e-commerce market makes card-not-present fraud an equally important security issue that card issuers and merchants need to consider in the shift to chip cards for point-of-sale transactions.
Retailers and service providers who deal in card-present transactions are reminded that upgrading to EMV terminal at the POS is the best way to protect their customers and their business from fraudulent transactions.
EMV cards are available as either chip-and-PIN (requiring the cardholder to enter their personal identification number to complete a transaction) or chip-and-signature (requiring the cardholder’s signature), U.S. banks have primarily chosen to issue chip-and-sign cards for now.
While 59 percent of US adults have already received a new chip card, only 41 percent of them know its benefits and only 37 percent say their card issuers explained how to use the chip cards.
Posted in Best Practices for Merchants, e-commerce & m-commerce, EMV EuroPay MasterCard Visa, Point of Sale Tagged with: card issuers, Card Not Present transactions, card-present transactions, cardholder, e-commerce, EMV, EMV terminal, merchants, point-of-sale transactions, POS, Service providers
September 24th, 2014 by Elma Jane
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
September 17th, 2014 by Elma Jane
Host Card Emulation (HCE) offers virtual payment card issuers the promise of removing dependencies on secure element issuers such as mobile network operators (MNOs). HCE allows issuers to run the payment application in the operating system (OS) environment of the smart phone, so the issuing bank does not depend on a secure element issuer. This means lower barriers to entry and potentially a boost to the NFC ecosystem in general. The issuer will have to deal with the absence of a hardware secure element, since the OS environment itself cannot offer equivalent security. The issuer must mitigate risk using software based techniques, to reduce the risk of an attack. Considering that the risk is based on probability of an attack times the impact of an attack, mitigation measures will generally be geared towards minimizing either one of those.
To reduce the probability of an attack, various software based methods are available. The most obvious one in this category is to move part of the hardware secure element’s functionality from the device to the cloud (thus creating a cloud based secure element). This effectively means that valuable assets are not stored in the easily accessible device, but in the cloud. Secondly, user and hardware verification methods can be implemented. The mobile application itself can be secured with software based technologies.
Should an attack occur, several approaches exist for mitigating the Impact of such an attack. On an application level, it is straightforward to impose transaction constraints (allowing low value and/or a limited number of transactions per timeframe, geographical limitations). But the most characteristic risk mitigation method associated with HCE is to devaluate the assets that are contained by the mobile app, that is to tokenize such assets. Tokenization is based on replacing valuable assets with something that has no value to an attacker, and for which the relation to the valuable asset is established only in the cloud. Since the token itself has no value to the attacker it may be stored in the mobile app. The principle of tokenization is leveraged in the cloud based payments specifications which are (or will soon be) issued by the different card schemes such as Visa and MasterCard.
HCE gives the issuer complete autonomy in defining and implementing the payment application and required risk mitigations (of course within the boundaries set by the schemes). However, the hardware based security approach allowed for a strict separation between the issuance of the mobile payment application on one hand and the transactions performed with that application on the other hand. For the technology and operations related to the issuance, a bank had the option of outsourcing it to a third party (a Trusted Service Manager). From the payment transaction processing perspective, there would be negligible impact and it would practically be business as usual for the bank.
This is quite different for HCE-based approaches. As a consequence of tokenization, the issuance and transaction domains become entangled. The platform involved in generating the tokens, which constitute payment credentials and are therefore related to the issuance domain, is also involved in the transaction authorization.
HCE is offering autonomy to the banks because it brings independence of secure element issuers. But this comes at a cost, namely the full insourcing of all related technologies and systems. Outsourcing becomes less of an option, largely due to the entanglement of the issuance and transaction validation processes, as a result of tokenization.
Posted in Best Practices for Merchants, Credit Card Security, EMV EuroPay MasterCard Visa, Near Field Communication, Visa MasterCard American Express Tagged with: (MNOs), (OS), assets, bank, card, card issuers, cloud, cloud based payments, cloud based secure element, cloud-based, hardware secure element, Host Card Emulation (HCE), issuing bank, MasterCard, mobile, mobile app, mobile application, mobile network operators, mobile payment, mobile payment application, nfc, operating system, payment application, payment transaction, payments, platform, risk, secure element, smart phone, software, software based technologies, token, tokenization, transaction, virtual payment, visa
September 4th, 2014 by Elma Jane
EMV, which stands for Europay, MasterCard and Visa, and is slated to be mandated across the United States starting in October 2015 and automated fuel dispensers have until October 2017 to comply. Unlike magnetic swipe cards, EMV chip cards encrypt data and authenticate communication between the card and card reader. Additionally, chip card user is prompted for a PIN for authentication.
Why are those dates important? Companies lose $5.33 billion to fraud today, with card issuers and merchants incurring 63 and 37 percent of these losses, respectively. Under the EMV mandate, merchants who do not process chip cards will bear the burden of the issuer loss. By accepting chip card transactions, merchants and issuers should see a reduction in fraud.
Overcoming Barriers to EMV Adoption
Given the significant barriers to EMV adoption, it may be tempting for merchants to meet minimum requirements for accepting EMV payments. However, medium to large retailers should also consider the bigger picture of customer security and peace of mind.
Some key critical success factors for a payment initiative of this size include:
Business Continuity Architecture: As with all payment systems, it is imperative to have the EMV system running at all times. The solution should preferably have Active-Active architecture across multiple data centers and have a low Recovery Point Objective (the point in time to which the systems and data must be recovered after an outage).
Cost Benefit Analysis: Take a top down approach and decide accordingly on the scope of the analysis. This will ensure that decisions on scope are made on basis of quantitative data and not just qualitative arguments.
Phased Approach: To overcome time or cost overage in a project of this scope and complexity, retailers should try using an iterative approach for development. The rollout can be divided into multiple releases of six to seven months, which will provide the opportunity to review, capture lessons learnt, and improve subsequent releases.
Proactive Monitoring Alerts: Considering the criticality of business function carried out by EMV, tokenization and payment gateway, a vigorous supervising environment must be defined to perform proactive and reactive monitoring. It should take into consideration the monitoring targets, tools, scope and methods. This will provide advance visibility to the failure points and better ensuring maximum system availability.
Resilience Testing: Typically in a software project, the testing is limited to the unit, integration, performance and user acceptance. However, due to the critical nature of the applications and systems involved, robust resiliency testing is vital. This will ensure that there are no single points of failure and the system remains available when running in error conditions.
Stakeholder Identification: This is a key step to ensure that you have varied perspectives from all departments and their support. It will keep your organization from being blindsided and reduce the risk of disagreements in later stages of the program. Key stakeholders should include Store Operations, Card Accounting, Loss Prevention, Contact Center and IT & Data Security.
Organizations should adopt a five step approach to implement a secure, robust and industry-leading payment solution:
Encryption – Point to point encryption will ensure card data is secure and encrypted from the point of capture to the processor. Usually, merchants use data encryption that is not point to point, rendering their organization vulnerable to data breaches. Software encryption is the most common form of encryption, as it is easily installed and quires little or no hardware upgrades; however, it is less secure, may expose encryption keys, and is prone to memory scanning attacks. Hardware encryption is considered more secure but requires more costly terminal upgrades. Hardware encryption is designed to self-destruct the keys if tampered, but is not well-defined as very limited headway has been made in this space.
Tokenization – Build a Card Data Environment (CDE) that will host a centralized card data storage solution. Only limited applications with firewall access and capability to mutually authenticate via certificates can access CDE and receive card data. The rest of the applications will have tokens which are random numbers. This architecture will ease the merchant’s burden with existing and emerging PCI Data Security Standards.
Payment Gateway – Perform a risk assessment on the current payment gateway and identify gaps in functionality, manageability, compliance, scalability, speed to market and best practices. Determine the alternatives to mitigate the risks. Some of the important aspects of a leading payment gateway solution are support for all forms of credit, debit, gift cards and check transactions. Its ability to work with any acquirer, in-built encryption abilities, support for settlement and reconciliation must also be kept into consideration.
Settlement, Funding and Reconciliation – A workflow-based system to handle chargebacks and the automation of chargeback processing will greatly reduce labor-intensive work and enhance the quality of data used for settlement and reconciliation. Upgrades to the existing receipt retrieval system may be needed.
Card fraud is on the rise in the U.S., and merchants are the primary target for stealing information. With the EMV deadline just over a year away, the responsible retailer must take steps to prepare now. Although EMV implementation might seem overwhelming to merchants, they should start their journey to secure payments rather than wait for a looming deadline. Solutions such as data encryption and tokenization should be used in combination with EMV to implement a robust payment solution to better protect merchants against fraud. By proactively adopting EMV payment solutions, merchants can stay ahead of the regulatory curve and better protect their customers from fraud.
Posted in Best Practices for Merchants, Credit Card Security, EMV EuroPay MasterCard Visa, Payment Card Industry PCI Security, Visa MasterCard American Express Tagged with: authentication, automation, card, card data, Card Data Environment, card fraud, card issuers, card transactions, CDE, chargeback, chargeback processing, check, check transactions, chip, chip cards, credit, customer, customer security, data, data breaches, data encryption, data security, debit, EMV, emv chip cards, EuroPay, fraud, gateway, Gift Cards, host, integration, magnetic swipe cards, MasterCard, Merchant's, payment, payment gateway, payment solution, payment systems, PCI, PCI Data Security Standards, PIN, processor, retailers, Security, software, swipe, terminal, tokenization, tools, visa
