Why SamsungPay is Toast

Samsung Pay has 2 parts

androidlknox
Android L

1) NFC (Contactless EMV ISO 14443 stuff)

2) MST (Mag Stripe Emulation)

Both “could” work in the new Google world. But Samsung does not seem to be aware of the new Android efforts to build an organic security solution within Arm’s TrustZone that completely steps on the proprietary work they did (mostly with Knox). For background, see the following articles

– Android L vs Samsung (see this article)

Samsung Knox 2.4 vs Google For Work

Samsung nixes Knox – Bob Eagan

The BRAND NEW Google for Work Security Whitepaper

Historically, NFC wallets driven by GSMA’s SIM based approach require MNO support (keys for either SIM based or for embedded). SamsungPay was based upon a new software SE that ran within its own proprietary security architecture.

Android for work
NEW Android M

Problem is that Google’s new Android M steps on Samsung’s security architecture. Both are claiming the same space.. Sorry I can’t be more specific.. I’m almost 50 now and have lost most of my real skills.

Now Samsung could redesign its wallet, give up its security architecture and run within Google’s HCE environment. Samsung pay would operate as Google wallet does.. at Parity. But Samsung is not currently running in this model.. Samsung could also launch a loopPay only wallet that works in this model..

Why are Google and Samsung so focused here on payments and security!!? See my blog on Brokering Identity, and Authentication in Value Nets. The key to future profitability within mobile is about managing interaction between the physical and virtual world… security, identity and authentication is EVERYTHING.

Forget about technology.. here is the real problem

Let’s assume that Samsung solves ALL of the technical issues above and now SamsungPay works on all Android devices. Everyone knows that MNOs decide what gets pre-installed on the phones they subsidize (even Apple). Six weeks before MWC, Google made a strategic deal with the US MNOs to buy ISIS in exchange for Android Pay (the new Google wallet) becoming part of Google Mandatory Services (GMS.. just like search and gmail).  Part of this is also a new android registration flow that addresses THE KEY weakness of Android profitability.. it gets consumers to add a card and play account (Apple brilliantly required an iTunes… with accompanying credit card.. in launch of iPhone).

Samsung’s wallet could still work.. however IT IS NOT PRE LOADED.. so this is what the consumer would have to do (AFTER REGISTERING FOR ANDROID PAY):

1) Find out about Samsung pay

2) Install Samsung Pay

3) Register for Samsung Pay

4) Understand where they can use Samsung Pay

5) Wave it near the Mag Head reader

6) Then use Android pay for in-app and play purchases..

Forget about the technical issues. In a world where only 6% of iPhone 6 users have ever used mobile payments..  What Mobile wallet has ever succeeded without:

#1 MNO Support

#2 OS Support

#3 Merchant Support … PLUC

#4 An ACTIVE COMPETING WALLET in same phone

Samsung .. just drop it… !? there is no longer any revenue or data rights associated with it.

