We’ve all known about the ease of digital payments and the speed and efficiencies enjoyed over digging in one’s wallet or pockets for cash. It is the digging that causes lines to back up at a register or kiosk and grumbling to ensue. But crossing the Rubicon from paper tickets to digital ones is no easy feat when you’re dealing with mass transport and millions of riders as they use contact payments cards as they travel.
In a recent interview between PYMNTS’ Karen Webster and Will Judge, VP of Enterprise Partnerships/head of Urban Mobility at Mastercard, the dialogue focused on the front-end convenience for commuters and the back-end mechanics for Mastercard and other stakeholders, using London’s transportation system as a jumping-off point.
On its face, the tap-and-pay process is a simple one, said Judge.
“You arrive, you see the [contactless] logo you recognize — in the same way you would see the logo at a retailer or a point of sale — and you tap it and you get access to … the journey, and you tap out again,” he said.
The attraction of this process, he said, is “that it is understandable wherever you go in the world.” Judge also noted that ease of use comes as users do not need to pre-load, register or download any additional functionality to their devices. “Frankly, you have better things to do if you are visiting cities [and traveling].”
But behind the scenes — in the payments background, so to speak — between the acquirer and the transport merchant and the issuer, he said, some complexities arise with the event of the consumers “tapping and getting out” as they journey from station to station.
Among the multiple elements that matter to transportation-focused transactions, said Judge: speed, price (or, in this case, fare) and risk.
“The first thing that is essential in a transit situation,” maintained Judge, “is the time taken at the gate,” which is known as passenger throughput. And throughput is critical at any manner of events, say, at a concert venue or an outdoor sports stadium.
As Judge explained, Mastercard had determined that there was enough time, in lanes where there were 30 or fewer people (but always the potential looms for overcrowding), that there would be enough time for authentication via cryptogram but no real time to perform online authorization.
“And so,” said Judge, “we said, let’s make it a starting point that we will authenticate cards and prove they are not counterfeit, using the terminals, but the whole business of authorization and risk management has to be some other way.”
The company then had to grapple with what information would be needed to generate a cryptogram. One key piece of data, he told PYMNTS, boils down to price, but even that has its complicating factors. In a fixed fare environment (such as in New York City), that hard coding, as an input, is relatively easier than would be seen where, as in London, different destinations have different fares and transfers between busses and trains may be involved.
“The fare might not be known just on [passenger] entry,” said Judge, who explained that “you have to figure out when did this person start and where the person starts, and where did this person leave, and when.”
Thus, there remains a need for information processed by the transporting firm. Mastercard hardcoded the terminals to read “zero pounds” while sidestepping any triggers that might be set by an issuer — something “we absolutely wanted to eliminate from the context of busy metro [stations],” he said.
The Transport for London (TFL; the government’s transportation body) would, through its own back office, reconcile data tied to each journey and provide authorization (the system is agnostic as to whether devices are NFC-enabled or not, and, most recently, Android Pay became available across London’s contactless payments options).
A nominal charge (usually a pound) from the issuer is in place until the journey is completed, “with a view to the fact that the authorization is going to be, almost certainly, greater than a pound,” said Judge.
If the authorization is approved, TFL will track the journey (and the charges that accrue). If the authorization is declined, then “the issuer expects TFL to do something that pretty much no other merchant can do,” said Judge, “and that is to add the charge to the deny list that comes across all the stations and platforms.”
“A deny list is not present in the world [of] retail,” he explained, but transit companies must have central databases that maintain information on cards that are to be denied entry. “So the risk for a ride being made for which the card issuer refuses to authorize payment is limited to about the duration of one, or at most two, rides.”
Increased ridership, overall, he added, more than offsets any lost revenues stemming from authorization denials.
Noting the steady gestation of Mastercard’s process — from planning to initial deployments beginning about five years ago to adoption by dozens of cities worldwide — the VP stated that in April of this year, Mastercard logged “the first day in the whole program when more than two million pay-as-you-go journeys were made on the system in London.”
As the discussion between Judge and Webster turned to broader topics, Judge noted some “top of mind” issues for transit operators.
“They are all working very hard to keep up with the pace of digital innovation in the wider economy. [Rider] expectations are being drive by entities like Amazon and individual merchants and issuers.”
Within transit itself, “you have the large transport providers trying to mobilize their data, either in-house or partnering with startups,” said Judge, and “the digital giants are progressively” bringing in information tied to API and mapping programs “to intermediate between the consumers and the transport providers.”
People want multifunctional, geographically broad journey-planning tools at their disposal, he said.
The question is a broad one to be answered: “How do we integrate the best of payments and the best of journeys and bookings and reservations into this world of maps and journey planning?”