SRC enters the secure digital commerce arena

Secure Remote Commerce (SRC) officially launched in the US last week,
supported by a limited set of merchants, with more to launch by year-end and into early 2020. We’ve been tracking SRC for some time now as it moved through the specification development process within EMVCo. It has emerged at launch as a customer-facing brand called “Click-to-Pay,” unless you’re using an Amex card, where it’s also called “Online Checkout” in confirmation emails received after registering a card.

So now we know SRC has launched as Click-to-Pay, but what is it? As the card brands have positioned it, Click-to-Pay is intended to solve the challenges that come with guest checkout (i.e. the first time a customer shops with a merchant, or when a customer prefers not to let the merchant store their payment details). SRC itself is a specification that acts behind the scenes to provide a secure and interoperable card acceptance environment
and covers both web-based and native app-based transactions. EMVCo has suggested that by having a simpler integration for merchants to access a consolidated brand wallet through a single buy button, it can enable a smoother process for consumers to access their payment cards and shipping details without having to manually fill out payment details for these types of transactions. This is not the first attempt by the brands to solve this problem (e.g. Visa Checkout, Masterpass, and Amex Express Checkout), but previous attempts struggled with adoption by both consumers and merchants. This new iteration under SRC has all the brands working together under EMVCo to coordinate efforts, so if implemented correctly, and if it does simplify the process for merchants and consumers, the momentum of this joint effort might help enable broad adoption.

Naturally, as all intrepid payment consultants are inclined to do, we went out and tested SRC with the launch merchants to see how it’s working and what we could learn for our clients. We bought some chocolate, movie tickets and also donated to the Movember charity. Based on these payments we found a few peculiarities to note so far:

• The checkout experience across the three launch merchants varies quite a bit, which can be expected for different types of goods or services (i.e. donations vs. goods that need to ship). However, even the experience after returning to the merchant checkout from the SRC checkout varied. Sometimes there was a “Payment Review” screen before confirming payment, and others the payment was submitted immediately after clicking a button to “Confirm” payment on the SRC screens.
• The flows for desktop web and mobile web varied slightly as well when returning to the merchant checkout. Interestingly, there were more steps to complete on a mobile browser after returning from the SRC checkout.
• On subsequent payment attempts after initial registration, more cards appeared without needing to register each one. It’s not entirely clear how these were loaded or where they came from, though we believe it could be due to past use of Visa Checkout, or registration of cards within Apple Pay using the same email address. Even though these cards appeared, they still needed to be authenticated (with a card security code or a one-time passcode) before use.
• While a registered SRC profile contains the customer’s shipping address, the merchant checkout flow forced manual entry of shipping information since payment method selection comes after entering shipping details. As solutions mature, this flow may shift to bring Click-to-Pay earlier in the flow.
• There is a trusted device process, but it doesn’t appear to be recognized by subsequent attempts as even after using Click-to-Pay as a “Returning User”, we were forced to enter a one-time passcode sent via email.

Some of these variations can be expected in early iterations of SRC, and some of them are by design. Jess Turner, executive vice president of digital payments and labs of North America at Mastercard told PYMNTS.com,
“…the way a merchant deploys SRC will depend on their chosen verticals, consumer bases, and how large or small the merchant may be.” This flexibility, in the long run, should actually provide merchants with more choice about how they implement SRC, and which features are most important to them. At this time, the only thing that SRC seems to save for a customer is entering their card details. As adoption expands, we expect to see the checkout experience optimized and simplified for everyone involved.

Speaking of merchants, what’s in it for them? If a consumer is going to enroll any payment cards into a wallet, historically, merchants have preferred this be in a merchant wallet under their control, rather than a scheme wallet. However with SRC there is no merchant card on file “honey pot” to be breached, so for many merchants this is an appealing security feature that reduces their risk of becoming the next credit card data breach in the news like Home Depot, Target, TJX, Marriott, British Airways, Macy’s, Lord & Taylor or Saks Fifth Avenue. For consumers who do not regularly shop with certain merchants, SRC could help reduce the checkout friction while also simultaneously securing the cardholder’s payment details.

There are a variety of ongoing developments attempting to make the experience of guest checkout more convenient and more secure for both consumers and merchants. These include different approaches like storing payment details in your device’s browser (W3C Payments Request API in Safari, Chrome, Firefox, etc.) or leveraging digital wallets like Apple Pay, Google Pay or Samsung Pay for in-app payments. While the technologies available today are still early to the market and need time to mature, they each are striving to enable universal acceptance, increased security, and a common checkout experience, but do we need all these solutions? Are we going to just confuse consumers? Which solutions will gain traction and survive? Which solution works best for different merchant types? The answer to these questions may well depend on the consumer experience a merchant wants to provide on their website.

