Visa and MasterCard Drive Adoption of EMV Payment Technologies in the United States

Transcription

1 Visa and MasterCard Drive Adoption of EMV Payment Technologies in the United States EMV, which comes from the initial letters of Europay, Mastercard, and Visa, is a technical standard for a newer chipbased payment technology. This technology has been very popular globally and accounts for over half of the payment transactions outside of the United States. Where in use outside the U.S., consumers use payment cards that are embedded with a smart chip to connect to an EMV-enabled device and execute payment using dynamic authentication. The details of how EMV works vary slightly, but consumers either insert their card into (contact) or tap their card on an (contactless) EMV-enabled device, and then enter a personal pin number or their signature for authorization. Why is there buzz in the industry right now around EMV and payments? Visa and MasterCard are making a move to accelerate the acceptance of chip-based technology in the U.S. by offering incentives for investing in the infrastructure required to accept and process chip transactions, and have announced the following: As of October, 2012, Visa and MasterCard will no longer require eligible merchants to validate their PCI compliance as long as they use EMV chip-enabled payment terminals for at least 75% of their payment transactions using dualinterface (contact and contactless), EMV-enabled POS terminals. Eligibility will be determined by each brand independently. Important: This does not replace Payment Card Industry Data Security Standards (PCI DSS). Our customers must continue to meet the 12 requirements within the PCI DSS. EMV only reduces some of the costs associated with compliance for large merchants, as they will not be required to submit official PCI DSS validation. This refers to the PCI DSS validation process typically conducted with a Qualified Security Assessor (QSA). As of April, 2013, payment processors must be able to process EMV transactions. As of October, 2015, a liability shift will occur for counterfeit transactions, giving financial responsibility of fraud in a card-present transaction to the party who is not using EMV technology. If a merchant has EMVenabled devices (and 75% of transactions go through EMV), the merchant will not be responsible for costs associated with fraudulent transactions on their customer s cards the acquiring or issuing bank will be responsible. However, if a merchant does not use EMV, the acquiring and issuing bank will shift the cost involved with chargebacks and data fraud onto the merchant. Note: This liability shift will not occur for petroleum merchants until October, 2017, as the card brands have recognized the complexity in replacing or upgrading fuel controllers. How does the use of EMV improve payment security? EMV-chip-based solutions have been successful in reducing data security fraud around the world. Traditional magnetic stripe cards contain static data on the back of each card. This static data can easily be duplicated using low cost equipment that is readily available for purchase on the Internet. Once duplicated, a criminal can use the copied card to commit fraud anywhere in the world that accepts the specific brand of credit card. EMV differs as it uses a program in the chip on the card. The program allows for dynamic information to pass through with each payment transaction. Because the data is dynamic and not static, duplication of any one card is very difficult. Strong encryption and other security measures have made EMV much more secure; however, if a merchant has a properly configured POS solution and is meeting or exceeding PCI DSS requirements, the added security of EMV will only provide a marginal improvement in the overall security of your payment data. Is this relevant to the Aloha customer base? In the future, yes; however, there is no immediate impact to our U.S. customer base. Customers have approximately three and a half years before these changes start to impact their businesses. There also will be little to no reduction in PCI DSS costs for our customers, since most SMB merchants do not officially validate their PCI DSS compliance using a third-party QSA. Outside the U.S., we already support EMV where it is relevant. Today, no U.S. processors, acquiring banks, or card issuers are set up to support EMV. We are working with the acquirers and the various hardware manufacturers as they develop solutions and will add support for EMV, as needed. We are also on target to make EMV functionality available within Aloha early next year, ahead of the deadline for the processors. As a merchant, will I be required to only accept EMV cards? There are a number of moving parts to this change, and this will ultimately be determined by the card brands, but it is unlikely that traditional magnetic stripe cards will go away anytime soon. Outside of the U.S., 56% of Visa cards are issued as non-emv and 26% of the payment terminals cannot accept EMV cards. EMV cards are more expensive to issue than magnetic stripe cards, thus some issuers may delay replacing cards for financial reasons. Also, the petroleum industry has been given a two-year delay in the deadline dates to deal with the logistics of upgrading and replacing fuel controllers. Page 1

