W3C home > Mailing lists > Public > public-payments-wg@w3.org > July 2016

Re: [w3c/webpayments] [Payment Apps] Extending invocation of payment apps with other techniques than HTTP (#156)

From: Adrian Hope-Bailie <notifications@github.com>
Date: Wed, 13 Jul 2016 04:07:55 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Cc:
Message-ID: <w3c/webpayments/issues/156/232324970@github.com>
> 2. Creating a channel between the invoking Web page and the native App.

@cyberphone - I agree with this statement but think there are ways to do this that you're ignoring

Apple can do this in their solution because the solution is only available if you're using an all Apple stack.

In situations where this is not guaranteed we must cross boundaries (network and process) over channels that use platform-agnostic technology like HTTP.

The approach of the PaymentRequest API is to simply define the interface for initiation. 

If the payment method employed is simply returning some credentials that are used by the merchant or PSP to process the payment then we can use the response returned through the API for this.

If the payment method is any more sophisticated (like most payment methods) where the payment is actually processed by the payer's payment app then it's pretty likely that a different channel between the payment app and the payee will be established for this.

Note that here I am talking about a channel between the payment app and the payee (NOT the payee website). Trying to communicate directly with the client side code of the payee website is fraught with trouble (as you have pointed out numerous times) so it would be far more likely that the payment app would communicate directly with the payee's back-end systems.

Once the payment app completes it's processing it can return a response to the website that is no more than a signal that it is complete (it may contain some data that allows the website to reconcile the processing that the app did with it's back-end services but this is not essential).

The website can then call out to it's own back0end service to establish the state of the payment and behave accordingly.

The platform agnostic way to establish this channel would be for the request to contain a callback URL or similar that allows the payment app to establish a channel after it receives the request.

The platform specific mechanisms are outside the scope of the W3C to define but event then it seems fraught with trouble to try and establish a channel from a native payment app to the client side code of the payee website.

---
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/issues/156#issuecomment-232324970
Received on Wednesday, 13 July 2016 11:08:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 13 July 2016 11:08:26 UTC