How are web-based payment apps supported?

[msporny]

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.

[adrianhopebailie]

@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.

[adrianhopebailie]

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 😄

[burdges]

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.

[wayneca]

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.)

[adrianhopebailie]

@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

[dlongley]

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

[msporny]

+1 to @wcarr's comments.

[adrianhopebailie]

This is being addressed in the Payment Apps proposal at:
https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html

[msporny]

How is it being addressed? Is there a separate issue on the payment apps proposal that covers this?

[ianbjacobs]

The spec indicates the intent to address it. The spec is not yet fleshed out enough to demonstrate that it does address it.

The spec says: "It [this specification] defines mechanisms that may be used to support both Web-based and native payment apps."

Ian

[msporny]

The question that this issue raised is: How are web-based payment apps supported?

The response seems to be: "The spec indicates the intent to address the question" ... which is a non-answer. It doesn't address the question that was asked. It was a question of "how", not "do you intend to address it?"

We shouldn't close issues that ask "how" questions until the mechanism to address the question becomes clear.

[ianbjacobs]

I think the whole project of the Working Group is to answer the question. It is in our charter. Therefore, it does not seem particularly useful to me to register this broad an issue.

Once we have a proposal on the table, it makes more sense to me to raise specific issues about the proposal.

Ian

[msporny]

it makes more sense to me to raise specific issues about the proposal

It makes more sense to me to track the issues we have and not close them until we have resolutions to the issues raised.

[adrianhopebailie]

@msporny what value does having this issue open provide the group?

The whole purpose of the payment apps spec is to address how web-based payment apps will be supported. Answering that question in the issue list of a different spec seems pointless to me.

I agree with @ianbjacobs that this type of generic question is no longer of any value in this list. It is just creating noise.

As the Payment Apps spec is not yet a WG ED it does not have it's own repo or issue list so issues on the proposal are being tracked on the WG list with the label "Proposal: Payment Apps".

The sooner the group agrees to adopt a proposal for payment apps the sooner we will have a concrete draft to work on and log issues against.