> The merchant calls the (non-existent) Payment Receipt API and provides the payment app id and other relevant data. -1, Digital Bazaar would object to a design where the browser routes receipts to payment apps for at least these reasons: 1) in a number of cases, you can't deliver the receipt immediately and it must therefore be done at a later time where the browser may not be available, and 2) this could potentially conflict with the way we could store digital receipts using a future Verifiable Claims API. I suggest the WPWG coordinates with the Verifiable Claims WG on this as digital receipts are in scope for that charter. We would prefer that an HTTP endpoint is provided in the PaymentResponse that can then be used by the merchant to push a receipt asynchronously (when it's ready). An endpoint that allows a receipt to be pulled, as @adrianhopebailie suggests, is also appropriate. We're less interested in the details at this point than we are the general design, which SHOULD NOT be browser centric. -- 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-298916389
Received on Wednesday, 3 May 2017 13:51:03 UTC