Re: [webpayments] How are payment messages trusted? (#19)

> Some elements in the payment response may need to be hidden from the merchant also (e.g. card number), so signatures don't meet this requirement. 

I'm wondering if you're raising another important issue. 

This particular thread is about how you can trust a particular payment message.

I think what you're talking about could be broken into two sub-issues:

1. How can you obfuscate information in a payment message (encryption), and
2. What do you do with data that a PSP should not see (such as receipt information intended for a customer), or data that a merchant shouldn't see (such as a card number)?

Care to split it out into a different issue, @mattsaxon?

> Since we are creating other connection from the browser, e.g. to cloud payment instruments, couldn't the connection to the PSP be via the same means? My view is we may need to support both methods.

For things like the PAN, I think the PSP would just drop that on the floor and not include it in the payment response message.

You do raise another interesting point, though. For example, when we get to digital receipts, how is that handled? The merchant could:

1. Provide a digital receipt at the point of the payment request
2. The pop-up takes over (keeping the merchant channel open), splits the digital receipt out (storing it temporarily), sends the payment request (sans receipt) onto the payment processor channel
3. The payment processor responds with a success via the payment processor channel
4. The pop-up opens a receipt storage channel to the customer's receipt storage location w/ the receipt and proof of success
5. The pop-up then relays the proof of success via the merchant channel back to the merchant.

In this example, the pop-up has 3 channels open: 

* merchant channel
* receipt storage channel
* payment processor channel

To be clear, I don't think this is what we should do - receipts would most likely be best handled as after-the-fact storage decisions. I can't think of a realistic use case where we'd need to open more than two channels, but I can certainly conjure up edge-case ULTRA SECURE payment instruments that require you to piece together data from different servers at different data centers around the world.

Just food for thought - we may need to open more than 2 channels in the payment selection pop-up/message relay component (aka wallet).

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/19#issuecomment-161505540