Re: Payment Method Spec for Card Issuer Tokens

On 16 September 2016 at 08:04, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2016-09-15 00:22, Adrian Hope-Bailie wrote:
>
> Hi all,
>
> I had a meeting today with a company that deploy mobile apps for banks
> including a whole load of backend security infrastucture for issuing of
> issuer tokens.
>
> They are very keen to build payment app functionality into the apps they
> already build for banks but are concerned that given the current state of
> things there is unlikely to ever be situation where a banks app could be
> used to make a payment other than in countries where there are already push
> based schemes.
>
> Issuer tokens are the card tokens that are created by the card issuing
> bank and provisioned onto a user's mobile device for secure online
> payments. The tokens can be issued with various restrictions on their use
> (one time vs recurring, amount limits, merchant limits) etc.
>
>
> I wouldn't characterize this as "push" payments, it is rather an improved
> version of existing card schemes like 3DS.
>

No, this is tokenized card. i.e. Pull with a slightly more secure auth token


>
> Anyway, lots of similar (but fairly local) systems out there perform real
> push payments which among many things exclude card networks, exploiting the
> fact that banks in many countries charges nothing for such transfers.  Push
> doesn't need tokenization since it only hands over a payment receipt or
> similar to the merchant.
>
>
Correct


>
>
> The token looks like a card number so to the merchant or acquirer they
> just look like a card number and therefor they pass through the network
> seamlessly. As I understand it these are similar to the tokens used in
> schemes like Apple Pay and Samsung Pay but those are issued in conjunction
> with Apple/Samsung where as these are just issued by the banks.
>
>
> As I understand Apple Pay requires patches somewhere in the backend since
> at least local payments do not rely on the client having Internet
> connectivity.
>
>
> The feedback I got was that an open payment method for tokenised card
> payments is essential otherwise they see no future for the payment app
> ecosystem other than for proprietary apps.
>
> Basic card will be fulfilled by browsers so there is no way for an issuer
> to offer payment via a more secure mechanism without third-parties. We
> don't want every bank coming up with their own payment method.
>
> So, I'd encourage anyone with knowledge of how these schemes work and
> access to the specs to provide input into a first draft payment method spec
> that we can work on next week.
>
>
> Creating a scalable tokenization scheme seems hard.  EMV tokenization is
> really just a set of guidelines where awkward stuff like authentication to
> tokenization providers have been left to implementers.
>

Correct but there is enough in the guidelines to define a message format
between the merchant and the payment app which is all we need to define a
payment method for the Web Payments APIs.


>
> Anders
>
>
>
> Adrian
>
>
>