Re: [w3c/browser-payment-api] Fix #129 (#153)

@hober and @nickjshearer, there is no guarantee that the browser will be able to pass any data to a payment app after the payment response has been received by the website. On some platforms this may be impossible and on others result in a terrible user experience.

`complete()` is just an instruction to the browser to tear down the payment app UI (or any other UI that is still visible) as the website is now taking focus.

There are only two ways we can guarantee that a more complex interaction is possible between website and payment app:

 1. The payment app is built into the browser so we can guarantee that the payment app is able to interact directly with the website.
 1. The payment processing is done BEFORE the response is returned to the browser through some out of band channel.

To expand on option 2 and use @nickjshearer 's example:

> This PIN (in encrypted form) is passed from the payment app via the user agent and payment processor to the issuing bank, where it's validated. If it's incorrect, the payment processor is instead of providing a "Success" or "Failure" going to return an "Incorrect PIN" status.

It would be better (and arguably more secure) if the payment request contained a callback URL that the payment app used to submit the PIN. This would allow the payment app to complete the entire payment processing flow and only return focus to the browser when it has confirmed the payment.

This was raised in #109 where there is a flow diagram that explains the concept in more detail.

Since this callback requirement is not shared by all payment methods it's probably best to leave it to be defined in the payment method specific data for now and standardize if we feel it's required later.

---
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/browser-payment-api/pull/153#issuecomment-216494033

Received on Tuesday, 3 May 2016 10:52:19 UTC