At Consult Hyperion, we are continually working with our clients to make payments simple and secure. Based on what we can see so far, SRC should make paying online more secure for everyone while reducing integration and enrollment roadblocks for the merchant and consumer respectively, however the current implemenatations are somewhat clunky and need to be more streamlined to succeed. The real test will be the adoption rate and the brands’ responsiveness to feedback from participants in the ecosystem to ensure a beneficial approach for everyone involved. If you’d like to learn more please contact us for a copy of our latest digital commerce material at sales@chyp.com.

4 Essential Trends in Money for your Business

By Sanjib Kalita, Editor-in-Chief, Money20/20

This article was originally published on Money20/20.

We are in the midst of seismic societal changes of how people interact and transact.  Across societies, geographies and segments, digital is the new norm. Change has accelerated, placing greater value upon flexibility and speed. Historically, money and finance have been among the more conservative and slower changing parts of society, but this has changed dramatically over the past decade by viewing money as an instigator of change rather than a lagging indicator.

Whether you are a marketer in shining armor conquering new territory, a financial wizard casting spells upon the balance sheet, or the queen or king guiding the whole enterprise, here are 4 trends about money that you should keep in mind for your business.

Platforms are the new kingdoms

Platforms are the base upon which other structures can be built.  For example, App stores from Apple and Google provide the infrastructure for consumers to complete commercial transactions and manage finances through their mobile phones.  While these companies develop their own digital wallets, they also enable similar services from banks, retailers and other companies.  Building and maintaining the platform enables services that they would not have created on their own, like Uber or Lyft, which in turn, have created their own platforms.

Marketers trying to address customers’ needs can plug into platforms to broaden offerings or deepen engagement with target markets. Platform-based thinking implies that product and service design is ongoing and doesn’t stop with a product launch.  Jack Dorsey didn’t stop when he built the Square credit card reader.  The team went into lending with Square Capital.  They got into consumer P2P payments with Square Cash.  Their ecosystem has grown through partnerships with other companies as well as in-house development.

Digital Identities open the gates

How do your customers interact with you?  Do they need to create a username and password, or can they use a 3rd party system like Google or Facebook?  Are security services like two-factor authentication or biometrics used to protect credentials?  Is your company protecting customer identities adequately?  The importance of all of these questions is increasing and often the difference between being forced into early retirement by a massive data breach or surviving to continue to grow your business.

While identity management and digital security might not be top of mind for most marketers, they are table stakes for even the most basic future business.  History is full of tales of rulers successfully fighting off armies laying sieges on castles and fortresses, only to fail when another army gets access to a key for the back door.

Context rules the experience

Credit card transactions moved from predominantly being in-store, to e-commerce sites accessed from desktop computers, and now to mobile phones.  As the point-of-purchase expanded, so did the consumer use cases and thought processes. In tandem, mobile screens presents less information than desktop computer screens, which in turn presents less information than associates in a brick-and-mortar environment.  Companies best able to understand context and deliver the right user experience within these constraints will build loyal customer relationships.

Apps or services created for a different use cases on the same platform, such as Facebook and Messenger apps, can help achieve this. Banks and have different apps for managing accounts or for completing transactions or payments. On a desktop, you can access these services through a single interface but on the mobile, forcing users to select their use case helps present a streamlined experience on the smaller, more time-constrained mobile screen.  The use of additional data such as location, device, etc. can further streamline the experience. Marketers that don’t think about the context will lose the battle before it even begins.

Data is gold

While a marketer’s goal is to generate sales, data has become a value driver.  In the financial world, data about payments, assets and liabilities has become critical in how products and services are delivered.  PayPal, a fintech that began even before the word ‘fintech’, has recently been using payments data from their platform to help build a lending business for their customers.  Similarly, an SME lender named Kabbage has grown to unicorn status by using data from other sources to make smarter lending and pricing decisions.  In the payments industry, Stripe distilled a previously complex technology integration into a minimal data set, accessed via API, to easily build payments into new digital products and services.

Those that are able to harness the power of data will be able to predict what customers want and more effectively address their needs.  In some cases, it might be using data from within your enterprise or from other platforms for targeting, pricing or servicing decisions. In other cases, it might be using data to reimagine what your product or service is.

Looking for more insights on key trends in money? Hear from 400+ industry leaders at Money20/20 USA. Money20/20 USA will be held on October 27-30, 2019 at The Venetian Las Vegas. To learn more and attend visit us.money2020.com.

This article was originally published on www.money2020.com.

Digital Wallet Ticketing

