search

w3c / payment-request

Payment Request API
https://www.w3.org/TR/payment-request-1.1/
Other
482 stars 183 forks source link

What should we do with MerchantValidationEvent? #927

Closed marcoscaceres closed 3 years ago

marcoscaceres commented 3 years ago

Right now, MerchantValidationEvent is a Safari only feature. Should MerchantValidationEvent be "at risk" or can we get a second implementation? There seemed to be some level of commitment on the Chrome side but seems it hasn't shipped: https://bugs.chromium.org/p/chromium/issues/detail?id=867904

ianbjacobs commented 3 years ago

Per some discussion: propose to mark as informative.

ianbjacobs commented 3 years ago

Plan is to publish this feature as an independent Working Group Note.

cyberphone commented 3 years ago

AFAIK, existing payment systems already perform merchant validation, albeit at the backend.

It is true that the user may indeed authorize a payment to a "bad" merchant but since the bad merchant won't be accepted by the backend systems, the user is not at risk. Well, unless the payment handler leaks credit card data but then we are really talking about bad payment handlers.

Apple Pay requires merchants to provide an Apple-issued certificate in order to get the payment handler to accept a request. The certificate is (AFAIK...) also used for encrypting authorization data to the backend. I believe Google's counterpart uses a similar arrangement for the encryption part.

Saturn takes this notion one step further by encrypting the user's authorization with an encryption key that is specific for the payment credential issuer. This enhances privacy as well since the only thing (bad or good) third parties learn about users is what bank and payment method they have used for a particular authorization. The validation of a merchant including its claimed receive account is performed through a "merchant manifest" (published by the merchant's payment provider), referenced by the payment credential issuer's backend during authorization.