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

Payment Method Spec for Card Issuer Tokens

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Thu, 15 Sep 2016 00:22:26 +0200
Message-ID: <CA+eFz_KpdHXiiJFR_fJ6pzFHekPS4ebzLcoQmx3h0imNrtqzWQ@mail.gmail.com>
To: Payments WG <public-payments-wg@w3.org>
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.

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.

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.

Adrian
Received on Wednesday, 14 September 2016 22:22:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 14 September 2016 22:22:55 UTC