Re: Payment Method Spec for Card Issuer Tokens

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.

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.


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

Anders


>
> Adrian
>