How are cloud-based payment apps supported? about webpayments

[msporny]

I suggest that we support cloud-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.

[mattsaxon]

Agreed. The only thing I would add is that these payment instrument should be able to be specified by the merchant as well as the client. A use case for this is where the merchant has a nominated token service provider. The client would not know or want to know about this.

[cyberphone]

Note: Since I'm neither a JavaScript guru nor browser platform builder, the following may be off:
It is not clear to me how an API instantiated on a merchant page will deal with redirects to a payment provider site and still be able to provide a return result.

[rsolomakhin]

I think there will be no redirects. A browser will open a new tab, window, or dialog with the payment provider website. The browser is then responsible for piping information between the merchant website and the payment provider website.

[msporny]

The only thing I would add is that these payment instrument should be able to be specified by the merchant as well as the client. A use case for this is where the merchant has a nominated token service provider. The client would not know or want to know about this.

I think this information would be in the payment request and would be another piece of data in the "acceptedPaymentScheme" entry. That is, the merchant would say "I accept tokenized card transactions and here is my TSP". The buyer would select their "tokenized card" payment instrument, which would then redirect to the payment instrument issuer, which would then redirect to the merchant's TSP.

The upside is that all payment instruments would follow simple redirect logic. The downside being that there is one extra redirect w/ a TSP-based payment instrument.

Just a thought, not really married to the idea.

If we decide to have ad-hoc payment instruments, which is I think where @mattsaxon is going, we'd have to think a bit more in depth about it as that's one flow we (the Web Payments CG) haven't really thought through and I'd defer to @mattsaxon since I know next to nothing about how TSPs work.

[msporny]

I think there will be no redirects. A browser will open a new tab, window, or dialog with the payment provider website. The browser is then responsible for piping information between the merchant website and the payment provider website.

That's exactly right @rsolomakhin.

The way we've implemented this in the Credentials CG reference implementation (which has a tremendous amount of overlap with how the Web Payments API could be implemented) is by using a Promise that is fulfilled once the payment request has been processed by the payment processor. A code example of what this looks like to the Web developer can be seen here:

http://wicg.github.io/web-payments-browser-api/#processing-a-payment-request

Here's how a polyfill for it could be implemented.

1. navigator.payment.request(payRequest) is called, generating a Promise that the merchant waits to be resolved.
2. A pop-up opens, user selects the payment instrument, pop-up opens channel to payment processor via postMessage() or similar mechanism. I'm handwaving at the details as the thing that's important is that the channel to the merchant is kept open and a channel to the payment processor is opened, and something exists to relay the message back and forth between those two actors (the pop-up).
3. payment processor processes payment request, calls navigator.payment.acknowledge(payResponse), which relays the payment acknowledgement back to the pop-up, which relays the payment acknowledgement back to the merchant, which fulfills the promise.

[msporny]

It is not clear to me how an API instantiated on a merchant page will deal with redirects to a payment provider site and still be able to provide a return result.

