Re: Payment Initiation - platform integration

On 16 September 2015 at 15:47, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2015-09-16 15:03, Adrian Hope-Bailie wrote:
>
>> <snip>
>>
>>         The best example I could find is in the Web Notifications PR
>> published
>>
>>     > earlier this month:
>> http://www.w3.org/TR/2015/PR-notifications-20150910/#displaying-notifications
>>
>>     I don't understand much of this spec :-(  But I doubt it has any
>> bearings on invocation of wallets and such.
>>
>>
>> </snip>
>>
>> To be clear, I am not suggesting that the Web payments API in the
>>
> > browser would invoke the notifications API on the host platform.
>
> I see.
>
> I am drawing attention to a precedent for invocation of a platform
>>
> > API as a result of a browser API being invoked.
>
> The difference is that notifications are passive and fairly innocent
> (unless you are bombarded by them), while wallets are active,
> "full-duplex",
> and attractive for various attacks.
>

I'm not sure that the aspects of the payment we wish to standardize are
much more complex notifications. They are a two communication
(request/response) but I wouldn't call them "full-duplex".

We are proposing a simple request/response pattern where the response from
the platform API can be returned to the calling website via either the
browser API response or an event (like the pattern used for the "show"
event in the notifications rec.). That should be discussed and decided by
the WG.

In my opinion, any complex interactions that a specific scheme requires
should be handled out of band.

The goal of this browser API is to reduce friction for users in making a
payment and standardise a mechanism for payment data to flow between the
payee website and payer wallet service.

By doing this we open up the whole ecosystem for innovation in both payee
applications and payer wallets which will allow them to address issues such
as security unrestrained by the need for changes to a scheme or
introduction of new schemes to require massive user adoption.

As an example (card-centric but it illustrates the point), if card issuers
could magically replace all of the issued cards in the world with a new
instrument that was more user friendly for digital payments they would have
solved much of this friction and the current security issues already. They
can't the world (at least in NA and Europe) is full of consumers with cards
and acquirers who accept them.

Instead every single card issuer (that I am aware of) is moving to a
digital wallet model where the wallet is the digital instrument that can
work seamlessly on the Web without user's needing to type in their card
number. As an interim measure this wallet is a wrapper for one or more
cards but often it also holds or proxies other instruments. I'm sure that
long term the card will disappear completely and the wallet will be a
stand-alone instrument.

Note that for the payee the fact that the wallet is an instrument or is
using another that it "holds" may not be known but that doesn't matter as
long as there is a *common* instrument that can be used to complete the
payment.

*Common* means payers and payees need to support it and making this happen
for anything new or radically changed is the fundamental issue.

The current wallet ecosystem is fragmented and user adoption is very poor.
If something is easier to ignore than to use, then it will never gain
adoption.

What we (the WG) are aiming to do is make digital wallets the first class
citizens for payments on the Web but we need to do this in a way that is
not too prescriptive so that wallets and schemes can be innovative and also
try to be conscious of not creating an ecosystem that gives an unfair
advantage to any stakeholder.

I.e. If we simply create the API and make it simple enough then the
definition of what a wallet is or does will even change over time but the
messages between payer and payee will still flow via this same simple API.


>
>
>> What is not clear to me is how this would work for cloud-based wallets.
>>
> > Perhaps the recommendation would be that the browser allows the user to
> > provide a wallet API endpoint (URL) that conforms to our recommendations
> > or it will invoke the platform's payment API?
>
> I think we should do a distinction between Web-wallets like PayPal and
> Google Wallet for Android which was (is?) a local wallet using cloud-based
> payment credentials.
>

I agree. In fact the mention of cloud based credentials even cloud's the
issue. I see the situation far more simply.

1. The browser API receives a request message which it either POSTs to a
user configured endpoint or passes to a platform defined API.

2. The browser receives a response which it passes back to the website
either by resolving the promise that was returned by the original API call
or by raising an appropriate event.

That request response pattern can be used for payment initiation
(effectively selection and confirmation of the instrument to be used),
payment completion (for push payment when the website requests the wallet
to make the payment) and payment notification (for pull payment when the
website notifies the wallet that the payment has been completed).


>
> The security model required by Web wallets won't permit payment instrument
> enumeration so they have rather different characteristics compared to any
> form of local wallet.
>

I'm not sure I understand this statement. I see no issue with a message
object being POST'ed to a Web wallet's API endpoint?


>
> Anders
>
>
>>
>