Ahh springtime, flowers and the annual Apple Platform Security (APS) update. This year’s version has many Apple Pay housekeeping changes. Previous versions put everything Apple Pay in a single section. In keeping with Apple spinning out iOS 15 Wallet app as a separate identity, Wallet has its own separate section now, covering all the things Jennifer Bailey unveiled at WWDC21: hotel-home-office keys and ID in Wallet. The Apple Pay section adds a new category for Tap to Pay on iPhone with some interesting bits.
The Tap to Pay on iPhone servers manage the setup and provisioning of the payment kernels in the device. The servers also monitor the security of the Tap to Pay on iPhone devices in a manner compatible with to the Contactless Payments on COTS (CPoC) standard from the Payment Card Industry Security Standards Council (PCI SSC) and are PCI DSS compliant.
The Tap to Pay on iPhone server emits decryption keys to the Payment Service Provider after validation of the integrity and authenticity of the data, and after verifying that the card read was within 60 seconds of the card read on the device.
What’s interesting to me is that Tap to Pay on iPhone servers are providing a seamless payment reader experience in the same way that Apple Pay servers provide a seamless pay experience. It just works, from setup to use, the same tight integration allows payment service providers to focus on POS app development and forget about the hardware because Apple Pay takes care of everything. As Junya Suzuki tweeted recently, a lot of payment reader hardware is suddenly junk compared to what iPhone is providing with tight mobile integration and Tap to Pay servers on the backend. Now with Tap to Pay apps on the horizon, good thing that iOS 15 Wallet expanded the secure element max to 16 ain’t it?
Speaking of Wallet, this separate section covers all things “access credential” related (hotel-corporate-home-car-student ID) with App Clips suggested for provisioning multifamily home keys. Transit now includes eMoney cards (or is it e-Money, Apple seems confused about it just like Express Mode vs Express Transit) and IDs in Wallet is covered in detail. There is also an intriguing iOS 15.4 Wallet security tweak:
In iOS 15.4 or later, when a user double-clicks the side button on an iPhone with Face ID or double-clicks the Home button on an iPhone with Touch ID, their passes and access key details aren’t displayed until they authenticate to the device. Either Face ID, Touch ID, or passcode authentication is required before pass specific information including hotel booking details are displayed in Apple Wallet.
It sounds almost exactly what we already do with regular Apple Pay cards. Perhaps keys and passes only show a generic icon and checkmark with Express Mode with the double-click + authentication required for show details…it’s not very clear.
The whole security expert thing reminds me of what my uncle the doctor (who ran a medical research lab at Columbia University) used to say about his disdain for pharmaceutical companies, “They don’t want to cure you, they just want to keep ‘treating’ you with their medicines.” Human nature never changes. The gist is that EMV Express Transit Mode will always be a thorn in Apple Pay’s side because the security is up to the card companies.
The document is worth your time is you have any interest in Apple Pay and Wallet.
(The) Digital Markets Act will…require companies designated as gatekeepers to ensure effective interoperability with hardware and software features they use themselves in their ecosystems. This includes access to NFC for mobile payments.
Today’s case addresses a conduct by Apple that has been ongoing since Apple Pay was first rolled out in 2015 <sic, 2014 actually>. This conduct may have distorted competition on the mobile wallets market in Europe. It prevented emergence of new and innovative competition that could have challenged Apple.
Both pieces miss important context surrounding the debate however…and with this issue context is all, especially how Apple Pay is playing out in other global markets. Most of what follows I’ve covered in earlier posts but hope to pull the various issues together in one post. Yet again, we kickoff with an updated Apple Pay diagram.
The so called Apple ‘NFC chip’ is not a chip at all but a hardware/software sandwich. The Apple Pay ecosystem described in iOS Security is a collection of tightly integrated polished pieces: Secure Element, Secure Enclave, NFC Controller, Wallet and Apple Pay Servers, all wrapped into a slick, easy to use UI with a final security wall of ‘secure intent’, a double-click side button hot-wired to the Secure Element. This approach has been so successful that people divide mobile payments history into pre-Apple Pay and post-Apple Pay eras.
Apple Pay has a very simple rule: any card that loads a Java Card applet into their embedded secure element (eSE) has to reside in Wallet app. The maximum number depends on how many Java Card applets it can hold at any one time, the previous limit was 12, the iOS 15 Wallet limit is 16 cards. Developers have two ways to access iPhone NFC: 1) Core NFC framework for NFC operations that don’t use the secure element, 2) Secure Element pass certificates for NFC operations that need secure element transactions (payments, keys, ID, passes). Any developer who wants to run applets in the eSE has to apply for a PassKit NFC/Secure Element Pass Certificate. This is covered by NDA but a company called PassKit (not Apple) gives us an idea what Apple’s Secure Element Pass guidelines are:
Apple care a great deal about the user experience. Before granting NFC certificate access they will ensure that you have the necessary hardware, software and capabilities to develop or deploy an ecosystem that is going to deliver an experience consistent with their guidelines.
The end to end user experience, the whole reason behind the success of Apple Pay. But this gatekeeping is what riles banks and financial service providers who want to load their applets into the secure element without the Apple Pay gatekeeping, without the Apple Pay ecosystem and without the Apple Pay commission. They want to do their own transactions with their own app for free. This is what the EU Commission means when Vestager says: “Evidence on our file indicates that some developers did not go ahead with their plans as they were not able to to (sic) reach iPhone users.” It should read: when they were not able to reach iPhone users for free. Either the developer didn’t apply for a Secure Element Pass, didn’t pass the certification process, balked at Apple’s certification conditions, or couldn’t agree on Apple Pay commission rates.
Secure element gatekeeping is not new, it is an essential part of the secure element system:
A Secure Element (SE) is a microprocessor chip which can store sensitive data and run secure apps such as payment. It acts as a vault, protecting what’s inside the SE (applications and data) from malware attacks that are typical in the host (i.e. the device operating system). Secure Elements handle all sorts of applications that are vital to our modern digital lives…
Mobile Payments Here, the Secure Element securely stores card/cardholder data and manages the reading of encrypted data. During a payment transaction it acts like a contactless payment card using industry standard technology to help authorize a transaction. The Secure Element could either be embedded in the phone or embedded in your SIM card.
Lifecycle management It’s crucial that SE-embedded devices are secure throughout their lifecycle. That’s why Secure Elements need to have an end-to-end security strategy. It’s no use developing a robust security solution for a device which becomes obsolete after a period of use. This is why Secured Elements can be updated continuously to counter new threats.
Few people, especially a PayPal or EU Commission vice president, discuss the crucial secure element lifecycle management aspect. It’s not convenient for them to say the secure element ‘gatekeeper’ is responsible for keeping it secure. Far more convenient for their arguments to omit this, portray gatekeeping as unnecessary and gatekeepers as evil. In the end however, Apple has to maintain secure element updates from the various licensed secure element providers (EMV,FeliCa Networks, MIFARE, and so on) if secure payments are going to work at all This is what people who say, ‘it’s my device, we should be able to use NFC how we want,’ do not understand.
People also forget that nothing is free, you get what you pay for. With Apple Pay as gatekeeper, users get simplicity, innovation and feature updates. Simplicity: users get NFC they can use out of the box without Android-like NFC complexity such as secure element positions and obscure express mode settings.
Innovation: Apple Pay has features like Global NFC. iPhone and Apple Watch are the only smart devices that come with FeliCa built in as standard to use in Hong Kong or Japan, while Android limits functionality by market region. It’s astounding that Android, not even Google Pixel Android, has matched this basic functionality yet. We’re seeing more innovation as Ultra Wide Band (UWB) extends Wallet functionality to include ‘Touchless’ car keys and eventually, UWB enhanced automatic card selection as you approach the reader; more helpful than you might think.
Japan is key to understanding what’s really going on in the Apple Pay monopoly debate. Japan was the first market with an established mobile payment platform in place, long before mobile EMV contactless payments took off in Europe. iPhone also has a much larger marketshare in Japan than it does in Europe. It’s a shame people pass up the opportunity to learn from the successes and failures here.
So what’s the EU Committee vision for ‘open NFC’? I think it’s a rehash of the secure element wars when carriers locked mobile payment services to SIM contracts. In 2013 Google incorporated SimplyTapp HCE (Host Card Emulation ‘secure element in the cloud’) technology as a NFC ‘workaround’ to ‘free’ NFC from the evil clutches of mobile carriers. Sound familiar? Android NFC has never been right since.
How little things change, swap ‘evil mobile carriers’ for ‘evil Apple’ and you have the same self serving ‘open’ vs ‘closed’ NFC chip nonsense that people are debating today. FeliCa Dude, the ultimate industry insider who has experienced it all, said it best: ‘It’s all eSE or nothing now.’
And yet we now have Île-de-France Mobilités (IDFM) turning back the clock, circumventing the eSE on NFC equipped Android devices and going all in with HCE for IDFM’s Smart Navigo service for Android. To me this says all you need to know what European priorities are regarding the ‘open NFC’ model: eliminate eSE gatekeepers by forcing the less secure network dependent HCE as a required option. Good luck with that. From a transit perspective, based on Mobile Suica user experiences, I don’t think HCE Smart Navigo will be a smooth ride.
The EU Committee ‘open NFC’ vision might look ideal…to Apple Pay competitors. Regular users however, will have to deal with the ugly reality of multiple NFC apps, multiple NFC secure element modes and clashing updates that cancel out NFC services. Apple Silicon eSE space is limited to 16 cards. If that sounds like a lot now, wait until you have credit cards, transit cards, home, car and office keys and ID installed along with ‘open’ NFC apps wanting their own eSE space too. Services will be squeezed out forcing the user to intervene. If the EU Committee thinks this environment fosters competition and innovation while growing mobile payment use, dream on.
Japanese tech journalist Junya Suzuki has covered NFC mobile payment developments in Europe, America and Japan for over 2 decades. He doesn’t think the EU is playing an even hand here, in his opinion Samsung and Huawei would never face the scrutiny that Apple now faces. In typical European cultural fashion, EU motives pay lip service to fair open markets while playing an underhanded game of chess to make Apple do what EU banking interests want Apple to do. In other words, a double standard.
What does Apple need to do? I’ve always said that Apple needs to make the Secure Element Pass application process as transparent as possible. Keeping the blackbox NDA process as it is now makes Apple Pay a target, increasingly difficult to defend the status quo. Secure Element access on the level of Core NFC is a long shot, the very definition of a secure element means there has to be a developer certification process similar to EMVCo, FeliCa Networks, MIFARE, Calypso Networks Association, etc., that protects the privacy and business interests of all parties. But it would be great if there is a middle way where Apple can securely open things up for iPhone as a digital wallet, and iPhone as a payment terminal. We’ll see if Apple has anything to say about the subject at WWDC22.
That was quick. When I made the above table for mobile wallet chokepoint, there was no indication we’d get EMV confirmation so quickly. Many were quick to applaud sanctions against Russia to stop the war with Ukraine, and while stopping war is always the right thing to do, hurting citizens is never the right thing to do. Turning off basic digital wallet services should give people pause. What is easily done in one place can be easily done anywhere.
It’s also not clear cut how it is being done. Is Apple turning off select Russian bank services in Wallet or turning off select payment applets in the Apple Pay secure element, or turning off Wallet for Russian Apple ID users? Most likely the first but there’s no way to be sure and there is no way that Apple or Google will ever tell us.
Long lines at Moscow Metro transit gates are not so clear cut either. Open loop isn’t standard on all transit gates, most them being Troika transit card only, and according to a Twitter follower, physical Troika card only, not Google Pay/Samsung Pay Troika which only rolled out recently. If so this suggests the (so far only one) picture of long lines could be due to Troika system issues instead of Apple Pay/Google Pay/Samsung Pay, hacking, or something else.
VISA and mastercard soon followed and cut their services in Russia. Many people in Japan noted how easily all this happened and expressed their distrust, saying they would think twice about using digital wallet services from Apple and Google. Many also noted the importance of Japan having it’s own FeliCa technology and FeliCa based e-Money payment network
The value of non-EMV native payment networks controlled and operated by native companies should be clear to everyone by this point. Always, always have a backup plan. One thing is certain, warfare that attacks basic public service infrastructure like transit and digital wallets, far and away from any front line, is the new ugly reality.
Jonathan Seybold said it best in his Computer History Museum interview video, many arguments can be easily demolished by pulling out the hidden assumptions. In our attention span challenged social media era it’s all too easy to believe things at face value. Few people invest time and brain energy to analyze and question arguments to find and examine hidden assumptions.
A reader of this blog might come away thinking I am not a fan of open loop transit fare payments and despise EMV contactless and QR Code payment technology. That would be a mistake. I don’t hate them, everything has its place. I simply don’t agree with ubiquitous assumptions that EMV or QR or open loop are cure alls for every transit fare payment situation that they are praised to be…usually because ‘everybody uses’ bank issued contactless payment cards or smartphone payment QR apps. It’s a one size fits all mentality that blinds people from seeing hidden assumptions. It’s very important to see how all the pieces, seen and unseen, fit together. After all, transit companies and their users have to live with transit infrastructure choices for decades.
In a recent twitter thread Reece Martin thought it would be nice if Canada had a nationwide transit card. This is something Japan has had since 2013 when the Transit IC interoperability scheme was put in place that made the major transit IC cards compatible with each other, but they did this without changing the hardware. The various card architectures were left untouched and linked with system updates, a use-the-same-card backend solution. China on the other hand created a national transit card with the China T-Union • PBOC 2.0 standard that replaced all older transit cards with locally branded T-Union cards, a get-a-new-card hardware solution.
A nationwide Canadian transit card is a great idea but as Samual Muransky answered in the same thread, why bother with ‘obsolete’ dedicated transit cards when everybody uses EMV contactless bank cards and EMV is the new standard. Let’s examine some hidden assumptions at play here.
Assumption #1: Everybody has contactless credit/debit cards The open assumption here that everybody has bank issued credit or debit payment cards is not the case and varies by country, demographics, age, etc. Most people in some countries do, but even so there will always be people who don’t. Transit cards always have the advantage of being available at station kiosks to anyone with cash.
Assumption #2: because of assumption #1 open loop (credit/debit cards) is better than closed loop (dedicated ticketing) for paying transit fare The hidden assumption is that open loop covers everything but it does not. Specific transit services such as individual commuter passes, discounted fares for disabled/elderly/children are practically impossible to attach and use with bank payment cards. The best that transit systems and payment networks can do with open loop is fare capping or special discounts when applied universally. The age-old pay ‘x’ times and get one free concept. Open loop works best for occasional transit users.
Assumption #3: EMV contactless is the NFC standard The NFC Forum recognized long ago that credit card companies and transit companies have different needs and objectives. To that end the NCF Forum has 2 basic NFC standards, one for contactless payments (NFC A/B but only A is really used) and one for transit (NFC A-B-F). All NFC devices must support NFC A-B-F for NFC Forum certification.
Assumption #4: EMV contactless for transit is safe and secure There are many hidden assumptions packed into the words ‘safe and secure’: not everybody agrees on what safe is and what level of security is secure. Things also change depending on the situation and the design. I have covered transit gate reader design in many other posts but recap some basics here.
Steve Jobs famously said that designing a product is a package of choices. I have often said that EMV contactless is supermarket checkout payment technology but that’s not a put down, it’s the truth of what EMVCo were aiming for when they grafted NFC-A to their EMV chip for contactless cards.
Because of wide deployment with no direct control, the original EMV contactless spec had a latency window to work reliably even with crappy network installations, and the slow speed has sometimes been cited as a security risk. NFC-A (MIFARE and EMV) transaction speeds are rated for a theoretical 250ms but are usually 500ms on open loop transit gates. Suica is always 200ms, often faster. The speed gap is due to gate reader design, the network lag of centralized processing vs local stored value processing, and the different RF communication distances for NFC-A and NFC-F. JR East presentation slides explain the transaction speed differences.
Japanese station gates are designed to be capable of 60 passengers per minute. To do this the conditions are:
Processing time of fare transaction has to be within 200ms
RF communication distance is 85mm for physical cards and smartphones
European station gates are designed to be capable of 30 passengers per minute:
The processing time takes 500ms
RF communication distance is 20mm for physical cards, 40mm for smartphones
The Suica transaction starts from the 85mm mark while MIFARE and EMV contactless cards start at the 20mm mark. Because of the greater RF communication distance Suica transactions start much earlier as the card travels toward the reader tap area. It you look closely at the 2nd slide you can see that smartphones have a slightly earlier EMV/MIFARE RF transaction starting at the 40mm mark (the 1.1A/m boundary) due to the larger smartphone antenna, physical EMV cards with smaller antennas are limited to 20mm. This is why smartphones seem faster than physical cards on NFC-A gates. Suica physical cards have a larger antenna and the same RF transaction distance as smartphones.
NFC-A transaction speed is slower because it has to be on top of the reader before it can start. This is also the limitation with optical based QR and bar codes, the transaction only starts when the smartphone screen is close enough to the reader for an error free scan. Transit gates using these technologies are not designed for smooth walk through flow.
One of the smart things Nankai is doing in the test phase (limited to a few key stations) is keeping EMV/QR gates separate from standard FeliCa gates. This is practical. Regular users go through the faster regular gates, the occasional open loop or QR users go through slower EMV/QR gates. Keeping different readers separate and clearly marked helps keep walk flow smooth and crowding down at busier stations. The Nankai program has been put on pause for another year due to the collapse of inbound travelers in the COVID pandemic. It’s a trial run as Osaka area transit gear up for an anticipated inbound travel boom in connection with Expo 2025, that may, or may not pan out.
The Nankai VISA Touch gates are designed for physical cards, Apple Pay works but without Express Transit. That’s a plus as Apple Pay EMV Express Transit on TfL and other open loop systems (OMNY) has come under scrutiny for a potential security risk with VISA cards that allows ‘scammers’ (in lab settings) to make non-transit charges to Apple Pay VISA cards via Express Mode, something that is not supposed to be possible.
Timur Yunusov, a senior security expert at Positive Technologies…said a lack of offline data authentication allows this exploit, even though there are EMVCo specifications covering these transactions.
“The only problem is that now big companies like MasterCard, Visa and AMEX don’t need to follow these standards when we talk about NFC payments – these companies diverged in the early 2010s, and everyone is now doing what they want here,” he said.
In other words, Apple removing Apple Pay bio-authentication to promote EMV Express Mode for open loop transit puts Apple Pay at the mercy of lax card network payment operation practices who don’t follow their own rules. Not that it’s a real problem in the field but accidents do happen, such as this incident on Vancouver BC TransLink that a reader forwarded:
Just a moment ago, I nearly got dinged on my CC while sitting on a high seat near a door which is where one of the validators are located. The validator picked it up from the backside rather than the front side where the tap area is located. Also, somehow, my iPhone authorized the transaction when I only want to return to the home screen instead.
If the open-loop was implemented in a way where the card must be pre authorized before the card can be tapped at a validator, it wouldn’t get me in a situation where I need to deal with customer service to dispute some charges. Good thing this time, transaction was declined so nothing related to this charge showed up in my account.
And then there is data privacy, a far larger and long term problem is how open loop transit user data is stored and used. Apple always says they don’t know what Apple Pay users are doing as the data stays private. Fair enough, but the same doesn’t apply to the bank card companies. Open loop payment platforms in Japan, like stera transit, love to promote the customer data reporting services they provide to transit companies.
Plastic transit IC cards are basically private, they have a card number but nothing else. Credit/debit cards have your entire profile coming along with your open loop use and stera report a subset of this in their reports. And where is this data stored? In Japan, in Korea, somewhere else, wherever stera has a data sub-contractor? Payment transaction companies have been burned, repeatedly, when caught storing Japanese card transaction data outside of Japan…but they keep doing it again when everybody’s back is turned. This problem isn’t going away because of flimsy laws, lax industry practices and last but not least: personal data is a valuable commodity.
There is also the aspect of the price of cost effectiveness. When data processing stays in the country of origin, that means local employment and tax revenue feeds the national economy. When data processing goes outside the country, those are lost. This kind of discussion never takes place when it comes to transaction data processing, which it should, especially when publicly funded transit operators are involved.
Open loop is only part of a larger picture Canadian transit would certainly benefit from a Japanese transit IC system approach with compatibility on the backend, or even the China T-Union approach of a national card spec that is locally branded but works everywhere.
To come back to the beginning, my point isn’t about slamming EMV or QR open loop transit, just the assumptions that they solve everything. They have their place in intelligently designed fare systems but only constitute part of the larger transit fare system picture. And as I have pointed out many times, card companies have little interest in improving the EMV standard for transit needs. They want to capture transit fare business without investing. The focus will always be the supermarket checkout lane that EMV was designed for.
There will always be a risk involved when ignoring the hidden assumptions of EMV open loop as a one size fits all solution. Dedicated transit cards will always be necessary. Every transit system is unique and deserves the best solution for the transit company and the riders they serve.
After a long gestation, and a COVID related delay, the mighty swipe MetroCard replacement finally shipped. The OMNY card: a white-label EMV bank payment card using the mastercard payment network, not a MIFARE or FeliCa smartcard like San Fransisco Clipper or Tokyo Suica. MetroCard missed the transit smartcard revolution of the late 1990’s, so MTA and their ticketing system management company Cubic Transportation Systems went all in with a new CUBIC designed system built using EMV payment network processing i.e. ‘open loop payment‘ regular EMV contactless credit/debit cards for mainstream transit fare use, and dedicated white-label EMV prepaid debit transit cards that replace MetroCard, relegated to a backup role for users who cannot use regular credit/debit cards for transit.
OMNY is envisioned and designed as a ‘one size fits all’ approach where bank card EMV payment networks (VISA, mastercard, American Express, etc.) are promoted as transit tickets since everybody supposedly already use bank cards for all daily life purchases. The addition of fare capping, basically a OMNY closed loop card feature for open loop, further encourages regular credit/debit card use and reduces the need for issuing OMNY card. And rest assured, MTA very much wants to get out of the card issuing business…good luck with that.
Arguably it’s a good thing that the Ventra prepaid debit card is going the way of the dinosaur. The debit card function debuted with a long list of fees that had the potential to siphon of much of the money stored on the card, including:
A $1.50 ATM withdrawal fee A $2 fee to speak to someone about the retail debit account. A $6.00 fee for closing out the debit balance A $2 fee for a paper statement A $2.95 fee to add money to the debit account using a personal credit card A $10 per hour fee for “account research’’ to resolve account discrepancies
“These fees were probably not any different than other bank cards offered by Money Network or Meta Bank or other predatory banks,” says Streetsblog Chicago’s Steven Vance, who reported on the issue at the time. “But it was shameful for the CTA to be aligned with that.”
After a backlash, most of these fees were reduced or eliminated, but CTA retail outlets were still allowed to charge Ventra card holders a fee of up to $4.95 to load cash on the debit sides of their cards. So maybe it is for the best that the CTA is getting out of the bank card business.
Let’s hope the OMNY card issuer and MTA do a better job of hiding their white-label OMNY prepaid debit card fees. Because let’s face it, even though OMNY card is ‘closed loop’ it still uses the same EMV payment network that open loop cards do. I call it faux closed loop because OMNY doesn’t process their own fare payments, nor does OMNY (as of this writing) offer commuter passes, student discounts, etc. OMNY station kiosks that have yet to be installed will likely be modified ATM machines that take money instead of dispensing it.
A digital version of OMNY was advertised to launch on Apple Pay and Google Pay ‘soon’, although MTA now says it ‘expects’ to launch OMNY iOS and Android apps necessary for adding OMNY to Wallet sometime in 2023. We shall see. When the OMNY digital card does finally launch, expect the same rebranded version of mastercard closed loop Ventra and Opal digital cards, all managed by Cubic. As most of the open loop systems in North America, UK and Australia are designed and managed by Cubic it’s helpful to compare their ticketing system profiles.
Transition bumps in road When you carefully analyze the different systems and Express Mode transit support listed on the Where you can ride transit using Apple Pay support page, one condition becomes clear: current transit systems do not support Apple Pay Transit cards and EMV Express Transit when the system uses both MIFARE and EMV open loop. It seems to be a choice between supporting one or the other, not both. I suspect transit system operators do this because of the complexity supporting MIFARE and EMV mixed mode operations on the same transit system.
OMNY is a new system however, built exclusively on EMV. When Apple Pay OMNY launches, OMNY will be the first system to support both EMV as an Apple Pay transit card and EMV Express Transit mode for credit/debit cards. There is a catch however similar to using Apple Pay China T-Union cards: turning on one card for Express Transit turns off other cards.
This happens when cards share the same NFC ID number which results in card clash at the gate reader. When cards share the same ID, only one card can be set for Express Transit mode at any one time. For EMV cards this applies to payment cards as well so Express Transit Card settings will likely turn off any activated payment cards when an OMNY card to turned on, and vice versa. Otherwise the complaints from Apple Pay MTA users would be endless.
The last big OMNY headache: MTA Railroad ticketing After OMNY card is launched on Apple Pay and Google Pay, the next OMNY challenge will be integrating Metro-North and LIRR commuter rail ticketing. A difficult task as none of the train line are equipped with NFC card readers. MTA has yet to unveil any commuter rail ticketing integration details. Ventra has the same problem, commuter rail ticketing remains the age old conductor visual inspection, no tap and go contactless. And as ever there are thorny open loop user data privacy issues.
OMNY truly represents the state of American public transit as it tries to get on board with mobile payments. Progress is good and welcome but instead of real meaningful development, American public transit will continue to be a confused mess of endless broken promises. This can’t change as long as America treats public transit as a subsidized welfare and jobs program instead of essential public infrastructure.