Re: Limitations of "Push" payment schemes

You make a good points Anders.

Push is definitely more appealing and more "possible" these days because
more and more payers have a device in their hand that can "push", a
smartphone.

I agree that for certain payment types push is a challenge (subscriptions,
offline etc) but I think one can look at push as a rail and still build
these experiences on it using the model being proposed by PSD2 where we
decouple the initiator from the payee.

i.e. I can delegate authority to someone I trust to "push" payments from my
account at the request of a payee in response to a regular subscription.
That doesn't mean I give the payee access to my account.

The advantage of this is that I can still be very selective about who
accesses my account and under what terms. I also have very fine grained
control over this process.

Admittedly this is not far off what the card networks are attempting with
tokenization. The difference being that the push system is a far more
distributed architecture where there is not a need for everyone to be
signed up to the same network scheme.

On 26 August 2016 at 21:40, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> On 2016-08-26 21:26, Erik Anderson wrote:
>
>> Only if there is multiple factors of Authentication, Authorization, and
>> Identification.
>>
>
>
> Could there maybe be an hour or two for security related topics during
> TPAC?
>
> Anders
>
>
>
>>
>> Practice: But in practice push is rarely used. low adoption, so of
>> course there is less fraud.
>>
>>
>> Good quote about this: "In theory, practice and theory are the same.  In
>> practice, they are not."
>>
>> Erik Anderson
>> Bloomberg
>>
>> On Fri, Aug 26, 2016, at 01:15 AM, Anders Rundgren wrote:
>>
>>> Dear All,
>>>
>>> When I first begin looking into payments I (without really thinking too
>>> much about it), came up with a "Push" payment system. Push indeed has
>>> certain undeniable qualities like not exposing customer data to merchants
>>> as well as supporting bank-specific authentication methods.
>>>
>>> However, if the goal is supporting a wider range of payment scenarios,
>>> "Push" doesn't seem to be the optimal approach.  So far I have identified
>>> the following disadvantages:
>>>
>>> - Considerably more complex "Wallets" which have to deal with two
>>> independent but cooperating channels and unspecified user-authentication
>>> will most likely lead to each bank rolling their own
>>>
>>> - Incompatible with automated gas stations, subscriptions, bookings etc.
>>> which all depend on some kind of "pull" method
>>>
>>> - Adds dependency on Internet connectivity also for local payments
>>>
>>> It is also worth keeping in mind that "pull" payments is the de-facto
>>> standard for local card-payments so it obviously works.
>>>
>>> Anders Rundgren
>>> Principal, WebPKI.org
>>>
>>>
>>>
>>
>>
>
>