Re: Spec/vision Clarification

The purpose of the standard data, which would include more than price, is
to help the component that helps the user select a payment app, filter
which apps are able to process the payment.

One can imagine having a bunch of payment apps installed which support
different payment methods and may have other constraints on the payments
they are able to process.

It should be possible for the mediator (likely the browser) to (possibly
with user interaction) be able to narrow the list down to a single payment
app without needing to probe each one to find out if it is capable of
processing the requested payment.

On 13 November 2015 at 09:09, Anders Rundgren <anders.rundgren.net@gmail.com
> wrote:

> Hi Payment-Lovers,
>
> The JSONesque example below shows a very simple version of a possible
> Payment Request a la W3C Web Payments:
>
> "paymentRequest":
>    {
>       "amount": "10.5",
>       "currency": "USD",
>    }
>
> However, assuming that the request is targeting a system along the lines
> of my published PoC [1], the message also has to hold native payment
> request data like this:
>
> "paymentRequest":
>    {
>       "amount": "10.5",
>       "currency": "USD",
>       "customData": <native payment request data>
>    }
>
> The question that comes to my mind is simply: What purpose does the W3C
> Payment Request have in this particular case?
>
> Is the idea that "Wallets" like in the PoC, should use "amount" etc. from
> the W3C Payment Request and thus refrain from defining such data in the
> native version?  Unfortunately, there is no alternative for the PoC since
> the native part is signed (identifying a payee payment network member) and
> supposed to be countersigned by the user in order to create a fully
> end-to-end-secured solution using "stacked" signatures quite similar to
> what Cyril Vignet showed in his SCAI paper.
>
> Cheers,
> Anders
> 1] https://test.webpki.org/webpay-merchant
>
>
>
>