Re: [w3c/payment-handler] Open Window Algorithm and tracking through 1ps (#351)

hi @snyderp,

> It depends on the details of those redirection flows, how deeply nested they are, etc. Safari, for 
> example, prevents some sites that are part of redirection flows from keeping state (ITP2.x) (those > that it thinks are tracking). 

So an interesting question is: what information can be sent by the merchant to the payment handler once the user selects the payment handler to pay? The Payment Handler API defines some data for the browser to hand to the payment handler. This is data deemed necessary for the transaction to take place:
 https://w3c.github.io/payment-handler/#the-paymentrequestevent

The browser passes the origin of the merchant site (and the origin of the party that called Payment Request API, e.g., if from an iframe). 

In addition, a payment method definition can include its own "request data" (e.g., information to identify the merchant to the payment handler). 

> Not all visits to the checkout / payment page result in entering information (some users decide not to purchase). 

That would be the same as if the user were to cancel the payment handler before completing payment.

>  And some visitors may want to maintain different identities with the same payment provider, so 
> (for a variety of reasons) may choose to present one identity payment.com when buying boring 
> things, and might present another identity to payment.com when buying sensitive things. (e.g., 
> paying for insurance and paying for a cancer screening).

I believe that the payment handler approach would support that use case. A (Web-based) payment handler is a Web site, so the user should be able to interact with it with different identities.







-- 
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-handler/issues/351#issuecomment-547198036