2 Visa and MasterCard Drive Adoption of EMV (cont.) Will I have choices in hardware as a merchant? EMV is one of two new payment methods being introduced to the industry; the other is Near Field Communication (NFC), which allows payments to be made using your smart phone. Combined with the fact that EMV supports two methods, contact versus contactless, there will inevitably be some variability in the market solutions provided by the issuing banks in the form of cards and by the acquiring banks and processors in the form of payment terminals. NCR is working directly with the major processors and will provide solutions that are the most flexible for our customers given the constraints of the payment process. In most cases, we expect to implement a multi-payment type solution that can be used for traditional magnetic stripe (MSR) as well as EMV and NFC. What if I accept American Express or Discover? American Express and Discover have not communicated any plans for EMV in the U.S. to date. If you accept these card brands, you must seek guidance from each for specifics around your processing merchant agreement. For more information: View the original NRA article. View the original Visa announcement. View the MasterCard EMV strategy. List of Aloha PA DSS Validated Payment Applications Payment application software vendors must adhere to the Payment Application Data Security Standards (PA DSS), to ensure they are developing products that are secure and protect cardholder data. In turn, merchants must use validated payment applications as part of complying with the Payment Card Industry Data Security Standards (PA DSS), Independent security consultants have validated the following Aloha applications: Product/Version number Validated against PA DSS version: Acceptable for new deployments? Current validation expires on: Aloha Online Site Agent v1.0 PA DSS v1.2.1 Yes October 28, 2013 Aloha POS v6.4 PA DSS v1.2 Yes October 28, 2013 Aloha POS v6.5 PA DSS v1.2 Yes October 28, 2013 Aloha POS v6.7 PA DSS v1.2 Yes October 28, 2013 Aloha POS v6.8 PA DSS v1.2 Yes October 28, 2013 Aloha Takeout v1.2 PA DSS v1.2 Yes October 28, 2013 Orderman Communicator v2.7 PA DSS v1.2.1 Yes October 28, 2013 Aloha POS v7.0 PA DSS v2.0 Yes October 28, 2016 All Aloha POS sites must use a PA DSS validated version of any Aloha payment application in use. A version is considered not valid for new deployments once its expiration date has passed; however, sites already using a validated version as of its expiration date are still considered to be using a validated version of the application, as long as the following remains true: NCR is still providing software support for the version. Note: It is expected that POS v6.4 will be retired effective when v7.0 reaches market ready status. Page 2

3 List of Aloha PA DSS Validated Payment Applications (cont.) The site is on software maintenance, which entitles them to patches and upgrades. The site implements all critical patches and updates within 30 days of the release. If using mixed POS and EDC versions, the POS version is used for validation purposes. For example, if you are using POS v6.7 and EDC v7.0, then you meet PA DSS requirements for v6.7. NCR is committed to continuously increasing security to protect cardholders and merchants. We continue to validate versions of Aloha payment applications as they are developed and released, and we strongly encourage clients to adopt the most recent market ready Aloha releases as they become available. Access the Payment Card Industry Security Standards Council (PCI SSC) Web site to view the published list of validated payment applications and their expiration dates. Changes in Merchant Policies That Could Impact Your Business Summary of policy changes Major credit card brands, specifically American Express, Visa, and MasterCard, have implemented changes in their merchant policies that could impact your business. You may need to evaluate your current practices and possibly make changes to your Point-of-Sale configuration, to reduce the risk of increased processor fees. Must have one single authorization for the full amount of the charge It is no longer acceptable to submit multiple authorizations for a single submitted charge, such as in a bar tab environment. Authorization approvals are only valid for seven (7) days. What does this mean for Aloha users? How you configure and use pre-authorizations in the Aloha POS could determine if you are at risk for increased processor fees as a result of these policy changes. If you currently use pre-authorizations, we recommend you turn this feature off, or, at the very least, turn off the subsequent authorization functionality, if applicable, as this functionality can cause multiple authorizations for the same check. If you continue using the pre-authorization feature without the subsequent authorization functionality and the final purchase amount exceeds the original preauthorization amount by more than 20%, chances are you will still incur additional fees. Also, we encourage you to settle your transactions daily. If you delay settlement past the required seven days, you have to re-authorize the transactions, which could mean loss of revenue. To change your pre-authorization functionality in old Aloha Manager: 1. Select Store Settings > Credit Card group > Authorizations. 2. Clear Perform Pre-Authorizations Automatically to turn off the pre-authorization feature completely. OR Select Perform Pre-Authorizations Automatically and clear the amount in Increment, to continue using pre-authorizations but turn off the subsequent authorization functionality. 3. Click Save and exit the Store Settings function. To change your pre-authorization functionality in Aloha Configuration Center and new Aloha Manager: 1. Select Maintenance > Business > Store. 2. Select the Store Settings tab. Page 3