I’ve just been in Bristol at the annual Transport Card Forum (TCF) two-day event. I was on the agenda as chair of Working Group 27 giving the final report on progress. The report will be going to DfT shortly and thereafter available to TCF members via the website. I’ve been attending TCF for many years and it is impossible not to notice how very slowly things change in transport ticketing.

One piece of our recent advice to a sub-national transport body, when hired to outline their smart ticketing strategy can be summarised as: do not seek government funding to implement a region-wide (expensive) smart ticketing solution, but rather look at what already exists and how these ticketing schemes might be brought together to meet the needs of the various travelling customer types in the region. In this context, I was pleased to hear mention of software development kit (SDK) offerings from Masabi and FAIRTIQ giving me hope that the transport ticketing industry is moving in the right direction. For example, Masabi using their SDK to insert their ticketing technology into the Uber app for trials in Denver, Colorado.

A recurring theme at the event was operators reporting how PAYG solutions are proving popular with customers and how they are eroding the other forms of ticketing such as season tickets. This is an increasing area of concern for clients we are working with, most notably in terms of cash flow and forecasting but also technically. Some of our current work is helping clients deal with the array of ticketing solutions they are operating and how to rationalise these in the light of the way that the automated fare collection (AFC) industry is moving and responding to customer needs. Consumer demands will continue to drive change in their purchase patterns as flexible and remote working opportunities increase.  

It is not uncommon for a transport operator to support all of the following:

  • Paper tickets as the only medium interoperable at all acceptance points for all customer types.
  • Legacy smart card solutions based on 1990s technologies where the operators were focussed on owning the customer by issuing them with a smart card.
  • Barcodes as a cheaper alternative to smart cards that can also go paperless if delivered to mobile phones.
  • Mobile ticketing solutions based on bar code or flash pass, sometimes with low security levels and high fraud levels. Some using the ‘software only’ HCE innovations which Apple will not currently allow.
  • Open-loop (EMV bank card) PAYG solutions which have grown out of our work with TfL in 2008-14. These are intended to increase ridership and reduce costs by using the bank card in the customer’s pocket, but because they are one card per passenger, they do not cater for group tickets or for those not having (e.g. children) or not wishing to use bank cards. This could be addressed on buses by introducing a ‘retail model’, but this would require driver interaction to determine the price of the ticket before purchase and slow down bus boarding.

Operators are transport providers and their core business is providing transport services, not running ticketing solutions. The last thing they want is to be maintaining systems that have to be able to handle multiple different front ends, though many of them find themselves doing so. The classic example is TfL’s intention to switch off Oyster when open-loop was up and running, but they not yet managed to achieve this.

Our recent work with clients about how to use Digital Wallet Ticketing in a customer’s smart phone to unify their disparate ticketing solutions is proving popular.  This has been both in sports stadiums and transport ticketing. Digital Wallet Ticketing was not much discussed at TCF19, which I guess is a sign of how slowly things move within the transit ticketing community. We believe DWT is the future.

We have a wealth of experience over several years of designing and building DWT solutions. Let us know if you’d like a chat about how this might work for you, be it payment, identity or ticketing.

GDPR: Consequences, Fines and Responses

The UK’s Information Commissioner’s Office (ICO) has finally done what it’s been threatening to for a while and levied enormous fines on British Airways’ parent International Consolidated Airlines (£183 million) and Marriott Hotels (£99 million).  While subject to appeal, these are the first signs of how the ICO now has real teeth and is prepared to use them. The question is, what lessons can we learn from this?

Well, firstly, we can observe that card payments aren’t optimised for the internet.  The BA breach looks like it was at entry point – i.e. it wasn’t that the data was breached while stored in a database but that someone managed to get hacked software to intercept payments in flight and capture the details. The point here, of course, is that the paradigm of giving your card details to the merchant so they can pass them to your issuer originated in the 20th century when we didn’t have a choice. Now, given that we have this internet thing it makes more sense to contact our issuer directly and tell them to pay the merchant. Realistically, this may be the only way we can be sure merchants won’t lose our card details – don’t give them to them.

This points to push payments a la PSD2 APIs. But given that these won’t be pervasive for a while then the next best option is to tokenise cards to either limit their use to a single merchant or even a single transaction. Both of these are areas we’re seeing lots of interest in, and ought to be high on the agenda of heads of IT security and payments everywhere.

Secondly, we can note that static credentials are a sitting target. Seeing email addresses and passwords breached opens up companies to all sorts of horrible consequential damages under GDPR – let’s face it, most people reuse the same combinations across multiple sites so a breach on one site can lead to exposure on another. Any company relying on static credentials should basically assume they’re going to get some level of breach.  

