Payment Apps Task Force

<scribe> Scribe: Ian

Payment Handler FPWD

https://www.w3.org/blog/wpwg/2017/05/18/payment-handler-api-first-public-working-draft-published/

Implementations

IJ: Upcoming implementation plans or ideas?

rouslan__: In Chrome...we are developing the API for Android and Desktop. Our desktop PR API implementation has not yet shipped, so we are focused on Android for now.
... we are looking into how to properly open the window
... so that it looks good for the payment app that is a website (on android)
... we have some ideas for that
... on desktop, we haven't shipped PR API yet but are close to doing so; showed at Google I/O
... we are having UX discussions about how to best present payment apps on desktop. What was mentioned in Chicago still stands I think - the payment app web page will be shown in a dialog window where the user would do the payment

IJ: Any word on desktop implementation availability?

rouslan: Look for it in stable release in Aug/Sep

IJ: Would be great to hear other plans

frank: We are happy to start experimentation as soon as there is support in the browser for web-based payment apps, which sounds like it is coming soon.

IJ: Any critical path features that we need to deal with to do experiments?

rouslan__: We need to automate web platform tests that involve user interactions
... Marcos has a proposal that involves a payment method specific to testing environment.
... that way we can test conformance of browsers.
... there seems to be consensus on this approach for PR API; perhaps we can do something similar for Payment Handler
... e.g., reserved payment method for a testing environment that could be used for automation testing.

IJ: Anything that could be usefully done to prepare for implementation testing?

Issue 129 Add .clear() to map-likes

IJ: I am in touch with people suggested by Marcos
... Ali Alabbas, Joshua Bell
... meet with them later today
... perhaps need an asyncmaplike

https://heycam.github.io/webidl/#idl-maplike

https://github.com/w3c/payment-handler/issues

IJ: Any ones people want to look at in particular?

Issue 157 - filtering and matching

https://github.com/w3c/payment-handler/issues/157

rouslan__: I think that what implementers want is to keep PR API shape as-is and use the algo text to define how exactly filtering happens.

IJ: It's one thing to say "the algo says this" and another to say "where does it really happen -UA or payment app?"

rouslan: I think jury is still out.
... weigh privacy v. capabilities of payment handlers
... I think that payment handler API will be more specific than just "filtering happens here".
... but ack rous

IJ: Are we prepared for a canMakePayment() type approach for payment apps (which we said "no" to previously)?

rouslan__: I think we are going to compare details...don't think we will call any functions
... having said that, we are still in the early stages of experimentation with Payment Handler API and payment app writers

IJ: Should people on this call talk to you about those experiments?

rouslan__: Please do

IJ: Please contact Rouslan to help address this issue through implementation experience.

Issue 128 examples

https://github.com/w3c/payment-handler/issues/128

(Maybe those are issues 2 and 3 now)

Issue 123 Share user data with Payment App

IJ: Any updates from implementers since the FTF?

rouslan__: We've not heard from other app providers besides Klarna on this use case.
... but leave open

Issue 74 - recommended payment apps

https://github.com/w3c/payment-handler/issues/74

https://github.com/w3c/payment-handler/issues/74#issuecomment-291548795

IJ: What are plans for browser-assisted support for recommendations of mobile payment apps?

rouslan: Have had some discussions but not implemented...
... we think that recommended payment apps could work better on web than native mobile
... loading a payment app would be useful to a user
... so we think that recommend payment apps might be useful ... the spec may not need to change to support it
... but we haven't really designed or implemented of this; just some ideas for now

Issue 117: Support for Abort() being delegated to Payment Handler

IJ: Has this come up?

rouslan__: We keep hearing this might be a requirement. We might be adding this to the native android payment app spec
... not sure yet, though
... I would not be opposed to adding an abort() event to payment handler...some nativepayment app developers have asked for this

alyver: Beyond a certain point, abort may not always be successful. is the expectation that payment apps be able to handle abort() or do a refund for example?

rouslan__: I think the expectation is that the event is fired into the payment app if the merchant site requests an abort (e.g., timeout or no more tickets available)
... so payment app could do different things depending on the user's activity...e.g., if user is just starting to type info
... but if payment app is processing or has completed transaction...hten the payment app can signal that the abort failed.
... this gives the merchant site some idea of whether their abort request went through.

IJ: +1 to basically saying this is a signal, rather than having conformance requirements specifically for payment apps
... Should we wait for rouslan mobile experience before spec'ing out?

<alyver> +1 to it being useful

https://github.com/w3c/payment-handler/issues/117#issuecomment-291522464

Next Meeting

IJ: Rouslan, anything we can do to help you out?

Rouslan: Await further updates!

<rouslan__> +1

<alyver> +1

Proposed two weeks - 6 June

Next meeting: 6 June