Migrating issue from w3c/webpayments#16

How do we support Web-based payment apps? These instruments require a user to:

1. Start on the merchant website
2. Click buy
3. Select the web-based instrument
4. Navigate to a 3rd party website to approve the transaction
5. Return to the merchant website with a token, approval code, or other proof that the transaction has been approved.

I suggest that we support web-based payment instruments and local payment instruments using the same mechanism. There is a URL that is used to invoke the payment instrument. Local Android payment instruments would use an Intent URL (or something similar). Cloud-based instruments would use an HTTP-based URL. Both would have a callback URL (either another Intent URL or an HTTP-based URL).

I admit that this proposal is a bit hand wavy as I do not have a great deal of experience routing messages from a browser to an intent-based URL and back to the browser.

@msporny Can you edit this to use the terminology "payment app" as opposed to "payment instrument"? It seems more appropriate now based on the proposed architecture.

While I can understand that the integration between user agents and native payment apps is a complex issue (see #50) I believe that we should have some minimum conformance criteria for user agents and web based payment apps.

This could be as simple as mandating that the payment request is submitted to the app URL via a POST.

We could define two standard response types:

1. HTML - in which case the user agent renders the HTML (the app UI)
2. Some other type that indicates to the user agent that the app is not web based but provides some signal that enables the user agent to invoke the native app.

I need to flesh this idea out a little more

I think web based payment apps might necessary be rather similar to the way they work today:

After the pay button is hit, the user gets forwarded to the payment app selector, which forwards them to the web based payment app. After the user approves the transaction, the web based payment app forwards them back to the payees fulfillment page.

We must watch anything fancier closely for same origin violations. In this space, the spec's real value is probably standardizing the data formats to enable payees to support more web payment apps more easily, not enabling some additional interaction.

Since Web pages don't have access to tamper proof execution on the user device, a Web page payment app would likely execute secure functions on a server. One means of doing that could be:

1. Web page Payment App registration can be done like service registration in Web Intents. User navigates to a Web page that offers a Web page Payment Application. Web page calls a registration API, passing a Web page payment app URL and indicates what payment methods it supports. Reregistration changes URL or payment methods or unregisters. (whatever WebIntents ended with)

2. Payment Mediator selects Payment Application as usual and can choose one registered as a Web page payment application

3. Browser (Payment Mediator) starts Web page Payment Application page in a tab if it has been chosen for a payment. The payment app can interact with the user to login with Web Authentication, etc.

   4a. WG defines an additional, alternative payment request API that passes a JSON object that contains the same information that is passed to the other (currently proposed) payment request API that comes from and is, optionally, digitally signed by the merchant.

   4b. Define a way to pass the JSON payment request object to the payment application Web page when it is opened in a tab. (e.g. the JSON payment request is placed in a defined location in the DOM)

4c. Define a way for the Web page Payment Application to return a JSON object with the payment response (confirmation that it was payed or else with the information about how to complete the payment) (where again the JSON object can optionally be digitally signed, this time by the entity paying). (e.g. in the object in the DOM the Web page payment app where it gets its input, there is an API for providing the result. That API fulfills the promise given in the payment request in the merchant page.)

@wcarr please could you provide your input on the proposal at https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html

You can log issues at https://github.com/w3c/webpayments/issues/ with the label Proposal: Payment Apps or submit PR's directly against the proposal

@wcarr, I very much agree with your comments. The approach is very similar to what the WPCG came up with.

+1 to @wcarr's comments.