Fixing this requires two factor authentication and we have a ready-made, state-of-the-art, solution here in the EU. PSD2 SCA is about as strong an approach as you could ask for and we have banks and authentication providers drowning in relevant technology. There simply is no excuse for a company using static credentials if they get breached.  We’ve been working closely with providers to look at how to take these solutions into the wider authentication market, because there’s been a certain inevitability about the way a lot of companies have dealt with their data breach protection.

Finally, note that the point that BA have made – that they haven’t seen any impact due to their breach – needs to be quantified: “yet”. Hackers tend to sit on breach data for 18 months before using it, waiting for the identity protection schemes that are often engaged post these events to expire. GDPR allows affected companies and individuals to sue – up until now the costs of a data breach have been borne by banks having to deal with fraud and issue new cards and consumers having to sort out identity protection. The ICO fines may yet be just the be tip of a very expensive iceberg as GDPR ensures that the costs more appropriately allocated to the offending parties.

SCA: the end of merchant liability, and other authentication factors

The EBA’s recent Opinion on the elements of strong customer authentication under PSD2 was, apart from moving the goalposts on when SCA will be enforced, full of interesting information about what constitutes a valid SCA element. It closes some doors, opens others and ends any notion that merchants can take liability and not do SCA themselves.

Taking the final point first, there’s been a view that Article 74(2) of PSD2 permits merchants to carry on without implementing SCA as long as they take liability. We at Consult Hyperion have long argued that that is an optimistic and overly legalistic reading of the regulations and this has now been confirmed. The EBA states:


In addition, even if there were a liability shift to the payee or the payee’s PSP for failing to accept SCA, as articulated in Article74(2) of PSD2, this could not be considered an alleviation of PSPs’ obligation to apply SCA in accordance with and as specified in Article 97 of PSD2.

Basically, Article 97 takes precedence – PSPs (aka Issuers) must apply SCA so if the merchant chooses not to then rather than end up with a payment for which they’re liable they’ll end up with no payment at all. Which, you’d imagine, would rather miss the point of being a merchant.

Beyond this point the Opinion has lots of interest to say about inherence, possession and knowledge elements.

On inherence two points stand out. Firstly the Opinion unambiguously states that behavioural biometrics can be a valid factor: this opens up a world of possible low friction SCA, and we expect to see lots of innovation in this area. Secondly it states that 3DS-2 does not support inherence as none of the data points being gathered relate to biological or behavioural biometrics but – and we view this as important – 3DS-2 is a valid means of supporting SCA.

This is critical because the dynamic linking process behind 3DS-2 is not straightforward and there have been differences of opinion over whether this is compliant. Given that 3DS-2 appears to be the only game in town for CNP transactions having a statement that it’s OK is mighty important.

On possession, the EBA clarifies that OTP SMS is valid and also that mobile app based approaches can be – but only if the app is linked to the device. We’ve been arguing that this is obviously the case for a while, so it’s good to see this confirmed: although there are going to be a few app developers out there that need to revise their approaches pdq (we can help, of course!).

Also on possession the EBA has stated something that really should have been obvious to anyone taking more than a moderate interest in the topic – printed card details such as PAN and CVV or user ids and email addresses are not valid possession or knowledge elements. As a number of prominent industry players have been taking the opposite approach this could lead to some interesting developments in the coming weeks, particularly as the Opinion states that if the CVV is not printed on the card and is instead sent on a separate channel, then it is a valid knowledge element.

Overall, the analysis and discussion in the Opinion on valid SCA elements is welcome, if a trifle tardy. To be fair to the EBA, we don’t see anything in their analysis that a proper reading of the RTS wouldn’t have produced. However, it’s been clear for some time that many industry players have been making a highly liberal interpretation of the requirements usually based on a legal opinion. But PSD2 and the RTS are about principles, not rules: if you need advice on this you need to talk to the people who understand this stuff. Which, by the way, is us, not law firms.

The EBA blinks first …

EDIT: since posting this blog the UK’s FCA has confirmed our expectation that it won’t be enforcing SCA on the 14th September as long as the participants are aiming to comply with a soon to be announced migration plan. In the meantime it’s “working with the industry to develop a plan to migrate the industry to implement SCA for card payments in e-commerce as soon as possible”.  See: https://www.fca.org.uk/news/statements/fca-response-european-banking-authority%E2%80%99s-opinion-strong-customer-authentication

The doom-laden headlines appearing in the press have, it seems, worked and the EBA has decided to replace the 14th September deadline for the introduction of SCA with … another deadline. Only they won’t tell us what it is, presumably we have to figure it out for ourselves.  

So, let’s see what the EBA has done now …

Firstly, they haven’t actually changed the date as they can’t, it’s written into EU law. But given dire warnings of a collapse in online payments they’ve come up with a fudge:

