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