ApplePay in Browser by Summer 2015

Very short blog

Today ApplePay is limited to in-App purchase and at the POS (using NFC). Per my blog last week, mCommerce is one of the fastest growing trends in the industry right now. Apple will be extending the “touch ID” payment experience to all Safari browsers (with merchant support). Contrary to the poor POS/NFC uptake.. this will be a MASSIVE SUCCESS!!

Pre-requisite/Set Up

  1. Merchant implements new ApplePay API that looks for supporting browser/device. Similar to what Google Checkout, Stripe, Braintree have done for accepting a token in lieu of card and cardholder data
  2. There is likely some other device/browser information going to merchant (like applePay plug-in on browser)
  3. Consumer has at least one touch ID compliant device (iphone 5s or 6)

UC 1 – ApplePay on MacBook – Easiest one to explain

  1. Consumer Checks Out
  2. Merchant checkout page finds supporting device/plug-in and displays “pay with Applepay”
  3. Consumer selects pay with Apple Pay
  4. Consumer’s iPhone 6 comes up with tough ID prompt (touch ID to complete purchase with Merchant X). Side note somehow Apple Keychain management is involved in exchange between devices
  5. Merchant receives token(s) for user ID and for card. User ID token is resolved through Apple service, Card Token is routed through TSP in current iPhone 6 AP model.

Merchant  Benefits

  1. conversion
  2. new CNP  rate tier for “tokenized” eCommerce (see my blog above from last week)
  3. fraud liability shift

Significantly it was announced that EMVCo just took over the next version of the 3DS spec. Remember when this happened for tokens?

Impacts

  1. Paypal’s US take rate is around 340 bps, Apple will enable merchants to accept payments at a new rate tier and shift liability unto banks for 140-160.. wow..
  2. I believe Google is also in good shape to capitalize here, as is Visa Checkout. Perhaps Visa Checkout morphs into ApplePay online from a CYBS perspective. (CYBS becomes AP acquirer)

 

 

My confidence in this prediction 95%.

 

9 thoughts on “ApplePay in Browser by Summer 2015”

  1. ridiculous.

    Currently these are the requirements for ApplePay to work on apps:
    • Set up an account with a payment processor or gateway, if you don’t already have one
    • Register a Merchant Identifier via Certificates, Identifiers & Profiles
    • Submit a Certificate Signing Request to obtain Public and Private keys that will be used to encrypt and decrypt Payment Tokens
    • Include an Apple Pay entitlement in your app.

    The crucial step of public encryption key of vendors sitting
    at ApplePay Servers. Currently Apple sends tokens using Apple encryption keys
    to ApplePay servers which get re-encrypted with Vendor Keys which are sent forward.

    This is question of scale. Apple simply can’t support any website nor would it want to.

    Encryption Keys sit in the EMC chip. That is a requirement of standard.
    If it was in the KeyChain then Apple would have more devices supported for apps.

    Browser part is easy can be done yesterday.
    What is hard is getting all the website to send their encryption keys
    to Apple.
    if it was easy all their apps would have them already.

    If a vendor already does this with their apps then Apple has advantage which can’t be done anyone else including macs.

    1. Thanks so much for sharing. Think you are 90% correct on above.. on point #3 the CSR would be to “sign” the card token not to encrypt it. Even in EMV card numbers go in the clear.. this is why the networks want tokens .. a way to obfuscate the PAN. In a web implementation there is a need for Apple to sign and for the merchant to sign the transaction, or give token assurance information.

      There are many unknowns in the specification, and the common requirements. Remember in the VBV/MSC implementation the merchant implemented a iFrame redirect for the consumer to enter a PIN.. this was a form of “signing” by the bank. So screwy things have taken place here before

      1. Transaction-specific dynamic security code

        All payment transactions originating from the payment applets include a transaction-
        specific dynamic security code along with a Device Account Number. This one-time
        code is computed using a key that’s provisioned in the payment applet during
        personalization and is known by the payment network and/or the issuer. Other data is
        also used in the calculation of these codes, including the following:
        • A counter that is incremented for each new transaction
        • A random number generated by the payment applet
        • Another random number generated by the terminal—in the case of an NFC transaction
        or
        • Another random number generated by the server—in the case of transactions within
        apps
        These security codes are provided to the payment network and the issuer, which allows
        them to verify each transaction. The length of these security codes may vary based on
        the type of transaction being done.

          1. More detail can be found by googling Apple Security Document from October 2014.
            It is called iOS_Security_Guide_Oct_2014.pdf

            It amazes me that so called ApplePay experts have not read this document yet they pontificate about touch-id, ApplePay, NFC, etc without anyone calling them out.

            for example touch_id for mac can only come out if Intel builds a Secure Enclave for Apple and Secure Element and FingerPrint reader. Do you really think intel can put a ARM Cortex M3 processor inside their chip and have encryption key written at manufacture time. And Government will let them do that.
            And Would Apple want to share this tech with other PC manufacturers.
            or use a non secure tech.
            No need to answer the above questions.

        1. OK, so integrating desktop browsers is a bit of a challenge. Could you enlighten me if mobile Safari is doable? I would assume yes, but I am not an expert…

Leave a Reply

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