The EBA therefore accepts that, on an exceptional basis and in order to avoid unintended negative consequences for some payment service users after 14 September 2019, CAs may decide to work with PSPs and relevant stakeholders, including consumers and merchants, to provide limited additional time to allow issuers to migrate to authentication approaches that are compliant with SCA, such as those described in this Opinion, and acquirers to migrate their merchants to solutions that support SCA.

https://eba.europa.eu/documents/

Let’s summarise that. National regulators – competent authorities (CAs) – may work with PSPs (Issuing and Acquiring banks) and unregulated actors (merchants, consumers) to agree to delay the introduction of SCA. Which presumably means unprepared merchants and confused consumers are breathing a sigh of relief. Unfortunately, as this is now in the hands of local regulators there’s no guarantee at all that this will be applied evenly, opening up the possibility that some countries will enforce and others (notably the UK and France) will not.

On top of that, there’s no guarantee that Issuers won’t apply SCA anyway, even if their local regulator permits them to not do so. So merchants who are unprepared may still find themselves suffering random declines. And, furthermore, if Acquirers haven’t implemented the necessary changes then even if the merchants are compliant they may still have transactions irrevocably declined.

Note also the “limited additional time” clause. Frankly, introducing SCA prior to the critical holiday shopping period was foolish anyway (but was an unintended consequence of the 18 month implementation period following the adoption of the RTS), so we can assume that the date will be pushed out at least into early or mid 2020. The EBA adds (but not in the actual Opinion):

In order to fulfil the objectives of PSD2 and the EBA of achieving consistency across the EU, the EBA will later this year communicate deadlines by which the aforementioned actors will have to have completed their migration plans.

And that’s the catch:

This supervisory flexibility is available under the condition that PSPs have set up a migration plan, have agreed the plan with their CA, and execute the plan in an expedited manner. CAs should monitor the execution of these plans to ensure swift compliance with the PSD2 and the EBA’s technical standards and to achieve consistency of authentication approaches across the EU.

Basically, Issuers and Acquirers need to publish what they’re going to do including how they’re going to communicate the requirements to consumers and merchants respectively. Quite how this is all going to be co-ordinated is unclear – no sensible merchant is going to disadvantage themselves by unilaterally turning on SCA when its competitors aren’t. Issuers may take the same approach, as they probably don’t want their cardholders switching to other banks: but there’s no requirement on them to do so.

The rest of the opinion focuses on the validity of various authentication factors. That’s interesting too, but we’ll look at the implications of it another day.

The one thing this does allow is for 3DS-2.2 to be made ready. That’s an advantage to smart merchants who can at least develop a proper, low friction SCA strategy. In the meantime, we’re looking forward to getting involved in lots of migration planning.

Crazy Cards

Crazy Cards

The reasons behind the presence of mag stripe on cards alongside chip (and PIN) has long been a debate at Consult Hyperion. Especially for the US where things were different for years – of course now the US has introduced chip and PIN as well.

But putting numbers and signatures on cards helps criminals. There’s no need for it.

A couple of years later, in “Tired: Banks that store money. Wired: Banks that store identity” we asked why banks didn’t put a token in Apple Pay that didn’t disclose the name or personal information of the holder, a “stealth card” that could be used to buy adult services online using the new Safari in-browser Apple Pay experience. This would be a simple win-win: good for the merchants as it would remove CNP fraud and good for the customers as it would prevent the next Ashley-Madison catastrophe. Keep my real identity safe in the vault, give the customer a blank card to go shopping with.

Brazil Nuts

Some years ago, we were testing Static Data Authentication (SDA) “chip and PIN” cards in the UK, we used to make our own EMV cards. To do this, we took valid card data and loaded it onto our own Java cards. These are what we in the business call “white plastic”, because they are a white plastic card with a chip on it but otherwise completely blank. Since our white plastic do-it-yourself EMV cards could not generate the correct cryptogram (because you can’t get the necessary key out of the chip on the real card, which is why you can’t make clones of EMV cards), we just set the cryptogram value to be “SDA ANTICS” or whatever (in hex). Now, if the card issuer is checking the cryptograms properly, they will spot the invalid cryptogram and reject the transaction. But if they are not checking the cryptograms, then the transaction will go through.

You might call these cards pseudo-clones. They acted like clones in that they worked correctly in the terminals, but they were not real clones. They didn’t have the right keys inside them. Naturally, if you made one of these pseudo-clones, you didn’t want to be bothered with PIN management so you made it into a “yes card” – instead of programming the chip to check that the correct PIN is entered, you programmed it to respond “yes” to whatever PIN is entered. We used these pseudo-clone cards in a number of shops in Guildford as part of our testing processes to make sure that issuers were checking the cryptograms properly. Not once did any of the Guildford shopkeepers bat an eyelid about us putting these strange blank white cards into their terminals. Of course it’s worth noting things have progressed and fortunately this wouldn’t work now as the schemes have moved on from SDA.

