Re: Rethinking Apps Payments API, Re: Payment App API: updated flow description

> On Jan 23, 2017, at 9:50 AM, Jake Archibald <jakearchibald@google.com> wrote:
> 
> Comparing the two APIs:
> 
> I'm going to use MC to refer to Marcos' spec, and PG to refer to the payment group’s.

Thanks, Jake. Both Marcos’ text and your comparison are valuable in advancing this spec. I think we are likely to surface important issues and we’ll work hard to piece it all back together as we walk through them. Here is a quick response and I need more time for more thoughtful suggestions.

Ian

> 
> # Registration
> 
> I like how MC makes permission explicit. In PG, it isn't really clear that setManifest would be a permission-requiring method. However, I think something like https://github.com/marcoscaceres/payment-request-handler/issues/2 would be closer to how it's defined for similar APIs like Push. I like the integration with the permission API.

The specs both expect permission. PG could be even more explicit. We should definitely consider integration with the permission API.

> 
> # Setting payment methods & metadata
> 
> I much prefer the MC option of having APIs to get/set parts of the payment app, rather than have one big object specify it. Both APIs are open to some race conditions when it comes to getting & setting a value, but this is much more likely to cause an issue in the PG API.

I have also heard some appreciation for the finer granularity.

> 
> With the PG example, if I wanted to add an "option", I have to get the entire manifest, add an "option" to the returned object, then set it. If I have one thread trying to update the icons while another is adding an option, the reads and writes can interleave, resulting in data loss.
> 
> MC has icons per "method", whereas PG has a single set of icons for the app. From what I understand, the icons are intended for the app as a whole, so MC should move the definition of this somewhere else. It's another good argument for https://github.com/marcoscaceres/payment-request-handler/issues/2.
> 
> MC is missing somewhere to add the name of the app. I don't know if this is intentional. If not, it could also go in the register call.
> 
> # "Can handle payment"
> 
> As Marcos pointed out, PG's use of canHandle doesn't really make sense. You can see the fudging around step 10 https://w3c.github.io/webpayments-payment-apps-api/#matching - this would break all kinds of expectations around closures. Also, it's kinda why service workers were invented - MC gets this right.

While not disputing the closure questions, I think MC is not addressing the problem we intend to address with this. The goal of canHandle () is so that a payment app can say whether it is capable of supporting a payment method in light of the merchant’s additional filters. in the case of basic card, for example, the merchant can say “I only take visa debit”. The payment app responses “yes I can do this” or “no I can’t” to the user agent, which then either displays it as a candidate for payment or doesn’t.


> 
> The event name MC uses "canhandlepayment" doesn't sound like an event. Maybe that doesn't matter. ev.canMakePayment could probably be better named too, since it feels like it's "allowing" if called without any params. respondWith(promise) might be a better model to follow. Anyway that's a minor bit of bikeshedding.
> 
> # Handling a payment
> 
> I'd love to see some UI proposals for how a user is connected to a particular payment app. That might help solve some of the confusion around https://github.com/w3c/webpayments-payment-apps-api/issues/48.

We are starting to see some implementation experience in the payment app task force…I’ll see if we can get some UI screen shots. 

> 
> This is the most important part of the spec for me, as the patterns here will influence other APIs that call out to another API that may want to show UI, such as the credential API, and maybe intent APIs in future.
> 
> I don't have strong opinions on the PaymentRequest (MC) vs PaymentAppRequest (PG) objects. It comes down to if it makes sense to expose the methods & events on the PaymentRequest object to the other origin. The more I think about it, the PG model might make more sense.
> 
> The way MC puts openClientWindow on the event object is great - this means the browser can link the created window to the payment process, which PG cannot. With the MC model, the browser can automatically close the window once the payment is complete, and return to the vendor site.

(Note to self to reread this :)

> 
> Both MC and PG rely on up to two tabs plus a service worker being in memory to make a payment work.

On the call there was discussion about the fact that we do not want the payment app to open in a new tab.

In 10.4 we now say:

"To support scenarios that involve visual display and user interaction, user agents MUST allow payment apps to call the clients.openWindow() method defined in [SERVICE-WORKERS]. Because user agents can determine from event type that the window is part of a payment flow, the user agent SHOULD render the window in a way that is consistent with the flow and not confusing to the user. For example, we recommend that the payment app not be opened in a new browser tab, as this is too dissociated from the checkout context."

> This may cause problems with lower-memory devices - I'm not sure. Working around this would massively complicate the API, so hopefully it won't be a problem.
> 
> Both models rely on postMessage to communicate with the client. I'm in two minds about it, but there may be higher-level options that would allow the client to produce the response itself. Eg:
> 
> addEventListener("paymentrequest", event => {
>   if (canHandleWithoutUi) {
>     event.respondWith(response);
>     return;
>   }
>   event.respondWith(event.showWindow(url));
> });
> 
> And the window would have something like navigator.payments.provideResponse(response) which, when called, would close the window, and pass the result back to the service worker. Again, I'm in two minds about it, but it'd remove the need for the clunky postmessage work.
> 
> Hope this helps!

Thanks again!

Ian
--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Received on Monday, 23 January 2017 16:02:56 UTC