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= <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=>