I heard a different story from a Brazilian contact. He discovered that a Brazilian bank was issuing SDA cards and he wanted to find out whether the bank was actually checking cryptograms properly (they weren’t). In order to determine this, he made a similar white plastic pseudo-clone card and went into a shop to try it out.

When he put the completely white card into the terminal, the Brazilian shopkeeper stopped him and asked him what he was doing and what this completely blank white card was, clearly suspecting some misbehaviour.

The guy, thinking quickly, told him that it was one of the new Apple credit cards!

“Cool” said the shopkeeper, “How can I get one?”.

Titanium Dreams

That Brazil story was written back in 2014! There was no white Apple credit card at that time but it was interesting that the shopkeeper expected an Apple credit card to be all white and with no personal data on display, just as we had suggested in our ancient ruminations on card security. Imagine the total lack of surprise when the internet tubes delivered the news of the new actual Apple credit card launched in California a couple of weeks ago. Apple CEO Tim Cook said that the new Apple Card would be the biggest card innovation “in 50 years” [FT].  This seems a little rough on the magnetic stripe, online authorisation, chip and PIN, debit cards, contactless interfaces and so on, but it is certainly an interesting development for people like us at Consult Hyperion.

The story gathered the usual media interest. A number of reports on the web reporting on “Apple going into banking” which, obviously, they are not.  Far from it. The Apple Card issuer is Goldman Sachs (it’s their first credit card product) and the card product is wholly unremarkable. The card looks pretty cool though, no doubt about that. I still don’t know why they put the cardholder name on the front (instead of their Apple ID).

Apple Card is launching into an interesting environment. The US POS is a confusing place but Apple know their stuff and I am sure that they think they can use the 2% cash back on ApplePay purchases vs. the 1% on chip/stripe to push people toward the habit of using their phones at POS instead of cards. Judging by the sign I saw in an Austin gas station, they may be right.

The Apple Card adds security, there’s no doubt about that. The card-not-present PAN and CVV displayed by the app (which can be refreshed) are not the same as the PAN and CVV on the stripe, so you can’t make counterfeit stripe cards with data from the app and Apple uses the Mastercard token Account Update service, so if you give (say) Spotify the CNP PAN/CVV and then refresh it, you don’t need to tell Spotify that you’ve changed anything because Mastercard will sort it out with Spotify. That’s security for the infrastructure and convenience for the customer.

Now You See It

While I was jotting down some notes about Apple Card, I was thinking about David Kwong, the illusionist. He gave an entertaining talk at Know 2019 in Las Vegas and I was privileged to MC his session. I was sitting feet away from him and I couldn’t figure out how he did it. That’s because he is a master of misdirection!

I can’t help feeling that there’s a bit of misdirection going on with Apple Card. The press are reporting about the card product, but it’s really not that earth shattering. It seems to me that what is really important in the announcement isn’t extending Goldman Sachs’ consumer credit business or that bribe to persuade apparently reluctant consumers to use Apple Pay at contactless terminals instead of swiping their card, but the attempt to get people to use Apple Cash. Cognisant of how Starbucks makes out by persuading citizens to exchange their US dollars that are good anywhere into Starbucks Dollars that are not, and of Facebook’s likely launch of some kind of Facebook Money, Apple are hoping to kick-start an Apple Cash ecosystem.

You may have noticed that as of now,  you can no longer fund person-to-person Apple payments (in Messages) using a credit card. You can still fund your Apple Cash via a debit card. You can pay out from your Apple Cash to a Visa debit card for a 1% fee or via ACH to a bank account for free. They want to reduce the costs of getting volume into Apple Cash and make it possible for you to get it out with jumping through hoops. Given that you can do this, you’ll be more relaxed about holding an Apple Cash balance and that means that next time you go to buy a game or a song or whatever, Apple can knock it off of your Apple Cash balance rather than feeding transactions through the card rails. 

And why not? In this ecosystem Apple would carry the float, which might well run into millions of dollars (Starbucks’ float is over a billion dollars), and if it could persuade consumers to fund app, music and movie purchases from Apple Cash instead of cards it would not only save money, but anchor an ecosystem that could become valuable to third-party providers as well. With Facebook’s electronic money play on the horizon, I think Apple are making a play not for a new kind of card to compete with my Amex Platinum and my John Lewis MasterCard but for a new kind of money to compete with BezosBucks, ZuckDollas an Google Groats.

The Yin Yang Twins: SRC and W3C’s Payment Request API