4 Changes in Merchant Policies That Could Impact Your Business (cont.) 3. Select the Credit Card group, located at the bottom of the screen. 4. Under the Authorization group bar, clear Enable automatic pre-authorization to turn off the pre-authorization feature completely. OR Select Enable automatic pre-authorization and clear the amount in Subsequent pre-authorization amount to continue using preauthorizations but turn off the subsequent authorization functionality. 5. Click Save and exit the Store function. Sample scenarios for pre-authorizations likely to incur additional processor fees Consider the following possible scenarios. The first scenario assumes subsequent pre-authorizations are turned off; however, subsequent preauthorizations are enabled in the second scenario. In both scenarios, you are likely to incur additional processor fees; however, in the first scenario, it is not because of the new merchant policies that are in effect. Single pre-authorization and settlement for the check total Scenario 1: You start a tab for a guest using their credit card and receive a pre-authorization (Approval Code 1) for $ The tab totals $25.00 when friends join the guest. The guest buys a round of drinks for everyone, running the tab up to $ The guest asks to close their tab, and adds a $9.00 tip, for a new check total of $ In this scenario, you have a single approval to go with the settlement, but you are likely to incur additional processor fees for a check total that is more than 20% over the authorized amount. Multiple pre-authorizations but only one settlement for the check total, causing lingering or orphan authorizations Scenario 2: Your system is configured to do initial pre-authorizations for $50.00, and to do subsequent pre-authorizations for $25.00 when the check total exceeds the authorized amount. You start a tab for a guest using their credit card and receive authorization (Approval Code 1) for $ The tab totals $30.00 when friends join the guest. The guest buys a round of drinks for everyone, running the tab total up to $52.00, which still does not exceed 20% of the authorized amount; however, the guest later buys some appetizers, running the check total up to $85.00, and forcing the system to send another pre-authorization request to the processor (Approval Code 2). The credit card is now approved for $ The guest asks to close their tab and adds a $15.00 tip, for a new check total of $99.00, which is more than 20% over the authorized amount, and forcing the system to do another pre-authorization request to the processor (Approval Code 3). You now have multiple authorizations, for $50.00, $25.00, and $25.00 respectively, but only one settlement amount for $99.00 ($84.00 plus the tip). In this scenario, you will incur increased processor fees for having multiple authorizations with no matching settlement. You might also incur additional processor fees for a check total that exceeds 20% of the authorized amount. Did you know......you might be able to decrease your per transaction cost with Elavon? At one time, Elavon, a leading provider of payment processing, was experiencing difficulties with processing payments, specifically tips, in versions of Aloha prior to v6.4. Additionally, merchants were reporting issues with receiving batch settlement errors. As a solution, resellers began configuring merchants using Elavon to process payments using the TSYS Acquiring Solutions VisaNet emulation, rather than processing direct to Elavon. Processing through VisaNet (TSYS) emulation can cost sites an extra 4.5 cents per transaction, so Elavon has begun a campaign to ensure merchants are aware the issues have been resolved and to encourage sites to discontinue the practice of processing through TSYS emulation and to process direct to Elavon instead. Page 4

5 Questions or Comments? Aloha Documentation Team Acceptance of a given payment application by the PCI Security Standards Council, LLC (PCI SSC) only applies to the specific version of that payment application that was reviewed by a PA-QSA and subsequently accepted by PCI SSC (the Accepted Version). If any aspect of a payment application or version thereof is different from that which was reviewed by the PA-QSA and accepted by PCI SSC even if the different payment application or version (the Alternate Version ) conforms to the basic product description of the Accepted Version then the Alternate Version should not be considered accepted by PCI SSC, nor promoted as accepted by PCI SSC. No vendor or other third party may refer to a payment application as PCI Approved or PCI SSC Approved and no vendor or other third party may otherwise state or imply that PCI SSC has, in whole or part, accepted or approved any aspect of a vendor or its services or payment applications, except to the extent and subject to the terms and restrictions expressly set forth in a written agreement with PCI SSC, or in a PA-DSS letter of acceptance provided by PCI SSC. All other references to PCI SSC s approval or acceptance of a payment application or version thereof are strictly and actively prohibited by PCI SSC. When granted, PCI SSC acceptance is provided to ensure certain security and operational characteristics important to the achievement of PCI SSC s goals, but such acceptance does not under any circumstances include or imply any endorsement or warranty regarding the payment application vendor or the functionality, quality, or performance of the payment application or any other product or service. PCI SSC does not warrant any products or services provided by third parties. PCI SSC acceptance does not, under any circumstances, include or imply any product warranties from PCI SSC, including, without limitation, any implied warranties of merchantability, fitness for purpose or non-infringement, all of which are expressly disclaimed by PCI SSC. All rights and remedies regarding products and services that have received acceptance from PCI SSC, shall be provided by the party providing such products or services, and not by PCI SSC or any payment brands. The Compliance Newsletter is published on a quarterly basis. Channel partners can download a copy of each newsletter from the Reseller Portal. Corporate clients can download a copy of each newsletter from the Corporate User Portal. Also refer to the Aloha POS Data Security Handbook, in these same locations, for detailed information regarding configuring an Aloha system to meet PCI requirements. While the content in this newsletter has been obtained from sources believed to be reliable, no warranty is provided concerning such content and it does not constitute legal advice. Legal advice concerning specific situations should be obtained by your legal counsel NCR Corporation. All rights reserved. Page 5