Opinion
2:18-cv-00394-JAD-NJK
08-11-2023
JB Carter Enterprises, LLC dba ATM Merchant Systems, Plaintiff v. Elavon, Inc., Defendant
FINDINGS OF FACT, CONCLUSIONS OF LAW, AND FINAL JUDGMENT FOLLOWING BENCH TRIAL
Jennifer A. Dorsey, U.S. District Judge
In response to large-scale data breaches and increased counterfeiting, the debit- and credit-card industry adopted a technology known as “EMV” in October 2015 to authenticate chip-card transactions. Before this industry shift, plaintiff JB Carter Enterprises, LLC dba ATM Merchant Systems (ATMMS), which provides account services like credit-card, ATM, and check-cashing transactions to merchants, retained defendant Elavon, Inc. as its payment processor and linked its software to Elavon's systems. As the transition to EMV approached, Elavon repeatedly touted its EMV readiness and sold ATMMS payment terminals that it promised would be able to process the EMV transactions. But Elavon's software was not ready by October 2015, and it decided to shift to different payment terminals than the ones it sold to ATMMS. And though Elavon eventually rolled out the EMV-capable software and swapped out ATMMS's equipment with substitute devices the following year, the software couldn't process the type of transactions that ATMMS's business relied on. Year after year, Elavon kept pushing the date that it planned to offer support for its transactions, but Elavon terminated its contract with ATMMS in 2019 without ever having provided that technology.
ATMMS sued Elavon and proceeded to a non-jury trial on six claims: fraud, negligent misrepresentation, breach of contract, breach of the covenant of good faith and fair dealing (bad faith), intentional interference with contractual relations, and intentional interference with prospective business relations. At trial, ATMMS advanced the theory that Elavon falsely represented that it would-and orally agreed to-provide software and equipment that would allow ATMMS to process EMV-compliant transactions by the EMV-compliance date. It argued that Elavon's failure to do so halved its business and constituted an intentional interference with its relationships with current and future customers. Elavon, by contrast, sought to show that its EMV-readiness messaging wasn't meant for ATMMS; it wasn't responsible for ATMMS's EMV compliance; the parties never formed a contract; and it never represented that the software that it was developing would be ready by any date certain.
Based on the testimony of five witnesses and voluminous exhibits, I find that ATMMS prevailed on its claim that Elavon negligently misrepresented that it would offer an EMV software solution for customers like ATMMS by the EMV-compliance deadline. But ATMMS's victory on this claim is a Pyrrhic one because its too-thin damages evidence entitles it to nominal damages only, and all of ATMMS's other claims fail. I reach these conclusions based on the following findings of fact and conclusions of law.
Findings of Fact
I. The card industry switches to a new standard for payment processing called EMV.
Imagine that a decade ago, a Las Vegas tourist is feeling lucky but just spent her last dollar early in the night. Out of cash, she heads for the nearest ATM with her debit card in hand, swipes the card, and withdraws $500. After the machine spits out a stack of twenties, she walks into the nearest casino, hoping that her jackpot is minutes away. Days later, she learns that a fraudster had purloined her debit-card number using a skimmer surreptitiously installed on the machine-a device that criminals attach to ATMs to steal the information on a card's magnetic stripe-and emptied her bank account.
To prevent that kind of theft, the debit- and credit-card industry adopted a new standard for payment processing called “Euro, Mastercard, and Visa”-or “EMV” for short. Along with that shift, card companies started adding those small chips onto cards that we're all now accustomed to inserting or tapping in lieu of swiping the magnetic stripe. The chips encrypt the card information, complicating swindlers' attempts to steal card numbers. As of October 1, 2015, the industry also requires every entity involved in an in-person or “card-present” transaction to maintain devices and software that can read the chips and process the encrypted transaction. Any entity involved in the transaction that fails to do so runs the risk that the transaction is fraudulent and will have to take the hit of the chargeback. This transition to EMV was recognized as a major shift in the industry because, before it, the liability for chargebacks was borne by the banks.
ECF No. 136 at 97:13-22; ECF No. 137 at 31:25-32:12. These page-and-line citations come from the official trial transcripts, found at ECF Nos. 136 (trial day 1), 137 (day 2), and 140 (day 3).
ECF No. 136 at 95:19.
Id.
ECF No. 136 at 35:20-25.
ECF No. 137 at 31:25-32:12.
ECF No. 136 at 96:7-10.
II. ATMMS retains Elavon as its national processor and integrates its customers with Elavon's services.
Thinking again about our hypothetical tourist at the ATM, though her transaction seems relatively simple, the hardware and software that support those kinds of transactions are anything but. Once she requests the $500, the ATM sends the request to a “national processor,” which then forwards the information to the card company (think VISA, MasterCard, etc.) and the bank that issued the card. They, in turn, approve or deny the request, after which the flow of information reverses-that is, the approval or denial is sent through the national processor back to the ATM.
Id. at 233:10-22.
Id. at 233:22-25.
Id. at 233:7-12.
ATMMS bills itself as a hub connecting requests from people like our tourist with a national processor. According to its founder and CEO Bartus “Bart” Carter, ATMMS provides its clients with both hardware-such as ATMs, the point-of-sale (POS) terminals that shoppers insert their card into or tap their card against, or kiosks to get cash or casino chips -and the software that powers consumers' interactions with the hardware and its ability to communicate with a national processor. ATMMS calls its proprietary combination of hardware and software “Multi-Choice Cash” (MCC).
Id. at 18:25-19:1.
Id.
Id. at 28:24-29:21.
Id. at 230:15-18.
Id. at 19:14, 19:24-20:1, 22:8.
Though ATMMS services all sorts of businesses, its large casino clients are the focus of this case. For obvious reasons, casinos want as many ways as possible for their patrons to access cash or casino chips, so ATMMS's platform offers them a buffet of options: they can cash checks or dip into their checking or savings accounts with a typical ATM transaction; or, when their ATM card is maxed out, obtain a cash advance-basically a short-term loan-from their credit-card company. The industry describes the casino-chip requests as “quasi-cash” transactions, and ATMMS designed MCC with casinos' quasi-cash needs in mind. Certain transactions also require cardholders to verify their identity with a personal-identification number (PIN) or a signature.
Id. at 36:22-37:3.
ECF No. 140 at 60:10-14.
ECF No. 136 at 253:18-20.
ECF No. 140 at 58:19-59:6. ATMMS's platform also allows on-site restaurants to accept cards for payment. ECF No. 137 at 13-15.
ECF No. 140 at 58:19-59:6, 59:25-60:1. ATMMS also lends its customers the cash to supply ATMs (called “vault cash”). ECF No. 136 at 16:3-5, 17:15.
ECF No. 136 at 8-13.
ECF No. 137 at 156:4-18.
ECF No. 136 at 16:3-5, 17:15.
In 2011, years before the EMV transition, ATMMS retained Elavon as its national processer. In addition to processing services, Elavon also offers hardware like POS terminals. The parties' initial agreement, which did not contemplate the EMV transition, allowed ATMMS's customers to process transactions through Elavon's systems without Elavon entering a direct relationship or contract with them. Though Elavon appears to have at least hundreds of clients, Elavon understood the fundamentals of ATMMS's business (that it serviced casinos) and the importance of quasi-cash and PIN-debit transactions to ATMMS's casino business. And the partnership provided a unique benefit to Elavon because ATMMS offered products to casinos in ways that Elavon did not and ATMMS was Elavon's sole client who offered quasi-cash services.
Id. at 219; ECF No. 140 at 61:15-18.
ECF No. 136 at 215:8-216:13.
ECF No. 137 at 200:5-8.
ECF No. 136 at 56:20-23, 59:18; ECF No. 137 at 9:3-18, 67:2-6, 152:16-153:12; ECF No. 140 at 167:4-168:6; Trial Exhibit (Tr. Ex.) 72; Tr. Ex. 266.
ECF No. 137 at 175:1-23, 189:21-190:23; Deposition of Robert Morris (Morris Dep.), ECF No. 153 at 18:2-4, 25:15-17, 25:21-25, 45:12-13.
ECF No. 137 at 158:17-25, 178:4-6; Morris Dep. at 21:30-22:6.
ECF No. 137 at 6:22-24, 92:2-18; see also Tr. Ex. 38 (Morris acknowledging that ATMMS is “specialized” because it offers quasi-cash); Tr. Ex. 41 (Morris reporting that cash-advance transactions represent “most of their integration” with 70% being credit and 30% being PIN debit); Morris Dep. 26:3.
Early on in the parties' relationship, Elavon offered ATMMS the choice of how to connect to Elavon's systems: its platform could speak directly with Elavon's system (“direct certification”) or use Elavon's software (Converge) as an intermediary. After longtime ATMMS employee and general manager Michael Poggi -who works with every department in the company, including the sales, service, and accounting departments-learned that the direct option came with insurance and other additional requirements, ATMMS chose the Converge option at least for its casino clients and never again pursued direct certification.
ECF No. 136 at 235:8-16. At that time, it was called “Virtual Merchant.” Id. at 21:10-15. In 2014, the product was rebranded to “Converge,” ECF No. 136 at 216:18-22; ECF No. 137 at 68:5-6; Tr. Ex. 6, so I use “Converge” throughout for ease of understanding.
ECF No. 136 at 100:11-101:1, 107:5-21, 109:25-110:7; ECF No. 140 at 140:10, 139:8-19.
ECF No. 140 at 155:1.
Id. at 56:17-57:25.
Id. at 248:21; ECF No. 140 at 146:5-6; Tr. Ex. 87; Tr. Ex. 97.
ECF No. 140 at 62:14-63:13.
Id. at 146:2-147:8. Some evidence indicates that ATMMS chose the direct-certification option for its non-gaming customers. ECF No. 137 at 216:23-218:25.
Here's where the story gets really alphabet-soupy. Over the next two years, the parties collaborated on integrating MCC, the POS terminals that ATMMS supplied its customers (more on this later), and Elavon's host through Converge. Though ATMMS had primary responsibility for assimilating the systems and communicating with Elavon and other entities like the device manufacturer, ATMMS benefitted from guides and codes (collectively, “softwaredevelopment kits”) provided by Elavon and the device manufacturer. Development cost ATMMS about $1 million and finished in the summer of 2013, providing ATMMS its desired functionalities, including support for quasi-cash and PIN-debit transactions. Once integration was complete, ATMMS transitioned its casino clients to Elavon's services and set them up with POS terminals and MCC, and ATMMS started earning fees.
ECF No. 136 at 216:25-217:16; ECF No. 140 at 148:18-150:9, 162:2-14; Tr. Ex. 91; Tr. Ex. 294.
ECF No. 140 at 162:2-15, 163:3-24; Tr. Ex. 92; Tr. Ex. 308.
ECF No. 136 at 216:25-217:16; ECF No. 140 at 148:18-150:9; Tr Ex. 294; Tr. Ex. 91.
ECF No. 140 at 63:21-22.
ECF No. 137 at 39:13-19, 169:12-21, 176:15-177:13; ECF No. 140 at 164:25-165:18.
ECF No. 136 at 95:6-8; ECF No. 140 at 164:25-165:18, 166:24; Tr. Ex 266.
Throughout the parties' relationship, Poggi acted as the main point of contact from the ATMMS side and provided CEO Carter-who was not directly involved in day-to-day communications with Elavon-with weekly updates. Though Poggi has no formal education in software development, 15 people on ATMMS's technical team supported his day-to-day work. Elavon's outward-facing role for ATMMS, by contrast, changed hands multiple times: Ryan Hicks served in that role from the start of the relationship in 2011 until sometime before October 2015; followed by Robert Morris, who managed the ATMMS relationship until April 2016; and followed ultimately by Mike Palmer. These employees, or “relationship managers” as Elavon refers to them, acted as conduits between ATMMS and Elavon's technical and business teams and regularly upDated:MMS with business insights and the latest developments in Elavon's products and services. Despite Elavon's personnel churn, the parties “loved” working with each other throughout most of their relationship.
ECF No. 136 at 50:2-25.
Id. at 37:17-21.
ECF No. 140 at 155:1.
Id. at 65:10-22.
Id. at 135:10; Morris Dep. at 8:24-9:1.
ECF No. 136 at 163:16-22; Tr. Ex. 43.
ECF No. 136 at 163:16-22; Tr. Ex. 43.
ECF No. 136 at 15-20.
Id. at 88:19, 91:13-15; ECF No. 137 at 229:16-230:6; Tr. Ex. 313.
III. Elavon pushes the EMV transition and offers the L5200 as its EMV hardware solution for Converge customers.
Starting in 2012, Elavon primed its clients for the impending EMV shift. A December 2012 advertisement sent to Poggi asked “Are you ready” for the transition. A newsletter from the next month exclaimed that “Elavon is pleased to announce the launch and support date of our new EMV-capable terminal lines” that will be “plug and play” -essentially meaning that a user simply plugs in a device or downloads a software, and it works without significant effort on the user's part. This piqued Poggi's interest because ATMMS or its clients would have to foot the bill for disputed charges if their equipment and software weren't EMV compliant by October 1, 2015.
Tr. Ex. 2.
Tr. Ex 3 (cleaned up).
ECF No. 140 at 65:4-7, 157:3.
ECF No. 137 at 201:13-16.
So around November 2012, after learning about EMV, Poggi asked Hicks which POS device Elavon would support for EMV-compliant transactions through Converge. Elavon responded-and Poggi understood-that Elavon's EMV support for Converge would “not likely be until” late 2013 and that Elavon was prioritizing its development efforts in Canada, which had mandated EMV compliance two years prior. But Elavon ultimately advised ATMMS that it would support a device called the “L5200” POS terminal to work with Converge.
ECF No. 140 at 142:8-10.
ECF No. 137 at 50:22-56:18; Tr. Ex. 1.
ECF No. 140 at 153:20-154:11.
Id.; Deposition of Eric Przybylek (Przybylek Dep.), ECF No. 154 at 32:34-33:5, 36:20-37:12, 38:20-39:5.
ECF No. 136 at 103:22-24, 204:16; ECF No. 137 at 174:13-23; Morris Dep. 11:9-14; Tr. Ex. 5.
Based on that information, ATMMS bought 197 L5200s from Elavon sometime in 2013. Poggi was particularly interested in the L5200 because it would work with Converge and later allow ATMMS's customers to process EMV-compliant transactions without ATMMS having to go through the direct-certification process. He also believed that the device would be “plug and play.” Longtime Elavon employee and executive Lisa Brooks Carmichael-whose team helped manage Elavon's relationships with entities like ATMMS-acknowledged that ATMMS would not have bought the L5200s absent Elavon's representation that they would be EMV compliant.
ECF No. 136 at 185:15-22; ECF No. 137 at 171:9-172:10.
ECF No. 136 at 123:2-19; ECF No. 140 at 179:5-7.
ECF No. 140 at 157:14-158:9.
Id. at 171:15-19.
ECF No. 136 at 88:9-19.
Tr. Ex. 21; ECF No. 137 at 203:6-8, 204:6-8.
For the next two years, Elavon repeatedly touted its EMV technology in messages to its clients in anticipation of the October 1, 2015, liability-shift Dated:
• A February 2013 newsletter about “[n]ew EMV[-][c]apable [t]erminals” proclaimed that Elavon's customers “can be confident that Elavon has the latest . . . solutions to help you succeed.”
• The next month, Hicks emailed Poggi information about a “[n]ew EMV [c]apable [p]eripheral for [Converge]” that “will process . . . debit” and “helps protect your customers from chargebacks and prepares them for the future of EMV chip cards” because “Elavon wants to ensure you are properly equipped to position this revolutionary paradigm shift in our [i]ndustry!” The newsletter also advertised the L5200 as a “new signature[-]capture device for use with” Converge that “will process a range of payment types including
credit [and] debit,” feature a “PIN [p]ad,” and “prepare[] [customers] for the future of EMV chip cards.” The brochure attached to the newsletter described the L5200 as capable of accepting “PIN-based payment types, including PIN debit.”
• Two days later, Poggi received an ad telling him that the device “[c]an be used in the [Converge] virtual terminal,” and “customers . . . will be able to remotely enable [the device] to support” EMV functionality.
• Multiple October 2014 newsletters again hyped Elavon's “next-generation . . . terminals” to be “shipped EMV-enabled for your customers.”
• A January 2015 newsletter advised customers to “[t]ake advantage of our lower EMV-equipment pricing today, so your customers can be ahead of the October 2015 liability shift.”
Tr. Ex. 349.
Tr. Ex. 4.
Id.
Id.
Tr. Ex. 5.
ECF No. 136 at 112:19-113:2; Tr. Ex. 8 (emphasis in original); Tr. Ex. 11.
Tr. Ex. 14 (cleaned up).
At trial, Carmichael testified that some of the information in these mass communications was not intended for ATMMS. She explained that Elavon categorizes its clients into two classes: whereas class A clients use devices that Elavon has full control over and directly certify to Elavon's host, class B clients like ATMMS use their own software and integrate it into Elavon's system either directly or through Converge. Any messaging suggesting that EMV functionality would be more or less automatic, Carmichael added, related to class A clients only. Though she stated that the messages distinguished between the classes, she did not discuss any example emails that explicitly called out the divide, nor did she convincingly describe how Poggi would know which details didn't apply to ATMMS. And no written materials advised that Elavon would not be ready for the EMV transition for class B clients.
ECF No. 140 at 4:23-24.
ECF No. 136 at 229:23-230:5.
ECF No. 137 at 38:24-25, 39:13-19, 228:3-18; ECF No. 140 at 4:24-5:10. The class A vs. class B distinction (whether Elavon controlled the device) is somewhat different than the direct certification vs. Converge distinction (how a customer integrated into Elavon's system). A class B customer (with their own device and/or software) could directly certify into Elavon's system.
ECF No. 136 at 113:6-10; ECF No. 137 at 5:20-25, 194:15-195:6.
ECF No. 137 at 5:20-25.
ECF No. 140 at 29:1-9. Carmichael explained that Elavon uses the term Converge to refer to two distinct things: (1) a virtual terminal used for online payments and (2) the ability to integrate a client's software with Converge. ECF No. 136 at 116:14-18. ATMMS used the second. No evidence shows that Elavon explained that distinction to ATMMS or in its client communications.
ECF No. 140 at 6:23-7:1, 8:4-8.
IV. ATMMS seeks to enable the L5200 for EMV, and Elavon changes course.
In late 2014, with the EMV shift a year out, Poggi asked Elavon how to enable the L5200 for EMV with Converge. At that point, there was nothing for ATMMS to do in terms of development, and the ball was in Elavon's court. Elavon responded that it had not “defined” steps but was “working on a plan for 2015.” Two months later, Elavon reported a more precise timeline: “We anticipate having EMV available for Converge in Q1 or Q2”of 2015. Poggi took these emails as promises that Elavon would offer an EMV solution for Converge using the L5200s by the liability-shift date.
Tr. Ex. 12.
ECF No. 136 at 135:19-121:17.
Id.
ECF No. 140 at 76:19; Tr. Ex. 13.
ECF No. 140 at 174:24; 176:6-8.
But Elavon's plans changed: it would now support a different device, the Ingenico 250 or iSC250. Though Hicks told Poggi in April 2015 that Elavon's “EMV card reader for Converge will be the Ingenico 250,” the message went over his head. The news finally clicked when Poggi saw a May 2015 email informing him that Elavon would switch to a new EMV device by mid-2015. The email spoke of Elavon's “accelerated migration from non-EMV-capable terminal and pin-pad options over to EMV-enabled solutions.” Under Elavon's plan to switch EMV-supported devices, the L5200s would still be usable but not EMV compliant with Converge; though some evidence indicates that ATMMS could have achieved EMV compliance by directly certifying the L5200s.
ECF No. 137 at 71:9-20; Tr. Ex. 19.
ECF No. 140 at 79:14-80:1.
ECF No. 137 at 174:13-23; Morris Dep. at 16:8; Tr. Ex. 20; Tr. Ex. 29.
Tr. Ex. 20 (cleaned up).
Morris Dep. at 14:13-24 (cleaned up).
ECF No. 137 at 107:24-108:13.
Faced with Elavon's shifting support, Poggi emailed Elavon within days to shore up ATMMS's ability to be EMV compliant by October: “EMV is very important to me” and “[t]he deadline is October 15th of this year,” he said, adding that ATMMS bought the L5200s “with the understanding that they would be made EMV enabled.” He also requested two iSC250s to “integrate them into our platform.” Elavon shipped the two devices soon thereafter and explained that they were part of a test phase and were expected to be EMV enabled by late July.
ECF No. 140 at 83:4-5 (Poggi testifying that he was concerned at this point); Tr. Ex. 21; Tr. Ex. 29; Tr. Ex. 24.
ECF No. 140 at 83:4-5; Tr. Ex. 21; Tr. Ex. 29.
Tr. Ex. 24; Tr. Ex. 29.
V. ATMMS enters Elavon's beta program for an EMV-compliant Converge software.
In response to Poggi's request for the iSC250 test devices in June 2015, Elavon informed him that it was developing a software-development kit (known in the industry by the shorthand “SDK”) called “Commerce SDK” to help customers like ATMMS connect their software with Converge to process EMV-compliant transactions. The SDK included both a guide to help with integration and software that resided within the POS terminal's software. Elavon's representative explained that the tool was still being developed but invited ATMMS to join the first beta (or test) phase as an early adopter, and Poggi understood this. Poggi jumped at the chance and acknowledged that ATMMS would use Commerce SDK “in a test environment . . . until [it is] certified and authorized for release.”
ECF No. 137 at 88:9-13; Tr. Ex. 29.
ECF No. 140 at 193:14; Tr. Ex. 96.
ECF No. 140 at 187:21; Przybylek Dep. at 8:21-22; Tr. Ex. 96.
Tr. Ex. 96.
As Elavon geared up for the beta program, it continued sending newsletters and direct emails to Poggi about its EMV capabilities ahead of the liability-shift date. An attachment to a May 2015 email sent specifically to Poggi to gauge ATMMS's readiness, for example, was captioned “Converge Gets EMV Ready” and stated that the iSC250 has “the ability to accept credit cards and PIN-based transactions” and, though “currently EMV-capable . . . [,] won't be able to accept a chip card transaction until later in the year after a software download.”Another email from that month told Elavon's customers that, “[t]o make sure we are fully prepared for the EMV-liability shift in October, Elavon is taking every step possible to ensure a smooth transition for our customers,” noting an “accelerated migration” to EMV solutions and the upcoming removal of the option to turn off EMV functionality on terminals. Elavon pushed similar messaging in a June newsletter and continuously announced that “EMV is here!” in emails acknowledging the impending October deadline. A separate June newsletter announced that “some of our EMV[-]capable terminal[s]” would auto-update to EMV enabled starting in July. Some of the messages were sent to Poggi to alleviate his concerns about EMV readiness. In conversations too, Elavon repeatedly sold Commerce SDK as the EMV solution for Converge, specifically for quasi-cash, PIN-debit, and other debit transactions.
ECF No. 140 at 28:1-18.
Tr. Ex. 25.
Tr. Ex. 20 (cleaned up).
Tr. Ex. 26.
See, e.g., Tr. Ex. 30.
Tr. Ex. 27.
Morris Dep. 26:7-12; 26:14-19.
ECF No. 137 at 223:19-25; Tr. Ex. 32.
In August, the parties held a call to discuss ATMMS's “current integration with Converge and see if [Elavon] may move forward with including [ATMMS] in the beta program.” The materials for the call included a presentation describing Commerce SDK as a software tool that “enables a business to implement a secure, pre-certified EMV . . . solution” designed to solve EMV demand in light of the “upcoming liability shift.” ATMMS then formally joined the beta program, and Poggi knew that Commerce SDK was in beta and thus not yet a finished product. Throughout this time, ATMMS repeatedly asked about EMV PIN debit, and the frequency of those inquiries increased over time.
Tr. Ex. 95.
Tr. Ex. 96.
ECF No. 140 at 193:2, 187:3-192:4; Tr. Ex. 95.
Przybylek Dep. at 43:13, 46:22-23.
ECF No. 136 at 195:17-19.
VI. Elavon fails to support Converge for EMV by the liability-shift deadline.
Facing customer concerns about EMV compliance and a decline in business, Poggi sought assurance in writing that Elavon would be ready for the EMV shift, but Elavon declined to author such a letter. On September 25, 2015, Elavon informed Poggi that the Commerce SDK solution would not be ready by the October 1st liability-shift date, acknowledging that Poggi “hope[d] . . . to use Commerce SDK to help with the EMV transitions,” and stating that Elavon did not expect Commerce SDK “to be ready [until] toward the end of 2015.” Elavon senior product manager Eric Przybylek-who served in that role from 2015 to 2018 and is no longer with the company-acknowledged right before the liability-shift date that there were customers like ATMMS “that bought devices that would be EMV enabled like the L5200 and now will not.” Poggi testified that this was the first time he understood that Elavon wouldn't be ready by the EMV-compliance date. And Commerce SDK wasn't EMV ready by that date. While the iSC250 supported EMV, the SDK software could not; nor was the SDK certified for the iSC250 device.
ECF No. 137 at 204:9-10.
ECF No. 140 at 68:6-10; ECF No. 137 at 209:9-19.
Tr. Ex. 31.
Przybylek Dep. at 5:22-23, 6:17-21.
Id.
ECF No. 140 at 95:8.
ECF No. 136 at 111:21-25; ECF No. 137 at 163:8-9; Przybylek Dep. at 24:16-18.
Przybylek Dep. at 51:12-13.
ECF No. 137 at 185:2-3.
Id. at 210:17-211:4.
From the perspective of Elavon's then employees, the failure to meet the October 1 deadline was mostly a non-event. Though ATMMS's EMV compliance was in Elavon's interest, both Carmichael and Przybylek-who led the beta project-explained that the timing of Commerce SDK's development was untethered from the EMV liability-shift date.In fact, Przybylek testified that he had no direct role in EMV and that Commerce SDK was part of a broader strategy, not for a specific EMV deadline. While the product was never striving to be ready for the EMV-compliance deadline, Elavon did not consciously choose to miss the deadline. Rather, Elavon road-mapped tentative development dates in collaboration with its technical team and beta-program participants, and those dates happened to get pushed past the EMV-compliance deadline. In fact, at some point, Elavon knew that ATMMS would not be EMV compliant by the liability-shift date. Plus, the point of the beta program was to get feedback from several customers (not just ATMMS)-not to be ready by October 2015.And Elavon told ATMMS that PIN-debit functionality would be added later. Customers who prioritized EMV compliance by the liability-shift date could have pursued other options, including direct certification, rather than wait for Commerce SDK, and Elavon orally told ATMMS about those options multiple times, including in 2015. Though Elavon designed Commerce SDK to help connect its clients' platforms to Elavon's systems with Converge to support EMV, it had no responsibility to develop such a tool.
Morris Dep. at 19:6-16.
Przybylek Dep. at 15:14-24.
Id. at 18:10-17.
Id. at 15:14-24.
Id. at 24:5-11.
ECF No. 140 at 19:10.
ECF No. 136 at 111:21-25; Przybylek Dep. 6:24-25.
ECF No. 137 at 168:14-21.
Przybylek Dep. at 9:16-20; 42:18-43:2.
Id. at 22:24-23:8.
Id. at 43:13, 46:22-23, 27:5-29:4 (explaining that at some point between August 2015 and March 2016 ATMMS asked if it would support PIN debit but that Elavon was up front that it would not).
Id. at 24:5-11.
ECF No. 137 at 92:17-93:4, 111:13-18; Przybylek Dep. at 45:13-22.
ECF No. 140 at 54:17-20.
The rub: no documentary evidence shows that Elavon told ATMMS that Commerce SDK might not be viable by October 2015. There's also no written evidence that Elavon offered the direct-certification option anytime between 2012 and 2015 after the parties had the initial discussion about which approach ATMMS would take. And Carmichael conceded that ATMMS didn't do anything contrary to Elavon's instructions.
ECF No. 136 at 117:11; ECF No. 137 at 181:16-19.
ECF No. 137 at 112:4-11, 170:8-11; ECF No. 140 at 38:2.
ECF No. 137 at 179:4-9.
But ATMMS never asked about or pursued alternatives to Commerce SDK like direct certification after 2012. And it appears that ATMMS could have largely achieved its EMV goals by the liability-shift date if it had; it could have written its own code to integrate MCC into Converge or directly certified its platform to Elavon's system using the L5200s that ATMMS's clients had. Poggi testified that, though he didn't know he could have achieved EMV compliance with these alternatives, ATMMS would have (and could have) pursued them if he knew. However, some evidence indicates that no Elavon option would have supported EMV PIN-debit transactions specifically by the liability-shift date.
ECF No. 140 at 187:3-192:4.
ECF No. 137 at 227:18-20.
ECF No. 140 at 21:10-14.
ECF No. 136 at 102:19-22; ECF No. 140 at 52:1-53:14.
ECF No. 137 at 107:24-108:13.
ECF No. 140 at 217:11; Tr. Ex. 25 (noting that ATMMS qualified for direct certification).
ECF No. 140 at 197:22-25, 200:18-21, 203:17.
Przybylek Dep. at 40:6-13, 56:16-18. Przybylek did not appear certain about the details surrounding EMV, as that was not his focus, and referred to Carmichael for specifics.
ATMMS reacted differently to the lack of EMV support by the liability-shift date. Poggi testified that he believed that Elavon's representations starting in 2012 meant that Commerce SDK and the L5200 terminal (and then the iSC250) would deliver EMV functionality by October 2015. He thought that Elavon's technology would support the same functionalities that Elavon offered through Converge before the EMV transition, including support for EMV PIN-debit transactions. According to Poggi, ATMMS would have found an alternative if Elavon had not agreed to this. Nonetheless, he conceded that Elavon wasn't entirely responsible for ATMMS's EMV compliance; ATMMS had to choose its approach to EMV compliance and develop some coding of its own. Poggi also testified that he believed Elavon's representations were “partially true” or “could be true,” implying that he understood that Elavon might not live up to every detail of its messaging.
ECF No. 140 at 66:19-67:4.
Id. at 65:23-66:7.
ECF No. 140 at 76:24-77:14, 173:11-15.
Id. at 66:13-18.
ECF No. 140 at 169:14-170:2, 195:13.
Id. at 187:3-192:4.
Id. at 87:10-15.
VII. Elavon declines to cover ATMMS's potential liability while Commerce SDK is finalized.
Once ATMMS learned that Commerce SDK would not be EMV ready by October 2015, Poggi asked how Elavon planned to handle “liability coverage for those customers that bought devices that would be EMV enabled like the L5200 and now will not.” Elavon understood that Poggi was concerned about his clients and ATMMS's liability. Elavon was considering discounting swaps from the unsupported L5200s to the supported iSC250s and providing amnesty to-that is, cover the fraudulent-charge liability for -clients with L5200s. Elavon was focused on ATMMS because it had requested information, it was the most impacted, and its clients were asking for a temporary fix until it had an EMV solution. Poggi also expressed concern because ATMMS “put all of our eggs into one basket” with Elavon and asked about EMV compliance on a regular basis.
Tr. Ex. 31.
Morris Dep. 39:15-40:13.
ECF No. 137 at 105:5-7.
Tr. Ex. 98.
Id.; Morris Dep. at 42:20-23.
Tr. Ex. 98.
Realizing that Elavon would likely decide against giving ATMMS amnesty because of the volume of disputed charges on quasi-cash transactions, Carmichael's team pressed for amnesty to appease ATMMS as a “relationship-management” strategy. Indeed, her team wanted to keep ATMMS as a partner. Morris requested it as an advocate for his client, and he thought that ATMMS deserved it because Elavon went in a different direction. Plus his compensation was tied to his client's performance so he had a personal interest in amnesty.So the relationship-management team proposed amnesty “until Elavon is in a position to provide replacement hardware for the L5200s that [ATMMS] was initially instructed to provide.”They reasoned that ATMMS spent $100,000 “in order to move in[] the direction of EMV” and then “Elavon changed direction and decided we weren't going to offer the L5200.”
Id.
ECF No. 136 at 135:25-136:2, 137:20-22; Tr. Ex. 32.
ECF No. 137 at 17-25.
Morris Dep. at 29:10-14.
Id. at 30:22-31:1.
Id. at 42:19-24.
Tr. Ex. 101.
Id.
As Carmichael's team predicted, Elavon's higher-ups ultimately declined amnesty for ATMMS because ATMMS wasn't bringing in enough new business to justify the risk. In an email, Morris explained the decision, stressing that his team “pushed all the way to the top” to secure amnesty for ATMMS “while your EMV quasi-cash solution is developed.” He also suggested that ATMMS instead cover its customers' liability and “create a communication . . . explaining the November/December timeframe that is expected currently for development work to be completed.” This news put Poggi “in a bit of a panic mode” in search of a technical solution to become compliant. Poggi told Elavon that, because they wouldn't send an amnesty letter, they couldn't get new business, and Elavon could see the harm to ATMMS's business because it had access to the reports of transaction-processing volume. Morris later reminded Poggi that Elavon would “work[] with you to cover the cost of the replacement equipment.”
ECF No. 137 at 107:2-6, 196:9-15; ECF No. 140 at 44:8-11.
Tr. Ex. 32.
Id.
Tr. Ex. 105.
ECF No. 140 at 39:17-20.
Morris Dep. at 39:9-14.
Tr. Ex. 32.
VIII. Elavon launches Commerce SDK and discounts the iSC250s.
Elavon continued development of Commerce SDK after the liability-shift date. In January 2016, Poggi told Przybylek that one of ATMMS's “[c]asino [l]ocations cancel[led] their contract . . . due to EMV non-compliance,” and he asked for an updated completion date.“We are targeting the end of February,” Przybylek responded, “but there are some risks that may push [us] into early March.” Poggi understood that these dates were development targets.Despite repeated inquiries by Poggi, early March then turned into a “march[] to a general release at” the end of the month, which transformed again into “an April launch.” During this time, Elavon internally acknowledged that ATMMS was losing business each day without an EMV solution, but some of the delay was due to third parties that had nothing to do with Elavon. Nevertheless, Poggi understood that Elavon had to finish development before ATMMS could use Commerce SDK; the license agreement was not ready; and ATMMS still needed to integrate Commerce SDK to MCC and certify the integration into Converge.
ECF No. 139 at 141:15-19; Tr. Ex. 33.
Tr. Ex. 34; Tr. Ex. 114.
Tr. Ex. 34.
ECF No. 140 at 207:2-18.
See, e.g., Tr. Ex. 132.
Tr. Ex. 35.
Tr. Ex 37; Tr. Ex. 40.
ECF No. 136 at 153:20-155:24; ECF No. 140 at 211:1-24; Tr. Ex. 42; Tr. Ex. 44; Tr. Ex. 141.
ECF No. 137 at 213:15-19; ECF No. 140 at 208:17-209:22; Tr. Ex. 160.
Ahead of the launch, in March 2016, the parties entered into a licensing agreement allowing ATMMS to use Commerce SDK beyond the testing phase. In an email discussing that agreement, Przybylek acknowledged Poggi's “need for” an EMV solution. The agreement specifies that one purpose of the software was to “assist a merchant in implementing a pre-certified EMV . . . payment solution.” It includes a clause merging “all prior or contemporaneous proposals, negotiations, conversations, discussions[], and agreements . . . whether oral or written, with respect to the subject matter” of the agreement and stating that the parties didn't rely “on any prior statements of representations.” Under the agreement, Elavon also disclaims liability “for any damages . . . related to or arising out of [ATMMS's] use of, or the inability to use. . . Commerce SDK.”
Tr. Ex. 39.
Tr. Ex. 38.
Tr. Ex. 39 at PLTF000124.
Id. at PLTF000130.
Id. at PLTF000127.
When Commerce SDK launched in April 2016, Elavon advertised it as a tool that would allow its clients “to integrate with Elavon and be completely EMV compliant as a result.”Though ATMMS had access to the Commerce SDK in April, it was only certified to deploy it in June, as the parties' technical teams were working out kinks to get the various hardware and software components integrated. By June, ATMMS started onboarding its first customers to the EMV Commerce SDK solution. By that point, Commerce SDK allowed for some EMV functionalities but did not support others, including PIN-debit transactions. Przybylek testified that he had told Poggi in late 2015 that Commerce SDK would not initially support PIN debit.
Id.
ECF No. 140 at 127:2-8.
Tr. Ex. 45.
Tr. Ex. 186.
ECF No. 140 at 137:2-8; Tr. Ex. 132.
Przybylek Dep. at 36:1-15.
In conjunction with the general release of Commerce SDK around mid-2016, Elavon swapped the L5200s that ATMMS had in the field for iSC250s at a discounted price, depending on how long each L5200 had already been used, with older ones less discounted. ATMMS bought 117 iSC250s-well below the number of L5200s it previously purchased, Poggi asserted, because ATMMS lost some locations due to its lack of EMV functionality. Elavon did not pay for costs associated with the installation of the iSC250s.
Id. at 107:17-23; Tr. Ex. 164.
ECF No. 140 at 67:12-23.
ECF No. 136 at 153:20-155:24.
IX. Elavon adds functionality but not PIN-debit support to Commerce SDK and ends the relationship.
Around the time of the Commerce SDK deployment in late June 2016, Poggi asked Morris when PIN-debit functionality would be supported, recognizing that Elavon had targeted the end of June. “July 27,” Morris answered. In early July, Poggi confirmed that ATMMS had 30 terminals using Commerce SDK in the field and commented that Elavon “did a great job on the EMV product,” as ATMMS “had no service calls.” The parties continued to address technical issues and new features that year, but not PIN debit.
Tr. Ex. 186.
Id.
Tr. Ex. 188.
Tr. Ex. 193; Tr. Ex. 203.
In January 2017, still without PIN-debit functionality, Poggi laid out his complaints in a letter to Elavon requesting a meeting to discuss “product[-]completion dates and revenue”: ATMMS “pursu[ed] the EMV product almost two years” before the liability-shift date; it “purchased the product that [he] was told to purchase;” he “constantly asked about processing of EMV transactions”; and Elavon “bombarded” him “with EMV notifications . . . leading [him] to believe that Elavon was going to be ready to process EMV transactions” by the liability-shift date. Despite all that, Poggi continued, Elavon told him that ATMMS would not be able to process EMV transactions a mere month before the liability-shift date; ATMMS was liable for fraudulent charges; “12 high[-]volume locations either broke their contracts or chose not to renew due to [ATMMS's] inability to process EMV transactions”; it “cannot acquire new locations for [c]redit[-][c]ard [c]ash [a]dvance;” ATMMS laid off four salespeople and had lost $900,000 and growing; and its reputation for quasi-cash was “reduced to almost nothing.”Poggi also included a timeline of events from ATMMS's perspective.
Tr. Ex. 48.
Id.
Id.
The parties met to discuss these concerns in April 2017. After the meeting, Poggi circulated a summary recounting his understanding of the discussion, including that Elavon is prioritizing work in Canada over additional functionalities for Commerce SDK, such as quasicash and PIN-debit transactions, and that completion dates would be a guess. No one at the meeting advised ATMMS to pursue direct certification. Elavon never provided feedback on Poggi's complaint letter saying that anything was inaccurate.
Tr. Ex. 48 at PLTF000171.
ECF No. 140 at 128:16-19.
Id. at 119:21-23.
As the year progressed, Elavon continued pushing its target date for PIN-debit functionality. In September 2017, Poggi asked Elavon about its timeline for that technology, noting that he understood that Canada took priority and that the Canada work was expected to be complete a month prior. Elavon pushed back the date again and again, and Carmichael conceded that Elavon failed to meet any of the target dates.
Przybylek Dep. at 57:13-23, 58:14-16.
Tr. Ex. 240.
ECF No. 136 at 195:12.
Elavon cancelled its agreement with ATMMS in 2019 without providing a reason and before Commerce SDK ever supported PIN-debit transactions, and the parties have no relationship now. None of the casinos that ended their relationship with ATMMS became direct customers of Elavon. According to Poggi, at no point did Elavon advise him to pursue direct certification, and if it had, ATMMS would have done so, and Przybylek testified that he doesn't know if Elavon spoke with ATMMS specifically about fact that it could have accessed PIN-debit support through direct certification.
ECF No. 136 at 32:13-25.
ECF No. 140 at 60:16-18.
ECF No. 136 at 70:12.
ECF No. 127:17-22.
Przybylek Dep. at 96:6-10.
X. ATMMS sues Elavon.
ATMMS sued Elavon in 2018, asserting various claims, six of which survived to trial: fraud, negligent misrepresentation, breach of contract, bad faith, intentional interference with contractual relations, and intentional interference with prospective business relations.ATMMS alleges that Elavon negligently and intentionally represented that it would-and entered into an oral agreement with ATMMS to-be ready for the EMV standard by the liabilityshift date; failed to deliver contrary to its representations, the oral contract, and the covenant of good faith and fair dealing implied in that contract; and, in so doing, intentionally interfered with ATMMS's existing and potential contracts with customers. ATMMS asserts these claims based on three factual theories: (1) ATMMS failed to support any EMV-compliant transactions through Converge by the liability-shift date; (2) it failed to support certain transaction types like EMV PIN debit well past that date; and (3) it failed to support the L5200 payment terminal as Elavon's EMV-compliant POS device.
ECF No. 39.
Following remand from the Ninth Circuit at the summary-judgment phase, the parties proceeded to a three-day bench trial in December 2022. The court heard live testimony from Carter, Carmichael, and Poggi, along with the deposition testimony of Morris and Przybylek.
ECF No. 108, Ninth Cir. Case No. 20-15271.
The deposition testimony was submitted along with the parties' objections to various portions of that testimony. Because my findings and conclusions are not dependent on any of the objected-to testimony, I do not rule on those objections.
At trial, CEO Carter testified that ATMMS lost many of its larger casino clients because it was not ready for EMV in time. Carter blamed that failure for the significant downturn in ATMMS's business, including its transaction-processing volume falling from $5 million per month in early 2015 to a tenth of that now; reducing its former profits of $2 million per month; losing the ability to develop the company, buy more equipment, make deals, and hire employees; and downsizing its workforce from 30 people to 15.
ECF No. 136 at 39:18, 20, 40:15-16.
Id. at 42:8-9.
One exhibit at trial was a spreadsheet of ATMMS's transaction volume during its relationship with Elavon between 2013 and 2018. This spreadsheet includes columns for each month (and year) between 2013 and 2018, listing the number of merchants (Count); active merchants, i.e., those that processed transactions (Active Mid Count); the total amount in transactions ATMMS processed through Elavon (Net Volume); the number of transactions (No Tckts); and the amount of money Elavon paid ATMMS in residuals ($ MSP). Net volume climbed until 2015, peaking at $4,159,268 in March 2015; more or less steadily dropped until it reached just under $3,000,000 in August of that year; plummeted by about $750,000 in both September and October to a low of $1,473,067; and then rebounded to around $1,750,000 in November, where it stayed (plus or minus a few hundred thousand) for the remainder of the relationship. The number of active merchants grew from two at the beginning to 118 in October 2015 and dropped in December to around 100, where it stayed.
ECF No. 137 at 141:17-145:6; Tr. Ex. 280.
ECF No. 137 at 141:17-145:6.
The $174,135 number for December 2016 appears to be anomalous, but the parties failed to explain it.
This exhibit reflects only residuals, but Poggi testified that there were other damages. He said that ATMMS lost 7% on credit-card cash advances paid by the cardholder. These fees are based on contracts not in evidence. Poggi calculated the damages up to 2018 at $5,807,635.74. Going forward, Poggi pegged the damages at $187,401.89 per month, which sums the $129,332.80 estimate for quasi-cash losses and $67,069 for other financial products.Poggi also testified that ATMMS's business was growing into 2015 and then lost new and existing business because ATMMS couldn't verify that it would be EMV compliant by the liability-shift date. He averred broadly that ATMMS had to reduce its workforce and that its reputation was harmed because competitors were EMV compliant.
ECF No. 140 at 221:10-222:18.
Id. at 224:25-225:3.
Id. at 112:1-3, 123:24.
Id. at 124:3-126:19.
Id. at 129:21-130:7.
Id. at 130:18-22.
Conclusions of Law
I. ATMMS proved that Elavon negligently misrepresented that it would offer an EMV-compliant Converge solution by the liability-shift date, but it failed to prove any of its other claims.
A. Elavon negligently-though not intentionally-misrepresented that ATMMS would be able to process EMV-compliant transactions by October 2015.
ATMMS asserts claims of fraud and negligent misrepresentation. To establish its fraud claim under Nevada law, ATMMS must prove the following elements by clear and convincing evidence: (1) Elavon made a false representation; (2) Elavon knew or believed that the representation was false or had an insufficient basis for asserting it; (3) Elavon intended to induce ATMMS to act or refrain from acting in reliance on the misrepresentation; (4) ATMMS justifiably relied on the misrepresentation; and (5) that reliance harmed ATMMS. A negligent-misrepresentation claim also requires proof by clear and clear evidence of the first (false representation), fourth (justifiable reliance), and fifth (resulting harm) of these elements, plus a finding that Elavon “fail[ed] to exercise reasonable care or competence in . . . communicating” the representation. The clear-and-convincing-evidence standard does not require certainty, but the evidence must “persuade[] [the factfinder] that the truth of the contentions is highly likely” and elicit a “firm belief or conviction as to the allegations.”
Bulbman, Inc. v. Nev. Bell, 825 P.2d 588, 592 (Nev. 1992).
Halcrow, Inc. v. Eighth Jud. Dist. Ct., 302 P.3d 1148, 1153 (Nev. 2013), as corrected (Aug. 14, 2013) (quoting Second Restatement of Torts).
Nev. Civ. Jury Instruction 2.2.
1. Elavon falsely represented that it would support EMV-compliant transactions through Converge by the liability-shift date for customers like ATMMS.
ATMMS met the first element of its fraud claim. Though I find the record ambiguous as to whether Elavon made the verbal representation that Converge would be EMV ready by October 2015, the documentary evidence strongly supports that Elavon made it in writing. Indeed, for years leading up to the liability-shift date, Elavon barraged Poggi with messages implying that an EMV-ready solution was on the way. Several emails variously described the launch of “plug and play” EMV “terminal lines”; EMV-capable devices for Converge to prepare customers “for the future of EMV chip cards” because “Elavon wants to ensure you are properly equipped to position this revolutionary paradigm shift in our [i]ndustry!”; the ability to “remotely enable” devices to support EMV functionality; “next-generation . . . terminals” that would “be shipped EMV-enabled for your customers;” “lower EMV[-]equipment pricing . . . so your customers can be ahead of the October 2015 liability shift;” that “[t]o make sure we are fully prepared for the EMV liability shift in October, Elavon is taking every step possible to ensure a smooth transition for our customers” and “we are beginning our accelerated migration from non-EMV capable terminal and pin pad options to EMV enabled solutions;”and a software download to allow “customers to start accepting EMV transactions.”
Tr. Ex. 3.
Tr. Ex. 4.
Tr. Ex. 5.
Tr. Ex. 8 (emphasis in original); Tr. Ex. 11.
Tr. Ex. 14.
Tr. Ex. 20; Tr. Ex. 26.
Tr. Ex. 25.
To be sure, mass advertisements alone might not constitute an assertion that Elavon would offer ATMMS the EMV tools that it specifically needed by the EMV-compliance deadline. But Poggi repeatedly asked his assigned contacts at Elavon about EMV readiness for Converge, and Elavon responded that it planned for or expected a solution by various dates in 2015. Elavon sent these messages understanding the importance of EMV compliance, the consequences of non-compliance by October 2015, that ATMMS connected to Elavon's system through Converge, and ATMMS's reasons for doing so. It also was on notice that ATMMS bought the L5200s and entered the Commerce SDK beta program in anticipation of the EMV transition. And Elavon's technology supported ATMMS's integration to Converge prior to the EMV transition. So, viewing the totality of the written communications in that context, I find that Elavon represented that it would offer both equipment and software for ATMMS to process EMV-compliant transactions through Converge by the liability-shift date.
See, e.g., Tr. Ex. 12 (noting that Elavon was “formulating a plan for 2015”); Ex 13 (Elavon “anticipated having EMV available for Converge in Q1 or Q2” of 2015).
ECF No. 136 at 95:19-99:3.
Id. at 100:11-101:1.
Morris Dep. at 11:9-14; Tr. Ex. 12.
ECF No. 137 at 176:15-177:13.
Elavon's attempts to run from its own communications fail. Though Carmichael testified that some of the EMV-related newsletters applied only to class A clients and not ATMMS, the emails didn't make that distinction clear. That defense also ignores the individualized responses to Poggi's questions about the timeline for EMV for Converge. Also, that ATMMS may be a sophisticated industry player and Poggi understood that ATMMS had to program some code on its own is of no moment: though ATMMS had some responsibility for integrating its software into Converge even with Commerce SDK, Elavon represented that it would be possible for ATMMS to do that. And Elavon's telling ATMMS before the liability-shift date that it wouldn't meet the deadline shows that it was at least aware of ATMMS's goal of being compliant by that date.
ECF No. 140 at 5:20-25.
Tr. Ex. 12.
ECF No. 149 at 6.
Tr. Ex. 31.
Yet the representation that Elavon would provide the tools ATMMS needed to integrate MCC into Converge by October 2015 was false, and Elavon knew it. Przybylek testified that Elavon never intended to achieve the solution ATMMS sought by the liability-shift date. Also, the evidence shows that Elavon likely lacked a sufficient basis to continuously tout its EMV technology for Converge-reliant customers, as it did not even begin its beta program for Commerce SDK until well into 2015. So the first and second elements of the fraud and negligent-misrepresentation claims are satisfied.
2. ATMMS justifiably relied on Elavon's misrepresentations to its detriment.
ATMMS also met the last two elements of its fraud claim (justifiable reliance and harm). The justifiable-reliance requirement “does not impose a duty to investigate absent any facts to alert the defrauded party his reliance is unreasonable.” Rather, a “party has a right to rely on an express statement of existing fact, the truth of which is known to the party making the representation and unknown to the other party.” However, a person may not rely on a representation if he “has information [that] would serve as a danger signal and a red light to any normal person of his intelligence and experience.”
Collins v. Burns, 741 P.2d 819, 821 (Nev. 1987).
Id.
Id.
Applying these principles, ATMMS's reliance on Elavon's representations about its EMV technology was justified. Poggi credibly testified that ATMMS would have hired a different processor or developed its own software if he knew that Elavon would not deliver on its assertions. That testimony comports with emails from Poggi during the relevant time period that ATMMS depended on an Elavon solution for EMV compliance. The parties had a good working relationship and together already integrated MCC to Elavon's system once before. Elavon understood the importance of EMV compliance to the industry and ATMMS specifically, and I find that it never told ATMMS that Commerce SDK would not be a viable option by the liability-shift date. By contrast, a long parade of emails touted Elavon's EMV readiness and made no distinctions by types of customers. So I find that ATMMS was entitled to put faith in Elavon's representations.
ECF No. 140 at 197:22-25, 200:18-21, 203:17.
Tr. Ex. 98.
ECF No. 137 at 229:16-230:6.
ECF No. 140 at 146:2-147:8.
ECF No. 136 at 95:19-99:3.
ECF No. 140 at 6:23-7:1, 8:4-8.
See, e.g., Tr. Ex. 3; Tr. Ex. 4; Tr. Ex. 5.
That faith caused ATMMS harm. Carter's testimony revealed that casino customers fled ATMMS once they found out that it would not be EMV compliant. Common sense supports that notion-why wouldn't a large business switch to an ATM services provider that provided technology that helped shield it from chargeback liability? Elavon's business records also show a decline in ATMMS's processing volume and the residuals it received around the liability-shift date. That fact supports the inference that ATMMS's harm was caused by its failure to be EMV compliant for customers like ATMMS by the liability-shift date. So ATMMS established the reliance and harm elements of their fraud and negligent-misrepresentation claims.
ECF No. 136 at 39:18, 20, 40:15-16.
Tr. Ex. 280.
Of course, harm must not be conflated with amount of compensatory damages. While ATMMS has proven harm, it has not tied that harm to a reasonably accurate dollar amount. See infra at pp. 44-48.
Elavon's contentions to the contrary lack merit. It first tries to shift the blame onto ATMMS because it pursued Converge rather than shift to a direct-integration approach. But ATMMS had no obligation to take an alternative path in the face of representations that ATMMS would have an EMV-compliant Converge product ready by the liability-shift date. Plus, shifting gears would have required ATMMS to expend additional resources and comply with additional requirements, and it's unclear to the court whether direct integration would even support MCC.
ECF No. 149 at 33.
Elavon next argues that any reliance on moving target dates was unreasonable. True enough, an ordinary person would not rely on explicitly tentative dates. But the misrepresentations on which I find that ATMMS reasonably relied are not each and every provisional goal before the liability-shift date but rather the totality of the messages that implied that Elavon would provide an EMV solution by that date. Those representations were false, as Elavon knew it wouldn't deliver by October 2015 and put compliance for ATMMS on the backburner for several years in favor of a focus on products for Canada.
Id. at 34.
Przybylek Dep. at 36:20-37:12.
3. Because the evidence shows that Elavon acted negligently but not intentionally, ATMMS is entitled to judgment in its favor on its negligent-misrepresentation claim but not its fraud claim.
ATMMS proved that Elavon acted unreasonably in communicating the misrepresentations. I find that a reasonable actor in Elavon's situation would have tamed its communications by distinguishing between customers like ATMMS and those directly certifying or adding caveats about its EMV readiness. When Poggi expressed the importance of EMV compliance by the deadline, Elavon could have advised ATMMS that direct certification was the only path to that solution. But it did not, and no documentary evidence shows that it even pushed back on Poggi's expectation. Also, that Elavon employees lobbied so hard for amnesty and discounted the iSC250s suggests that they knew that Elavon should have done more for its customer. And some evidence indicates that Elavon was experiencing a right-hand-left-hand problem as its relationship managers weren't coordinating with its other teams in communicating with ATMMS about EMV compliance. So I find that Elavon “fail[ed] to exercise reasonable care or competence in . . . communicating” the representations to ATMMS.
ECF No. 136 at 135:25-136:2.
See, e.g., ECF No. 136 at 189:9-192:20.
But ATMMS has not shown that Elavon “intended to induce ATMMS to act or refrain from acting in reliance on the misrepresentation,” especially by clear and convincing evidence. The record is virtually devoid of direct evidence that Elavon acted intentionally to string along ATMMS. To be sure, Carmichael admitted that her team wanted to keep ATMMS as a partner and took actions with that aim, such as requesting amnesty. But I find that Elavon did not mean to convey that it would offer ATMMS EMV-compliant technology by the liability- shift date or any date certain. The deposition testimony-especially that of Bob Morris, who no longer works for Elavon-lends support to this notion. As do some of the carefully crafted emails and agreements characterizing the dates as moving targets and the fact that the product was being developed for a wide variety of customers, not just ATMMS. Plus, Poggi previously testified that he did not think Elavon acted intentionally and only at trial claimed otherwise. And he even sent an email to the Elavon team in 2016 expressing gratitude for its work on EMV compliance.
See Halcrow, 302 P.3d at 1153.
ECF No. 136 at 135:25-136:2, 137:20-22; Tr. Ex. 32.
See, e.g., Tr. Ex. 31; Tr. Ex. 39.
Przybylek Dep. at 9:16-20, 42:18-43:2.
ECF No. 140 at 215:23-25.
Tr. Ex. 288.
The evidence on Elavon's potential motivation also casts doubt on Elavon's intentionality. Surely Elavon had a financial motivation to keep ATMMS as a client, but ATMMS's lack of compliance with EMV also hurt Elavon's bottom line, as it earned fees from ATMMS's sub-merchants' transactions. Also, some evidence suggests that Elavon's directcertification option-something Poggi testified that he would have pursued if Elavon re-offered it to him-was mostly EMV compliant by the liability-shift date. Why would Elavon intentionally mislead ATMMS about Converge to keep it as a customer if it could have simply told Poggi that direct certification would satisfy his EMV needs? The record suggests no answer that provides this court with a firm conviction that Elavon acted purposefully.
ECF No. 140 at 197:22-25, 200:18-21, 203:17.
ECF No. 137 at 227:18-20.
Even though Elavon knew that its representation was false, ECF No. 152 at 11, ATMMS must still separately show this element.
Having failed to prove the element of intentionality, I find that Elavon is not liable for fraud. But, as ATMMS proved every element of its negligent-misrepresentation claim-false misrepresentation, negligence, justifiable reliance, and resulting harm-I enter judgment on that claim against Elavon and in favor of ATMMS.
B. ATMMS's contract-based claims fail because the evidence does not show that the parties formed a contract about software.
1. The parties did not agree on the essential terms of the contract.
ATMMS also brought a claim for breach of contract, alleging that Elavon breached its oral agreement to “be ready for the transition to EMV global payment standard.” The formation of a contract requires “an offer and acceptance, meeting of the minds, and consideration.” The parties' minds have met if they “have agreed upon the contract's essential terms,” and what those terms are “depends on the agreement and its context and also on the subsequent conduct of the parties, including the dispute which arises and the remedy sought.”
ECF No. 39 at ¶ 74.
Certified Fire Prot. Inc. v. Precision Constr., 283 P.3d 250, 255 (Nev. 2012) (citing May v. Anderson, 119 P.3d 1254, 1257 (Nev. 2005)).
Id. (citing Restatement (Second) of Contracts § 131 cmt. g (1981)).
In light of the contours of the parties' dispute, I find that the essential terms of the alleged oral agreement include Elavon's providing an EMV-compliant software solution that allowed ATMMS to process transactions through Converge by the liability-shift date and, when that failed, in a reasonable time. The complaint alleges that “Elavon agreed . . . that it would be ready for the transition to EMV,” and the dispute at trial centered on Elavon's responsibilities for ensuring that ATMMS could process EMV transactions. Poggi's testimony-plus the documentary evidence that some of its business dried up in the last quarter of 2015-also evinced the importance of ATMMS's securing EMV technology by the October 2015 liabilityshift date.
Though these terms were essential, ATMMS failed to prove that the parties agreed to them. Poggi testified that the parties entered into an agreement, but I do not find that testimony credible or persuasive. It may be true that Elavon made oral representations to Poggi, but I do not find that those representations amounted to an agreement. While Elavon mispresented what it planned to provide ATMMS, nothing in the documents corroborates that the parties entered into a contract or agreed to these terms on a specific timeline. In light of the frequency of email exchanges between the parties and the fact that they entered into multiple written agreements, it strains credulity that no one on either side would at least send an email listing the essential terms of the contract at some point in the parties' yearslong relationship. And the regular advertisement and update-style emails, most of which were sent to many organizations, do not show that the parties specifically entered into an agreement. Plus, Eric testified-and ATMMS argues-that Elavon never intended to offer the Commerce SDK/Converge solution by the liability date. This calls into question why Elavon would enter into an agreement that it would provide a non-direct software solution by a date certain with no intention of performing under that agreement. If Elavon merely wanted to keep ATMMS's business, it could have offered the direct-integration solution.
Though ATMMS brings no claim as to the Commerce SDK agreement, to the extent ATMMS also theorizes that, regardless of its meeting the liability-shift deadline, Elavon orally agreed to develop Commerce SDK in a reasonable timeframe, I find that this theory fails for lack of breach. Elavon delivered a solution around a year after the parties entered into the Commerce SDK agreement, and Poggi sent an email showing gratitude for that work-undermining the idea that Elavon didn't fulfill its end of any purported bargain. See Tr. Ex. 186; Tr. Ex. 188.
2. Because there was no contract, the bad-faith claim also fails.
Elavon based its bad-faith claim on the oral contract, not on the written Commerce SDK agreement. So I do not address whether Elavon breached the covenant of good faith and fair dealing in that written agreement.
ATMMS's claim for breach of the covenant of good faith and fair dealing fails for lack of a contract. “[E]very contract imposes upon the contracting parties the duty of good faith and fair dealing.” ATMMS based its bad-faith claim on the duty “[i]mplied in the oral agreement”that I find never existed. With no contract, there's no implied covenant of good faith and fair dealing. So I find that ATMMS failed to prove its bad-faith claim.
Hilton Hotels Corp. v. Butch Lewis Prods., Inc., 862 P.2d 1207, 1209 (Nev. 1993).
ECF No. 39 at ¶ 84; ECF No. 146 at 26.
C. ATMMS lacked proof of intent to support its contractual- and businessrelations claims.
ATMMS asserts claims for intentional interference with contractual relations and prospective business relations. Its contractual-relations claim requires proof of (1) a valid and existing contract; (2) Elavon's knowledge of the contract; (3) intentional acts intended or designed to disrupt the contractual relationship; (4) actual disruption of the contract; and (5) resulting damage. The prospective-business-relations claim similarly has five elements: (1) a prospective contractual relationship between the plaintiff and a third party; (2) knowledge by the defendant of the prospective relationship; (3) intent to harm the plaintiff by preventing the relationship; (4) the absence of privilege or justification by the defendant; and (5) actual harm to the plaintiff as a result of the defendant's conduct. As the Ninth Circuit previously held in this case, to prove the intent elements of both claims, ATMMS must show that Elavon either “desire[d] to bring . . . about” the interference or knew “that the interference [was] certain or substantially certain to occur as a result of [its] actions.”
J.J. Indus., LLC v. Bennett, 71 P.3d 1264, 1267 (Nev. 2003).
In re Amerco Derivative Litig., 252 P.3d 681, 702 (Nev. 2011).
ECF No. 108 at 7-8.
Applying this standard, I find that ATMMS failed to prove intent at trial. Rather, the evidence shows that the parties maintained a strong relationship, and Elavon's motive (if any) was to keep ATMMS as a customer, not to harm it or disrupt its business relationships. Indeed, Elavon's relationship with ATMMS was mutually beneficial, as ATMMS brought something different to the table than any of Elavon's other clients and Elavon stood to gain every time an ATMMS customer processed a transaction. Even Poggi did not believe that Elavon acted intentionally until trial. So I find that ATMMS didn't prove that Elavon acted intentionally.
ECF No. 137 at 158:17-25, 178:4-6; Morris Dep. at 21:30-22:6.
ECF No. 140 at 215:23-25.
Nor did ATMMS prove that Elavon knew that its actions would impede ATMMS's existing or prospective business relationships. ATMMS's actions told Elavon otherwise: it stuck with Elavon even after learning that it would not support the original equipment and learning that it would not support EMV through Converge by the liability-shift date. And it stuck with the Commerce SDK/Converge option, rather than pursuing the direct-certification path, throughout the parties' relationship. Even if ATMMS didn't know it could switch to the more direct option, the inquiry is about Elavon's subjective state of mind. Viewing the situation from Elavon's perspective, it could fairly assume that ATMMS would alter course to keep its business relationships from suffering. Because it didn't, Elavon had little reason to know that its (in)actions would harm ATMMS's business. So I find ATMMS's intentional-interference claims unproven.
I also find that ATMMS failed to prove that Elavon had knowledge of any prospective business relationship. The evidence of Elavon's knowledge of existing contracts is slim too. That Elavon knew about ATMMS's “niche” services does not mean that it knew of specific prospective relationships. ECF No. 146 at 24.
D. ATMMS's claims under the theory that Elavon failed to provide EMV PINdebit technology weren't proven.
Having addressed the claims that are based on ATMMS's theory that Elavon failed to deliver EMV compliance at all by the liability-shift date, I now address the claims based on the theory that Elavon failed to deliver EMV PIN debit at any point during the parties' relationship. I find that Elavon did not represent-let alone, enter into an agreement-that Commerce SDK would specifically support PIN debit by the liability-shift date. Little, if any, of the documentary evidence before October 2015 even addressed that particular technology, and the evidence of any oral agreement is too ambiguous to infer any contract. Plus, Poggi testified that he believed Elavon's representations only in part-suggesting that he did not actually rely on purported promises that Elavon would deliver every type of EMV functionality by the liability date. Though Elavon may have represented that the technology would come in a reasonable time after the EMV compliance deadline, any reliance on such a representation was not justified: Elavon missed the liability-shift date for Converge EMV technology, Poggi knew that Elavon prioritized work in Canada, and Elavon kept pushing its target dates. These red flags would have put a reasonable person on notice that PIN-debit functionality would not be timely. Regardless, the EMV PIN-debit theory suffers from a lack of causation: ATMMS's business losses appear to have stemmed from the failure to be EMV compliant at all by 2015. And it remains unproven whether ATMMS could have retained that business if it had some EMV functionality, even if not PIN-debit support, by that date. Finally, I find that Elavon did not act with knowledge or intent. So no claim based on the EMV PIN-debit theory was proven at trial.
Id. at 87:10-15.
Collins, 741 P.2d at 821.
E. ATMMS didn't prove its claims under its hardware theory.
ATMMS's final theory-that Elavon failed to deliver EMV compliant L5200 terminals- suffers from similar defects as its EMV PIN-debit one. As to the misrepresentation claims specifically, the Ninth Circuit affirmed the dismissal of the fraud claim on this theory for lack of “evidence showing that Elavon knew that its representations about the Equinox L5200 were false when made in 2013.” The negligent-misrepresentation claim suffered from a similar dearth of proof at trial, as the evidence revealed almost no evidence that statements about the L5200s were communicated even negligently. Though Elavon initially offered those devices as the EMV solution to its customers, it adjusted its messaging once it realized that it would instead support the iSC250s. There is no persuasive evidence that Elavon should have known that it would not support the L5200 or that it significantly delayed the announcements about the switch.
ECF No. 108 at 6.
The contract claims also fail under this theory. Though Elavon didn't provide EMV-supported L5200s, it eventually offered the iSC250s as an alternative. ATMMS ultimately accepted that alternative, and Elavon swapped the devices out at a discount, recognizing that ATMMS used the L5200s for multiple years but that it expected them to be Elavon's supported EMV solution. Also, as I found that Elavon did not act negligently, ATMMS cannot show that Elavon acted in bad faith.
ECF No. 137 at 107:17-23.
Id.
Finally, ATMMS failed to prove intent-for the same reasons it failed to do so as to the other theories-and causation. Indeed, the cause of ATMMS's harm was not a lack of equipment, as it had L5200s and then iSC250s to support its customers; rather, the lack of software for those devices to process EMV-compliant transactions through MCC caused its harm. So ATMMS's equipment theory fails.
II. ATMMS is entitled only to nominal damages because it failed to satisfy its burden to show a reasonably accurate amount of damages.
In any event, the evidence appears to show that ATMMS was already made whole with respect to the equipment in the form of the swap to the iSC250s and, to the extent it was not, ATMMS offers no reasonably accurate way to measure the disparity.
Under Nevada law, the plaintiff must prove the amount of its damages with “substantial evidence”-that is, provide an “an evidentiary basis for determining a reasonably accurate amount of damages.” Though the calculation of damages “need not be proven with mathematical certainty, testimony on the amount may not be speculative.” If the plaintiff “prove[s] a right to damages without proving the amount,” it is entitled to nominal damages only.
Alper v. Stillings, 389 P.2d 239, 240 (Nev. 1964).
Mort Wallin of Lake Tahoe, Inc. v. Com. Cabinet Co., 784 P.2d 954, 955 (Nev. 1989).
Clark Cnty. Sch. Dist. v. Richardson Const., Inc., 168 P.3d 87, 97 (Nev. 2007).
Alper, 389 P.2d at 240.
A. Poggi's testimony does not constitute substantial evidence of the amount of damages.
At trial, ATMMS's damages case relied predominantly on Poggi's testimony. He testified that he calculated the damages due to Elavon's failures at $5,807,635.74 up through November 28, 2018, plus $120,332.80 (for losses related to quasi-cash services) and $67,069.09 (for losses related to other services) per month thereafter. He added that he reduced these numbers to a writing in 2018 based on ATMMS's business records-records that were not presented as evidence. He also explained that his figures account for not only the fees ATMMS received from Elavon but also a 7% transaction fee paid by cardholders who use their services.
ECF No. 140 at 122:6-124:9, 126:8-19.
Id. at 124:25-125:12. That writing was not admitted as evidence but was used to refresh Poggi's recollection during trial. Id. at 125:19-24.
Id. at 221:11-222:15.
In pointing to this testimony, ATMMS essentially asks me to blindly trust that Elavon's actions caused it millions of dollars in losses. Though ATMMS argues that Poggi's figures represent “nothing more than a simple math calculation based on the history of lost transactions, the amount of those transactions, and the anticipated fees,” Poggi provided scant detail about the purported bases for his computations and leaves this court with key questions unanswered like: What transactions were lost, and how much were they for? What business records are these based on, and where are they? Does the 7% fee apply to all transactions, or did Poggi simply use that “easy figure[]” as an example or for just some transactions? Are the prospective losses indefinite, and do they account for ATMMS's changes in overhead costs? Do the figures even represent profits or merely revenue?
ECF No. 152 at 12-13.
Id. at 12-13.
ECF No. 141 at 221:19-20.
ATMMS notes that Poggi's testimony was unrefuted. ECF No. 146 at 30. But the defendant had no obligation to refute ATMMS's damages calculation until ATMMS met its own burden.
Perhaps if Poggi were an accountant or had otherwise established some evidentiary foundation for his calculations and assumptions, his testimony alone could constitute sufficient evidence of damages. But he earned an associate degree in general education -not accounting, business, finance, or the like. And, though he has many years of experience in management, including as the general manager of ATMMS, he merely “interact[s] with [its] accounting department” and did not testify as to any experience in calculating any financial figures for ATMMS apart from this litigation. So, while he may meet the personal-knowledge requirement of Rule 602, his testimony does not persuade me to accept his unsupported figures as anything more than speculation.
ECF No. 140 at 139:20-23.
Id. at 57:10-13, 21-25.
B. No other evidence allows the court to calculate a reasonably accurate amount of damages.
In light of the lack of evidence, I need not and do not reach Elavon's argument that ATMMS failed to mitigate damages. ECF No. 149 at 24.
ATMMS does not appear to rely on Carter's minimal testimony on damages-and for good reason. Carter merely testified that ATMMS processed $5 million per month in customer payments with $2 million per month in profits (or 40% of processing volume) before the liability-shift date and now processes only $500,000. But Carter never testified to ATMMS's current profits, leaving me to speculate whether they still are 40% percent of revenue or more (or less) in light of changes in overhead costs like staffing. Even if Carter had supplied that missing information, his estimates reflect an inflated sense of reality: ATMMS's processing through Elavon topped out at $4.16 million in March 2015 and hovered around $3.5 million in the months before and after-well shy of the $5 million figure Carter testified to. And, like Poggi, Carter's position (CEO) and job requirements (“oversee[ing] everything” and doing “all the contracts and negotiations”) suggest that his view of damages is a big-picture one, too, and he also offers no explanation of his estimates and provides no documentary evidence to support it.
ECF No. 136 at 39:24-40:9, 41:19.
Id. at 42:8-9.
Tr. Ex. 280.
ECF No. 136 at 15:6-18.
The only evidence that might allow me to calculate damages in a reasonably accurate way is the spreadsheet of ATMMS's processing through Elavon-an Elavon business record. This spreadsheet includes columns for each month between 2013 and 2018 listing the number of merchants; active merchants, i.e., those that processed transactions; the total amount in transactions ATMMS processed through Elavon; the number of transactions; and the amount of money Elavon paid ATMMS in residuals. And it shows a decline in merchants and volume in the last quarter of 2015-right after the liability-shift date. But the spreadsheet also shows that the downturn started (albeit, not as precipitously) before the liability shift in early 2015 and illustrates significant fluctuations in processing volume both before and after October 2015, making it impractical for this court to untangle how much of ATMMS's loss was driven by Elavon's failures versus other factors such as issues internal to ATMMS and market volatility. The record is devoid of evidence to address this concern. Also, the spreadsheet doesn't include information about fees from cardholders, which appear to make up the vast majority of ATMMS's purported damages, or information after 2018. So, because doing so would amount to speculation, I cannot calculate ATMMS's damages from the spreadsheet either.
Tr. Ex. 280.
ECF No. 137 at 144.
Tr. Ex. 280.
While ATMMS proved that Elavon caused it some harm, the court is left without sufficient evidence to put a dollar figure on that harm. With no way to bridge that evidentiary gap, I award ATMMS only nominal damages of $1.
C. Punitive damages are unwarranted.
The evidence also does not support a punitive-damages award. Exemplary damages are available if “the plaintiff proves by clear and convincing evidence that the defendant is guilty of oppression, fraud or malice, express or implied.” “[T]o justify punitive damages, the defendant's conduct must have exceeded mere recklessness or gross negligence.” But, as I found that ATMMS proved its negligent-misrepresentation but not fraud claim, I likewise find that Elavon's actions arose from bad business practices that amount to mere negligence;
Garcia v. Awerbach, 463 P.3d 461, 464 (Nev. 2020).
Id. (emphasis in original).
ATMMS did not prove that Elavon acted with the intent to injure it or a “conscious disregard” of its rights. So I find that an award of punitive damages is not available on this record.
Id. (defining oppression, fraud, and malice to variously require acting with intent to injure or “a conscious disregard” of another person's rights or property and equating a “conscious disregard” with “knowledge of the probable harmful consequences of a wrongful act and willfully and deliberately fails to act to avoid those consequences”) (cleaned up).
Conclusion
Based on these findings of fact and conclusions of law, and with good cause appearing and no reason for delay, IT IS HEREBY ORDERED, ADJUDGED, AND DECREED that:
• Final judgment is entered in favor of Plaintiff JB Carter Enterprises, LLC dba ATM Merchant Systems and against Defendant Elavon, Inc. on the plaintiff's claim for negligent misrepresentation based on the theory that Elavon failed to deliver an EMV solution by October 2015 in the amount of $1; but
• Final judgment is entered in favor of the defendant and against the plaintiff on all other claims and theories.
This order leaves no claims pending, so the Clerk of Court is directed to ENTER FINAL JUDGMENT accordingly and CLOSE THIS CASE.