W3C home > Mailing lists > Public > public-payments-wg@w3.org > September 2016

Re: Payment Method Spec for Card Issuer Tokens

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Fri, 16 Sep 2016 12:25:55 +0200
Message-ID: <CA+eFz_KUHME248BJnr7moxcKLW+kYPsbGr9fGh5mdtJuWHo-ng@mail.gmail.com>
To: Kevin Hurley <kph@fb.com>
Cc: Jason Normore <jason.normore@shopify.com>, Manu Sporny <msporny@digitalbazaar.com>, "public-payments-wg@w3.org" <public-payments-wg@w3.org>, Roy McElmurry <rvm4@fb.com>
Hi guys,

To clarify, my request was specific to issuer tokens for card payments.

It looks like a regular PAN and it is handled by the merchant like a
regular PAN.
It is routed by the network to the token provider (as opposed to the card
issuer) because they are the owner of the token's BIN.

The token provider has a relationship with the issuer (or in the case I am
referring to, is just another system run by the issuer) and forwards the
transaction with the original PAN (instead of the token) to the issuer for
auth.

These are the same tokens that get provisioned into a mobile device for NFC
etc.

In reality a payment app could respond to a payment request using the basic
card payment method and provide an issuer token. The system is designed for
this to work.

But, there are advantages to the merchant and user if the merchant can
explicitly say they support handling issuer tokens because the app can
provision a token specifically for that merchant on the fly.

The initial spec that Facebook have submitted looks like a good starting
point.

Lot's to discuss at TPAC!

On 15 September 2016 at 06:42, Kevin Hurley <kph@fb.com> wrote:

> 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> 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>
> *Date: *Wednesday, September 14, 2016 at 9:00 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
>
>
>
> 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> 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> 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=
>
>
>
Received on Friday, 16 September 2016 10:26:33 UTC

This archive was generated by hypermail 2.3.1 : Friday, 16 September 2016 10:26:34 UTC