In the world of online payments (card not present), two issues that seem to be unavoidable are:

•   Continuous rise of card-not-present fraud.  Fraud rates for card not present are running at between four and ten times greater than card present depending on merchant sector

•   High cart or basket abandonment rates. Average e-commerce abandonment rate is of the order of 65%, with 24% of customers at merchants using 3DS 1.0 abandoning the transaction after starting the checkout process.

As my colleague Andrew Whitcombe laid out in an earlier post, the quest for secure online payments (or at least as secure as their face-to-face cousins) is nothing new.  We have seen initiatives such as the CVV2 and the Address Verification Service (AVS) implemented with mixed results. Other mechanisms such as 3D Secure (3DS) provide an added a layer of security, however they introduce added complexities to the checkout process which can lead to increased cart abandonment.

The good news is that regulatory authorities and relevant stakeholders are beginning to act. Various efforts within the payments industry such as tokenisation, 3DS 2.0 and Strong Customer Authentication (SCA) are directly or indirectly geared towards addressing the issues with card not present transactions.

Two initiatives of particular interest to us are the efforts of EMVCo and the World Wide Web Consortium (W3C); the Secure Remote Commerce (SRC) and the Payment Request API (PR API) respectively. They both aim to facilitate secure and interoperable online payments by providing an easier and more streamlined checkout experience. This will also go a long way in simplifying the integration processes between the players the payment ecosystem.

W3C is working on a set of specifications that define the interactions between different entities through an API – the Payment Request API (PR API). The PR API specification describes how an intermediary (typically a browser) facilitates payment between a merchant and a customer through one or more payment methods, that is managed by a Payment Handler within the customer’s device.

Similarly, EMVCo has published the Secure Remote Commerce Specification (SRC). According to EMVCo:

EMV SRC offers an approach to promote security and interoperability within the card payment experience in a remote payment environment.

At its core, SRC facilitates the checkout process using information made available via an SRC system. It allows a merchant to obtain customer payment information in a secure and consistent way, which can thereafter be used to authorise payments.  

So wait! Aren’t W3C’s PR API and EMVCo’s SRC exactly the same thing? Well, they certainly share fundamental similarities, especially in their goals.  However, they also have their differences as outlined below.

EMVCo SRC
 
W3C Payment Request API
 
The customer’s payment information is stored within the SRC ecosystem i.e. typically off the customer’s payment device.
Payment Information is typically stored within the browser or payment handler on the customer’s device i.e. Device focused.
  
Very much “card” focused.Can support a variety of payment methods, e.g. Basic Card, Tokenised Card, PISP Credit Transfer.
  

At the moment it is early days for both initiatives; it is yet to become clear which will have the biggest impact on the digital commerce landscape.  However, one interesting possibility is the idea that they could in fact work together.  As ironic as it sounds, their collective strength may actually be in their subtle differences; W3C’s PR API being payment method-agnostic, puts it in a good position to support SRC as a relevant payment method within the W3C PR framework.  Likewise, with SRC the “wallet” can be anywhere including a browser providing valuable additional flexibility.   Hence, in spite of their similarities with regards to the problems they seek to address, it is their differences that presents an opportunity for the two approaches to work together towards achieving a common objective.

But we are not out of the woods yet! Some questions remain open; will SRC actually succeed, where wallets have failed before? What if you just use W3C’s PR API & 3DS 2.0? What happens when there are multiple wallets on the consumer’s device? Will larger merchants be willing to hand over any part of the consumer experience? So far, we only have the EMVCo framework, the full understanding will only come when the schemes publish their individual interpretations of the specification. In the meantime, we at Consult Hyperion are increasingly engaged in discussions with our clients who are trying to answer some of these questions, explore potential new revenue streams and understand the associated risk profiles.

In the next blog post, we’ll take a look at other payment initiatives such as tokenisation, 3DS and open banking APIs to try to understand if and how they all fit together. In the meantime, if you want to find out more and you’re attending The Payments Summit in Phoenix next week then please let us know, we’d love to meet you there.

Loosely-coupled MaaS payments

I was a panellist discussing the barriers to mobility as a service (MaaS) at the Transport Ticketing Global (TTG19) conference in London in January. In fact, many of the presentations over the two-day conference were about MaaS and reasons why it is proving very hard to deliver. Perhaps one of the most mature MaaS offerings is the one from MaaS Global branded as ‘Whim’ which launched in the UK in the West Midlands but, by their own admission, has struggled to gain a foothold.

