Re: [w3c/webpayments-payment-handler] How to support communication with a payment app after initial PR API interaction? (#143)

Ian,

Can I be clear on what use cases this is solving for? Is it so the app knows about the status of payments that are async?

I'm interested in receipts, but I think other use cases may be more important, e.g. a receipt from a payment app to a merchant that a payment has been completed, so the merchant can dispatch goods or allow download of digital media immediately.

Regards,
Matt

Sent from my iPhone

> On 2 May 2017, at 15:59, ianbjacobs <notifications@github.com> wrote:
> 
> Hi all,
> 
> At the recent Web Payments IG ftf meeting, we discussed digital receipts, and
> there was some support (in the form of raised hands) for enabling a "post Payment
> Request API" flow where the merchant sends a digital receipt (or other information)
> to the payment app that was selected by the user for the transaction. (Note: This thread
> is not about digital receipt formats; it's about the flow of information from payee back
> to payer after PR API has completed.)
> 
> Two pieces of information seem to be necessary:
> 
> Transaction id
> Payment app id
> I believe that Payment Request API and Payment Handler API provide for the communication of a transaction id.
> 
> Regarding a payment app id, I have the following requirements in mind:
> 
> REQ 1) The information must not reveal the identity of the payment app to the payee.
> REQ 2) The user agent must not be required to store information about "which payment app handled which transaction id."
> 
> I was wondering whether using hashes would make sense:
> 
> Upon registration of a payment app, the user agent computes a hash that uniquely identifies the payment app. This payment app id should be robust in the face of payment app updates (and perhaps other changes to the user environment) and ideally would be a one-time hash so that the merchant cannot detect that the same payment app was used for multiple transactions. It is probably also appropriate to ensure that the user has granted permission to the user agent
> to route receipts asynchronously to a payment app.
> The user agent returns the payment app id along with other payment response data to the merchant.
> The merchant calls the (non-existent) Payment Receipt API and provides the payment app id and other relevant data.
> The user agent compares the id with the database of payment app ids and routes the data to the corresponding payment app. How the payment app responds is up to the payment app. For example, the payment app might notify the user that it has received a receipt.
> A response message to the merchant indicates success or failure. (If the payment app is no longer registered, the user agent would send a failure message to the merchant.)
> Another potential requirement might be:
> 
> REQ 3) The system must prevent the user agent from routing the receipt to any payment app that was not the payment app used for the original transaction. This includes the requirement that no other payment apps must be made aware of the existence of the receipt.
> 
> To accomplish this, the transaction id might be used to generate the payment app id.
> 
> Although there is not yet any Working Group chartered to work on a Payment Receipt API,
> I would like for us to discuss the general question of how to enable interaction with a payment app
> for payee-initiated activities after Payment Request API.
> 
> I do not expect to address this issue prior to FPWD. We may not address this issue in V1 at all.
> 
> However, I am interested in hearing from people whether they think this is an interesting use case, and also thoughts on the three requirements I've drafted.
> 
> Ian
> 
> [1] https://www.w3.org/2017/03/22-wpay-minutes#item04
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
> 


-- 
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/webpayments-payment-handler/issues/143#issuecomment-298710805