Re: Authenticating Merchants

Payment Providers that want to do Merchant authentication, should require
some form of Merchant identifier to be passed in the PaymentMethodData.data
<https://w3c.github.io/browser-payment-api/#dom-paymentmethoddata> field.
The Payment Provider is free to decide how this data field should look, and
what are the required fields, so there's no problem requiring the Merchant
to also pass some kind of signature that can verify the integrity of the
Payment Request and the identity of the Merchant.

You could argue that these things should be actual members of the Payment
Request dictionary or on of the sub dictionaries, but I think it's actually
better that they are not. First and foremost; Merchants will most likely
have different identifiers with the different Payment Providers, meaning
that a single merchantId field is not going to work very well for a Payment
Request that supports many different payment methods.

Signing Payment Requests has been discussed, for instance here:
https://github.com/w3c/browser-payment-api/issues/291

-Tommy

On Wed, Feb 22, 2017 at 8:58 AM, Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> Have you considered authenticating Merchants in some way?
> It is possible that I haven't looked enough, but I couldn't find such
> references.
>
> Merchant authentication seems to have two primary goals:
> 1) giving the Payment Provider a chance to block a payment request because
> the Merchant has been black-listed.
> 2) if authentication is performed through a digital signature, verify that
> the payment request haven't been tampered with.
>
> Apple Pay seems to have something along these lines which (at least)
> checks that the Merchant is a genuine Apple Pay Merchant.
>
> /A
>
>