Until recently, MaaS providers have avoided London. We have seen some excellent journey planning apps exploiting Transport for London’s (TfL)  open APIs, but nobody was going that extra mile and actually proving a complete MaaS solution in a single app that allow both planning journeys together with payment and ticketing (i.e. proving authority to travel when entering the transit network). TfL has been very clear that they will not provide any cut of the fares to MaaS providers, so they will have to find other ways to make a profit.

So, the announcement from CityMapper that they are about to launch a MaaS solution in London surely doesn’t make any sense? Given the above barriers to MaaS and the high complexity of London’s public transport network, why on earth would you start there?

The answer is payments and identity, two of our favourite topics. These are services needed in order to offer account-based ticketing (ABT) and ABT is a corner-stone of MaaS. Passengers need to identify themselves to their customer account so that their journey charges can be calculated. Payment for the journeys needs to be handled in a way that is suitable to the particular customer.

One of the barriers I suggested on the TTG19 panel is that payment and identity are too ‘closely coupled’ in modern account-based ticketing offerings. I am old enough to remember the emergence of service oriented architectures in the ‘noughties’. The idea was that by ensuring services are ‘loosely coupled’, they can freely evolve without affecting consumers or implementations. I argued that if everyone rushes to implement the open-loop payment models with the payment networks like TfL has done, then we will be left with fare collection services that are highly dependent on the payment schemes and constrained from evolution. The identifier the passenger uses at the gate is their bank card (or its emulation on mobile or wearable devices). This identifies them to their ABT travel account but it also identifies their means of payment. Some would say this is convenient, I am suggesting it is too closely coupled and will stifle innovation.

Open banking APIs are a subject close to our hearts at the moment. The APIs are very new and they seem not to be thinking about transit payments at this stage. However, one could imagine that there could be future open banking APIs that would allow passengers to consent to transit payments from their bank to their MaaS provider without the need for the payment networks in between. I expect this will be subject of future blogs or white papers from Chyp.

The reason CityMapper is launching in London is that all the public transport modes accept open-loop payments and the CityMapper solution to payments and identity is to provide their MaaS customers with a Mastercard-branded prepaid card, ‘Pass’. CityMapper will offer a subscription model at a discount on TfL prices and any travel on TfL modes outside of this will simply use the prepaid bank card like any other.

This works for all London public transport modes, but there are very few other cities that have committed so totally to the open-loop models. It will be interesting to see whether CityMapper can make a profit and if they do, whether they can replicate it outside of London. Right now, it looks like they are using investment funding and planning on taking a loss to start with since they are offering to undercut the TfL fares and as stated above TfL has said they will not offer discounts to Maas providers. Or perhaps city mapper is planning on selling advertising space or plans to sell anonymised travel data to make up the shortfall? Only time will tell.

Meanwhile, may all your transit tokens be loosely coupled and your payment instruments plentiful.

 

Tough decisions for Acquirers and PSPs in 2019

In 2018/2019 both merchants and payment providers face pressing, strategic questions related to the selection of the payment methods they support, that need to be answered. 

European regulatory initiatives like PSD2, promoting instant payments, open banking, and data sharing have created a new payments ecosystem. Acquirers, PSPs and card schemes, threatened by the risk of being bypassed by Third Party Providers, are now looking at new business models and the roles they can play in this new ecosystem. However, the key questions remain, whether to continue playing in the traditional card acquiring space and/or to take full advantage of PSD2 by opting for PISP/AISP licensing? What can be done in-house, and what in collaborating with partners for those opportunities that lie outside the expertise?

There are other questions relating to the future direction of European Card Acquiring. In 2018, cards continued to grow their share of the European payments market, but the increasing scheme fees are eroding the benefits of interchange regulation. The British Retail Consortium warned in 2018 that scheme fees increased 39% in 2017. Various consumer groups asked the European regulators to step in to protect merchants from hidden fee increases. The UK Payment Systems Regulator (PSR) announced in July 2018 a market review into card-acquiring services, including a public consultation whether there is effective competition and supply of card-acquiring services.  

What’s next for Card Acquiring, Scheme fees and Interchange Fee Regulation in Europe in 2019? 

The future of card acquiring, fees evolution, new merchant payments options, Open API technology are among the key topics to be discussed at the MPE 2019, Europe’s Largest Merchant Payment Acceptance Conference in Berlin, February 19-21. Consult Hyperion are delighted to support MPE once again. If you’d like to meet with the team, please email sam.wakefield@chyp.com to arrange a meeting.

You can request the Agenda & register at www.merchantpaymentsecosystem.com.


Subscribe to our newsletter

You have successfully subscribed to the newsletter

There was an error while trying to send your request. Please try again.

By accepting the Terms, you consent to Consult Hyperion communicating with you regarding our events, reports and services through our regular newsletter. You can unsubscribe anytime through our newsletters or by emailing us.