Will an EZPass mobile payment partnership work? It very well could
Updated: Feb 12, 2019
Over the decades, major technology advances have typically fallen into one of two categories: truly disruptive, where the approach is meaningfully different from anything that exists; and piggyback, where the technology leverages something that already widely exists, thereby sharply reducing both the cost of implementation and any needed behavioral changes.
In short, piggyback advances are seen as less risky and easier to adopt. (My favorite piggyback mobile implementation is several years old and came from Macy's, which opted to leverage the huge number of audio speakers in its stores as a low-cost way to identify customers for loyalty programs.)
Whereas Amazon, Uber and Tesla may get more pages in the history books, piggyback CEOs will have an easier time in making a lot of revenue. In 2018, this brings us to mobile payments, an operation called Verdeva and a program called PayByCar. Verdeva cut a deal with the popular toll-payment RFID tag EZPass — which EZPass' website says is currently used in 17 states in the U.S. — to allow EZPass to be detected by a merchant; the transponder number will then link to a PayByCar account.
A multifactor authentication — which really isn't one, but more on that in a moment — has the merchant system also checking for a mobile phone number. The system needs to see both the RFID transponder and the customer's phone for a transaction to be approved.
By the way, given that any sufficiently powered RFID reader can detect the transponder number of any EZPass tag, why did PayByCar have to cut a deal with EZPass? It really didn't, but to avoid any legal challenges and to get EZPass onboard as a marketing partner, EZPass gets a cut of any purchases made through PayByCar, according to someone working closely with PayByCar.
Why am I questioning whether a phone and an RFID tag aren't a true two-factor authentication? From a security perspective, the whole point of requiring multiple points of authentication is to avoid a thief being authenticated. If a thief steals a phone from a shopper's purse, the thief must also know a PIN or be able to replicate a fingerprint or a face. This is the old something-you-have-something-you-know-something-you-are standard.
The problem here is that it's not unusual for shoppers to leave their phone in their car (it's not at all wise, but it's still done), especially for a quick purchase such as at a gas station or a convenience store — which are exactly the kinds of merchants Verdeva is trying to register. So if a thief breaks into a car — or gets lucky enough to find an unlocked car door—it's fast and easy to rip off the Velcro-like-material-attached EZPass tag and grab the phone.
With no password or PIN or biometric authentication required, the thief's work is mostly done. Fortunately, PayByCar has thrown up a few other hurdles. The current trials, happening in three Massachusetts locations, also leverage texting, with the shopper texting back a confirmation number. In the future, these communications may happen more securely within the PayByCar mobile app.
Also, thieves are unlikely to try to steal the RFID tag and the phone unless they have reason to believe the customer is using PayByCar. That could be done, though, by someone parking in front of a participating merchant and sniffing all mobile traffic until it detects PayByCar app traffic. If it can zero in on the vehicle, the target has been identified.
Security concerns aside, this is a creative approach to get around the current mobile payment chicken-and-egg nightmare. That's where merchants are hesitant to invest in a system until a lot of its shoppers use it, while those shoppers are hesitant to adopt a mobile payment system until they see a lot of their merchants using it. By changing the discussion from, for example, "How many of your customers use ApplePay?" to "How many of your customers use EZpass?," the merchant discussion is likely to go far better.
It should be noted that, initially, PayByCar is "not meant for in-store" purchases, said Kevin Condon, who is CEO and founder for both PayByCar and its Verdeva parent company. He said it's more envisioned to deal with gas stations, convenience stores and drive-through restaurants. (Note: the drive-through restaurants would seem to be a more secure option, since the driver presumably would never leave the vehicle.)
At gas stations, the customer would have to text the system back with the pump number, which could then be remotely activated.
There is one other obstacle that PayByCar must overcome. The current card brand rules — may I say ludicrously outdated and ridiculous rules? Yes, I think I may say that — would almost certainly classify these payments as the higher-interchange-fee card-not-present type. Why?
The charges won't appear on an EZPass account, but will simply be charged to whatever payment card customers opt to associate with their PayByCar accounts. Hence, it will look to the processor like any other e-commerce transaction and generate the higher CNP charge.
This despite the fact that there is ample physical evidence that the customer (or at least the customer's EZpass tag and phone) were indeed very much present. With more and more transactions leveraging the card information rather than the EMV chip or the magstripe of the physical card itself, card brands need to rethink CNP rules. The original intent was to charge more for a riskier transaction. How is an ApplePay charge — authenticated by fingerprint or facial recognition as well as physical possession of the phone itself — less secure than someone swiping a card at a store that has yet to accept EMV?
If merchants have to pay more to permit a PayByCar transaction rather than simply taking the shopper's payment card, will they be more resistant? Maybe not. Nothing is more crucial to gas stations and drive-through restaurants than speed, which translates to better customer service.
Just like the EZPass toll system allows a car to never have to stop at a toll, this could allow the shopper to never have to reach into his/her wallet/purse to get a payment card.
On the other hand, is entering a variety of keystrokes into a mobile app and the texting back and forth really easier and faster than handing an associate a payment card?
This still is an impressive mobile payment approach that could indeed move the (currently stuck) needle for mobile payment acceptance, and a lot of questions will be answered by the current trials. I will say this, though: Creativity such as this is to be applauded if we're ever to get mobile payments moving.