@marcoscaceres If I recall correctly we avoided this before because we felt there was no way to be certain that the payment handler (if it wasn't the browser) would be able to emit such an event. I.e. IPC between the handler (if it is a mobile app for example) and the browser is not guaranteed to be available. I think that based on where we are with the handler architecture that view has probably softened and this would be the ideal design. I'm definitely a +1 @rsolomakhin asked: > What's your definition of an open payment method? Those with a URL payment method identifier. For those payment methods the browser doesn't know which fields to redact if it was to emit a `PaymentChangeEvent`. > For payment methods implemented in a payment app, Chrome currently does not have a way to know which instrument is being selected inside of the payment app, so Chrome could let the merchant know only the list of payment methods supported by the selected payment app. That sounds like something we want to add to Payment Handler API? The ability to emit such an event. In this case it would be up to the handler to ensure it doesn't leak private data. -- 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/684#issuecomment-365866075
Received on Thursday, 15 February 2018 09:11:00 UTC