Re: Web Payments Demo

> What alternatives are there besides selecting a payment instrument?
Please elaborate.

Some verbose examples...

Example 1

The two PMIs http://webpay.org/cards/visa and
http://webpay.org/cards/mastercard are both defined in the Basic Card
payment method spec.
The PMI http://webpay.org/bitcoin is defined in the Basic Bitcoin payment
method spec.
Bob (the customer) has a payment app called EasyPay registered which
supports the Basic Card payment method.
He also has an app called CoinPay which supports the Basic Bitcoin payment
method.
His EasyPay app has two cards stored (his VISA card and his MasterCard).

Bob shops at XYZ Hardware and and checks out and
http://webpay.org/cards/visa, http://webpay.org/cards/mastercard and
http://webpay.org/bitcoin are listed as supported methods in the payment
request.

Bob's browser prompts him to select a payment app from both EasyPay and
CoinPay.
He selects EasyPay and the app is invoked.

In the app Bob is offered the choice of paying with his stored Visa card,
his stored Mastercard or adding a new card.
He selects his visa card and also selects an option to use this card by
default at this merchant in future.

The EasyPay app returns a payment response to the website with the details
of Bob's visa card.
What is interesting to note is that it would make very little difference to
the website if the payment request listed the selected payment method as
http://webpay.org/cards/visa (Basic Card using a Visa card) or
http://webpay.org/cards (Basic Card).
The format of the payment method data in the response would be the same
irresepective of which card type Bob chose to use.

The only value in having two PMIs (http://webpay.org/cards/visa and
http://webpay.org/cards/mastercard) is for the website to provide extra
semantics to the browser about specifically which cards it supports. If we
are only interested in the choice between payment method (i.e. between
Basic Card or Bitcoin) then those two PMIs mean the same thing.

The point here is that we have conflated selecting a payment app and
payment method with selecting a payment instrument. In this case XYZ
Hardware doesn't care which payment instrument Bob chose as long as it's a
brand they support. In terms of processing the response they only care
about whether Bob is paying by card or Bitcoin.

Example 2

Same scenario as above except that instead of http://webpay.org/bitcoin
imagine the following 3 PMIs are all defined in the Basic Bitcoin payment
spec: http://webpay.org/bitcoin/v1, http://webpay.org/bitcoin/v2 and
http://webpay.org/bitcoin/v3

In the spec the differences between the 3 versions of Bitcoin payment are
defined and merchants and payment apps don't all support all 3 versions.
Let's assume later versions added features for faster payment validation or
the ability to include reference data in the request.

XYZ Hardware only support v2 and v3 because they consider v1 insecure.

So in this example Bob shops at XYZ Hardware and and checks out and
http://webpay.org/cards/visa, http://webpay.org/cards/mastercard,
http://webpay.org/bitcoin/v2 and http://webpay.org/bitcoin/v3 are listed as
supported methods in the payment request.

Bob's browser prompts him to select a payment app from both EasyPay and
CoinPay.
He selects CoinPay and the app is invoked.

CoinPay supports all of the different versions of the Bitcoin payment
method but it's not going to ask Bob which he wants to use, he doesn't
care. Instead CoinPay picks the latest version that is also supported by
XYZ Hardware (in this case v3).

So as soon as Bob authorizes the transaction the CoinPay app executes the
payment and returns a response to the website with
http://webpay.org/bitcoin/v3 as the chosen payment method.

Example 3

Bob visits his bank's website and is prompted to install a new payment app
that has his bank's Visa card preconfigured.
He installs this app and the app label/name is ABC Bank VISA.
This app can't be configured to hold additional cards.

Now when Bob shops at XYZ Hardware and checks out and
http://webpay.org/cards/visa, http://webpay.org/cards/mastercard and
http://webpay.org/bitcoin are listed as supported methods in the payment
request his browser prompts him to select a payment app from EasyPay,
CoinPay and ABC Bank VISA.

If he selects ABC Bank VISA the app is invoked and all he has to do is
authorize the transaction.
i.e. No selecting payment instrument.

Some key take-aways here:

   - Users pick a payment app (unless the browser has been configured to do
   this automatically likely for specific scenarios)
   - Users don't have any idea of payment methods and should never have to
   pick a payment method. What they do when picking a payment instrument in
   some cases is to implicitly pick a payment method but also a specific
   payment method identifier which attaches extra semantics to the selection
   (e.g.: Bob has chosen to pay by card and has also chosen to pay using a
   VISA card).
   - We need to make more of a differentiation between a payment method
   (e.g. Basic Card) and the extra semantics we are trying to pass in the PMI
   (e.g. supported brands).


On 27 May 2016 at 17:53, Rouslan Solomakhin <rouslan@google.com> wrote:

> On Fri, May 27, 2016 at 6:57 AM Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>
>>
>>    - How the selection of a payment method is done by a payment app will
>>    depend on the payment method. We shouldn't assume that it always means
>>    selecting a payment instrument. That is a very card-centric way of seeing
>>    things.
>>
>> What alternatives are there besides selecting a payment instrument?
> Please elaborate.
>