Re: [w3c/payment-request] What should we do with MerchantValidationEvent? (#927)

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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/927#issuecomment-698105005