6 thoughts on “Why SamsungPay is Toast”

  1. Tom,
    Here are some facts about Samsung Pay that you should know, and why your assumptions may be off.
    1) The TEE (Trusted Execution Environment) or Trustzones are just segregated storage containers inside of device memory blocked off from normal access by other apps, Google or anyone can use a 3rd party or proprietary TEE, all can co-exist in the same environment. Samsung Pay uses TEE for storage of tokens and LUKs, with our own keys, and has no problem co-existing with any 3rd party TEE solutions. It’s like having many locked rooms in a hotel, we each have our own keys.
    2) Your assumption that Samsung Pay is not preloaded on Samsung phones is false, it will be preloaded with the major carrier builds. That said, having preload does not constitute success, in fact there are a ton of preloaded apps that go nowhere, while many successful apps that are not preloaded. Consumer experience is absolutely key for a mobile wallet, one that can truly work everywhere (like our current wallet do).
    3) Truth is, no wallet has succeed yet. Period. Not because they didn’t have: MNO Support, OS Support, Merchant Support, or Competing Wallets in the same phone – but because they are not giving consumers a real wallet that works everywhere, as a basic starting point. (Apple, Google, Softcard all have the same issue, and Android Pay certainly have not solved that issue.) Ubiquitous merchant acceptance is an essential chemical ingredient for combustion, but a truly useful mobile wallet has to do more, it has to provide more utility and value for consumers, and provide more than the current plastic cards that are inert and non-contextual.
    4) Samsung Pay has a unique solution to provide an outstanding consumer experience on a mobile wallet that:
    a) works with most of their cards from credit, debit, to gift, private label, to loyalty and membership cards
    b) is accepted at vast majority of merchants around the world, today! Regardless if they have EMV terminals or mag stripe only terminals, SP also works with merchants existing barcode readers for loyalty. Samsung Pay does not require merchants to change and has merchant support. There is certainly a lot of work still need to be done for any wallet to evolve, but there has to be a foundation.
    5) The winning solution will also have to be properly marketed to consumers. MNO have learned their lesson after spending hundreds of millions marketing Softcard without success, I doubt they’ll be spending large amounts of money to market Android Pay. When it comes to marketing, there are few consumer product companies better at marketing than Samsung, with feet on the ground, and ads in the air, Samsung is a pretty good bet to get the word out to customers about its solutions.

    It won’t be easy to succeed for any business, especially in mobile wallets, but I believe Samsung Pay has an excellent chance at being one of the first to do so. I hope this information is helpful. Don’t hesitate to ping me at will@looppay.com if you have questions or want to discuss offline.
    Best regards,
    Will
    Will Wang Graylin
    Co-GM Samsung Pay/CEO LoopPay

    1. I will let the community respond on technology, the hotel metaphor is a good one. Yes ARMs TEE allows many rooms, but with Android M Google is the hotel room manager. This holds for device certification (firmware on top of ARM) and the business terms with the MNOs (from SE keys to TEE permissions). The problem extends when EMV certification (card emulation) is included.

      I’m surprised to hear about MNO support. My view is that the only way for this to happen is for an MST/LoopPay only wallet.. driven by new GMS agreement and fact that 2 active NFC wallets on the phone is just plain silly. So assuming that you have LoopPay installed on the phone, I think you will find your Bank issuers upset with you Will. Just 2-3 weeks ago they were testing the “production” handsets with a registration flow that included SamsungPay. We both know this will not happen in the US (well perhaps with Sprint). So how are you going to break the news to Citi, BAC, JPM that the registration process for Verizon/ATT/TMob will be for AndroidPay.. and you won’t have consumers active in your new phones unless they discover your app in the phone and register for it (later). They are waiting to hear from you guys on this today.

      How do you explain a MST wallet to consumers.. when they don’t even use the one they have (ex 6% of iPhone consumers have ever used ApplePay). When there is a competing wallet active on the phone for GooglePlay, NFC, Uber, .. When do they use yours? Why should they bother registering. ..

      1. Tom,
        1) You are misinformed that Samsung needs Android M to access the TEE, or that you need business terms with MNOs to access the TEE. There are no SE keys necessary from MNOs, in fact the whole point of TEE as a storage is to avoid having to deal with the SE.
        2) You are misinformed about access to the NFC radio on the handsets, the whole point of HCE is for Android to provide access to the NFC radio without going through the SE or eSE. Wallet providers and Banks can access the NFC radio today via HCE, just like developers can access the Bluetooth Radio, the question is who will be a Token Requestor (TR) from Visa, MC, Amex, etc. Samsung Pay is certainly a TR that banks and networks are excited to work with, because Samsung Pay is the only one that has ubiquitous acceptance to deliver secure tokens, without waiting for merchants to change.
        3) Yes, Samsung Pay will be preloaded.
        4) Samsung will certainly have a significant marketing plan to inform users about Samsung Pay and to drive user adoption.
        5) Most importantly is how Samsung can provide a useful wallet solution for consumers, issuers, and merchants that truly works ubiquitously. Feel free to ping me if you have questions on any of the above technical details.

        1. I’m certainly one to admit when wrong… but don’t think I am here, not much detail on what samsungPay is: 1) MST/Loop only, 2) NFC only, 3) Combined. After we get specific on that, please let me know what OS it is running on: Android M, Samsung’s own OS (in US). Finally we can talk about what Secure OS/Stack it is running on: 1) Google’s Secure OS Services with Google’s ARM TZ Firmware or 2) Samsung’s secure OS and Firmware. Best to establish this before we discuss NFC/HCE.

          1) Capability. Android is openSource and Samsung needs nothing from anyone to make SamsungPay work in a Samsung only world. However, in a world where Samsung does not control the OS, they are dependent on the Firmware and OS that sits on top of the Processor (see in http://www.arm.com/products/processors/technologies/trustzone/tee-smc.php). Android M’s management of the trustzone “hotel rooms” has evolved (see https://static.googleusercontent.com/media/www.google.com/en/US/work/android/files/android-for-work-security-white-paper.pdf) to Secure OS Services. IF Samsung uses Google’s version of the Secure OS Kernel then there will be conflict both technically, and with respect to the GMS agreements with US MNOs. There is a battle brewing what was OEM turf (firmware/Secure OS).
          2) Agree on HCE. The Loop side of Samsung Pay can certainly run has HCE… However what about NFC/EMV? For the international version of SamsungPay (NFC/EMV) have you always planned on running as HCE!? Interesting as there are no certified HCE card provisioning applications (as of last week). What about Samsung’s software secure element? With respect to tokens, it will be very interesting to see how Mastercard will work on Loop, particularly post Oct liability shift (given there is no MST transaction type on MA’s network).
          3) Will both Loop MST AND NFC be pre-loaded? I’m assuming that Loop side will be pre-loaded, but there will be no user registration process that enables the wallet when handset is turned on.. that will be Google’s process.
          4) .. no comment
          5) I’m most interested in the CHAOS that this will cause with merchants and issuers post Oct 2015 (liability shift). This may have been a great idea 4 years ago, but banks and merchants want to move consumers toward 1-2 new behaviors NOT 4-1!! EMV contactless was always top of the list.. DIP is how the rest of the world works.. I don’t think we can handle a third uniquely US process..

  2. Thanks for the info! Just one correction: iPhone activation did require an iTunes account (now it only requires an iCloud account), but it never required a credit card be entered. An iTunes account can be filled via the use of iTunes cards bought in a store with cash, so a credit card is never required.

Leave a Reply

Your email address will not be published. Required fields are marked *