Re: Payment Method Spec for Card Issuer Tokens

Hi Jason,

Perhaps I’m misunderstanding the original question, but my understanding was that this was meant for card tokenization.  The solution I describe may not always be used solely for card tokenization, but for the purpose of this discussion, let’s assume that it is only used for debit/credit cards.  So in this case, let’s say Target is our merchant and Google is providing our payment tokens.   You have your credit card stored with Google and Google wishes to share this card with Target but only share a single use credential and not your real PAN.  Google has an integration with company XYZ.  Google sends your PAN to XYZ which issues a new card and CVV (effectively acting as a card issuer).  Google passes this new PAN and CVV to Target.  Target uses this PAN/CVV combo just like they would use any other credit card number, passing it to their credit card processor.  Eventually it gets routed back to the card issuer (XYZ) which charges the real card PAN.

So Target doesn’t need to have any special integration with the card networks other than through their typical payment processor.  Maybe I’m not understanding what you’re stating though.

Kevin

From: Jason Normore <jason.normore@shopify.com>
Date: Wednesday, September 14, 2016 at 9:24 PM
To: Kevin Hurley <kph@fb.com>, Manu Sporny <msporny@digitalbazaar.com>, "public-payments-wg@w3.org" <public-payments-wg@w3.org>
Cc: Roy McElmurry <rvm4@fb.com>
Subject: Re: Payment Method Spec for Card Issuer Tokens

Thanks Kevin. So you mean the issuer would (or could) point the alias PAN to something other than a credit card? This makes sense if so, but does it solve the case that Adrian described? Because it still means it's a credit card tokenization (it looks like one and goes over the same rails). The fact that it goes over the same rails as a card implies that anyone using it must have a relationship with a network (in order to issue the tokenized card and have them route it properly). My point is that a open payment method that covers more than just "card network tokenization" wouldn't make sense. Maybe it's not meant to cover more than that though, I could have misinterpreted the use case.

Jason
On Thu, Sep 15, 2016 at 12:11 AM Kevin Hurley <kph@fb.com<mailto:kph@fb.com>> wrote:
Hi Jason,

I don’t believe that is always the case.  There are implementations where the payment app can work with a provider that provides a PAN and CVV which act as the tokenized form of a card and a cryptogram.  The merchant does not need any special integration directly with anyone to use these.  They go through their standard credit card processing rails and the card gets routed back to the issuer which was the one who did the tokenization of the card.  I can provide some more details if you’re interested.

Kevin

From: Jason Normore <jason.normore@shopify.com<mailto:jason.normore@shopify.com>>
Date: Wednesday, September 14, 2016 at 9:00 PM
To: Kevin Hurley <kph@fb.com<mailto:kph@fb.com>>, Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>>, "public-payments-wg@w3.org<mailto:public-payments-wg@w3.org>" <public-payments-wg@w3.org<mailto:public-payments-wg@w3.org>>
Cc: Roy McElmurry <rvm4@fb.com<mailto:rvm4@fb.com>>
Subject: Re: Payment Method Spec for Card Issuer Tokens

What you're describing is EMVco Payment Tokenization, which is behind Apple / Android / Samsung Pay. The way this works today is that card networks have tokenization services (as defined within the EMV spec) that allow these wallet providers to create the device specific tokens (just as you describe, same characteristics of a cc PAN). There's nothing stopping a individual issuing bank (or any other entity) that has its own card brand or other payment instrument type from creating it's own tokenization service as defined by the spec to accomplish the same thing, in fact I believe this is how Interac (here in Canada) works with some of the wallets (including bank specific wallets).

This does require that the merchant have an integration directly with this issuer as they do through processor -> acquiring bank -> networks with credit cards in order to process payments. The key here is that no matter where your integration starts, the payment info ends up at the same place anyway (the network or one of it's issuers), if this integration is different depending on some part of the payment method spec (some sub type) it's going to be hard to get merchants on board, it's similar to asking them to have a separate integration for visa, MasterCard, and Amex. So I think a spec defining the structure is useful but I think it's a mistake to assume it's all the same payment method, unless you're talking about just tokenization mechanisms for the card brands that go through the same pipes as basic card (and end up in the same place), but this doesn't sound like what the bank is describing, it sounds like they want their own proprietary payment instrument to fall into the same general category to what the networks have built. Tokenization isn't the payment method, the dereferenced data defines the payment method, I can tokenize an email address and I wouldn't call that the same payment method to a tokenized credit card (the customer or merchant wouldn't understand).

A bit of a stream of late night text (sorry!) so I'd be happy to go over it live with anyone interested. Unfortunately I won't be at TPAC though.

Jason


On Wed, Sep 14, 2016 at 9:22 PM Kevin Hurley <kph@fb.com<mailto:kph@fb.com>> wrote:
I actually worked on a spec for this with Roy that includes both network and issuer tokens.  I think either Roy or myself will post it later tonight or tomorrow


On 9/14/16, 5:31 PM, "Manu Sporny" <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:

    On 09/14/2016 06:22 PM, Adrian Hope-Bailie wrote:
    > Basic card will be fulfilled by browsers

    Can you elaborate on this point, Adrian?

    Are you saying that /only browsers/ will be able to offer basic card
    details? Or are you saying that most people may choose to store this
    information w/ the browser.

    I hope it's not the former.

    To give an example of how this ecosystem could play out: Browsers
    already give you the option of storing your passwords. Still, LastPass
    has a thriving business. I'd expect the same for Basic Card, and I
    especially hope that we're not saying that our expectation is that a
    number of us creating "payment wallets" are going to be prevented from
    playing in this space.

    Wrt. tokenization, I agree and that would be great to have a
    tokenization spec.

    -- manu

    --
    Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
    Founder/CEO - Digital Bazaar, Inc.
    blog: Rebalancing How the Web is Built
    https://urldefense.proofpoint.com/v2/url?u=http-3A__manu.sporny.org_2016_rebalancing_&d=DQICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=czvCyIIR0NLkuLwCEQgGEA&m=UQiRJx8ILkXLFHz3WedicGrkc8p-GmkvJFy-ahwc4Fg&s=irfcmQLKpNCnlC9_PGlwG9UZqA3ZIVTt5UHyAYzICos&e=