To be clear, this is also possible via URL-based callbacks, you can relay messages using that mechanism, but it forces Web developers to initiate a payment at one location and complete it at another location (which is done today, but it's not as nice as just waiting for a promise to be fulfilled). Note that this second approach is sort of what the HTTP API uses (because that sort of programming paradigm is more common place in non-browser HTTP clients):

http://web-payments.github.io/web-payments-http-api/#processing-a-payment-request

[mountainhippo]

Historically, this approach to data flows created the opportunity for
nefarious users to intercept and rewrite payment messages (amounts in
particular) and the relevant confirmatory messages. All can be solved with
signatures and hashes but this vulnerability is a reason why redirect via
the browser or other agent fell out of vogue.

Nick

Nick Telford-Reed
e: [email protected]
m: [phone]
On 3 Dec 2015 3:10 a.m., "Manu Sporny" [email protected] wrote:

It is not clear to me how an API instantiated on a merchant page will deal
with redirects to a payment provider site and still be able to provide a
return result.

To be clear, this is also possible via URL-based callbacks, you can relay
messages using that mechanism, but it forces Web developers to initiate a
payment at one location and complete it at another location (which is done
today, but it's not as nice as just waiting for a promise to be fulfilled).
Note that this second approach is sort of what the HTTP API uses (because
that sort of programming paradigm is more common place in non-browser HTTP
clients):

http://web-payments.github.io/web-payments-http-api/#processing-a-payment-request

—
Reply to this email directly or view it on GitHub
#16 (comment).

[dlongley]

I imagine we'd have two different flows based on whether a browser API is being used or an HTTP API.

With a browser API, it could involve the merchant site making a JavaScript call that would cause the browser to open a popup with a secure browsing context. The browser will display payment instrument choices and/or cloud-based wallet choices. Then, it would use some discoverable or previously registered information to obtain a URL to load that will display a UI to the user to allow them to use the payment instrument/make the payment (depending on the type of instrument). This website would then make a JavaScript call to acknowledge that the payment is complete (or just that an instrument was selected) which would cause the browser to relay that acknowledgement back to the opening context to resolve the promise for the merchant's website. This is very similar to what Manu described earlier.

With an HTTP API, a system of callbacks could instead be used to implement something very similar.

In both cases, a digital signature on the payment request could ensure integrity and non-repudiability.

[dlongley]

I wanted to note that the browser API approach above is polyfillable today (I've implemented something very similar for a different purpose in the Credentials CG).

[mattsaxon]

I think this information would be in the payment request and would be another piece of data in the "acceptedPaymentScheme" entry. That is, the merchant would say "I accept tokenized card transactions and here is my TSP". The buyer would select their "tokenized card" payment instrument, which would then redirect to the payment instrument issuer, which would then redirect to the merchant's TSP.

I think this is a workable solution for PSP supplied tokens. I think issuer supplied tokens could work in this way also, though most issuer token today are supplied out of band and stored in a a wallet (e.g. ApplePay). So we need to cover both the just in time tokenised flow and the pre-tokenised flow. These will be documented as part of the flows Task Force.

[adrianhopebailie]

I want to attempt to close the issue by referring to the proposed new terminology and therefor place payment instruments in a different place in this flow.

Here is a slight variation of @msporny 's flow above:

1. navigator.payments.requestPayment() is called, generating a Promise that the merchant waits to be resolved.
   1. A pop-up opens (rendered by the UA who is acting as payment mediator in this context), user selects the payment app they want to use.
2. A new dialogue window opens and renders the content fetched via a POST to the payment app's request endpoint (with the original payment reuqest object passed to the browser API as the request payload, trimmed to exclude content that is not appropriate for this app).
3. The payment app processes the payment request, calls navigator.payments.respond(...), which closes the dialogue and relays the payment response back to the UA which fulfills the promise in the merchant website's window.

As you can see, unless the UA provides a way for the payment app to be built-into the UA as an extension or similar (or provides a bridge to a native app - as may be the case for mobile platforms) all payment apps are cloud-based and certainly they will have out of band comms with their publisher or processors to perform a variety of functions like authenticating the user, getting tokens or similar.

[burdges]

Just to clarify, a cloud based instrument is something like a verification page by a bank or visa or paypal? In other words, any cloud based payment schemes behave somewhat like old school payment schemes, even if they're much younger?

[adrianhopebailie]

I renamed this to use the "payment app" terminology as I don't want to lose the valuable discussion points made so far.

This does relate to #42 but in this case is specific to payment apps that are hosted remotely (i.e. their UI is fetched via HTTP and rendered by the browser).

[dlongley]

While we have turned a lot of focus toward payment apps (and away from payment instruments), I don't know if the rename keeps the same meaning here. Perhaps we want two separate issues, one related to cloud-based payment instruments and another for cloud-based payment apps.

[adrianhopebailie]

I don't know if the rename keeps the same meaning here

I agree it doesn't but this thread seems to be focused on what we are calling a payment app. What would a cloud-based payment instrument be? Is there such a thing?

[ianbjacobs]

I think "payment app" should not care whether the app is run entirely locally, locally and remotely, or entirely remotely.

Ian

[adrianhopebailie]

I didn't want to close this thread (which was tempting because it has had no input for a long time) because there is some good discussion about how we will actually implement payment apps on a desktop (assuming they will simply be apps on mobile).

It relates to #42 but we could close it if we feel that the discussion is better suited to that thread.

[msporny]

Migrated to w3c/payment-request#39