Payment Apps Task Force

07 Mar 2017


See also: IRC log


Ian, Jason, adamR, AdrianHB, Mathieu, rouslan, ConorhWP, Max, Ken


Updating the spec


* Change the title (Payment Handler API)

* Update the model description per the Proposal

* Move explanatory information to an appendix

* Add code samples


* AdamR to flesh out his proposal per 28 Feb discussion


adamR: I wasn't able to update the proposal last week due to IETF deadlines; that's likely to continue to next week.
... so that's ok if you move a lot of things around during that period.
... part of what I wanted to do with my edits is add in examples.
... from marcos' document
... I already borrowed IDL...will include exmaples
... I thank we will have incorporated most of what Marcos has provided...I also think that Marcos created that document to demonstrate some code and my understanding is that once I've taken the info into account, he won't develop that document further
... When you are done with the big structural moves, if you can tag me let me know.

issue 91

Discussion of AHB's proposal:


is on the WG agenda this week:


IJ: Anyone want to add to the GitHub issue in favor of sharing line items?

AdrianHB: Line items in payment request are not the things that you buy
... they are typically things like subtotal, tax, total
... so if a payment app wants full details about what is being purchased,
... that can be a payment method specific piece of data.
... I think that that's where we are headed on that issue.

<Zakim> adamR, you wanted to ask Adrian a clarifying question

adamR: Adrian, regarding the method you described passing through does that that imply redundancy of information passed through the top level?

AdrianHB: My proposal is that there's a flag in PR API...and if you want to pass line items to payment apps you would set the flag.
... zach's point is that we don't expect merchants to use line items to list products
... if there are no use cases for getting "total", "tax" etc. then we can drop the proposal, otherwise if there are use cases (which Klarna's is not an example of), then the proposal can stand

IJ: Privacy issue goes away if the line items are just used for tax and total information

AdrianHB: The breakdown was to show a change in total based on user actoins

AdamR: I understand the use case and the google use case, but I suspect that developers will use the line items for other purposes.
... The number of web developers who read specs for good practice is close to zero

AdrianHB: I think the only way we will address the concern from AdamR is to change the API to be less flexible.
... I also think that Google limits the number of things you can send through the API
... due to UI consideratinos
... the spec should not hard-code a limit, but I believe there is one

rouslan: We don't currently enforce a limit (we use scroll bars)
... we'll probably send a PR on the spec soon that says you can provide something like 50 shipping options and 50 line items
... for security reasons

Rename the spec

<AdrianHB> If the intent is explicitly to not show shopping cart items then we should limit to 5

Proposal: Payment Handler API for the title

<AdrianHB> +1

<adamR> +1

<rouslan> +1

<jnormore> +1

Pascal's code


IJ: Has anybody had a look? What is relationship to Marcos' code?

AdamR: This is input to drive the API; the examples in the spec are meant to explain the API.

AdrianHB: One thing immediately useful from the code samples is that if you don't have time to read the whole spec,
... I see the first example and say "Is our intent to get permission by calling options.set?" Is it implicit? Or do we want an explicit function to get permissions?

adamR: I think we had an open issue on this.




AdrianHB: that example shows an explicit permissions call
... asking for 'payments' permission

AdamR: yes, this can be incorporated.

AdrianHB: I suggest we respond on the issue and try to get a general approach

AdamR: I am confident in Marcos and Jake here
... if we want further validation, let's find another person who is familiar with how web apps ask for permissions.

IJ: Is PaymentManager more clearly captured in the new text (from Adam)?

AdamR: there is a page on the payment app's web site that installs the payment app...that's not the service worker
... there is a thing on the service worker registration that is where we are setting things like supported payment methods
... but I think this is something else (on window)

filtering update

- Filtering mostly for w3c (abstraction) specs

AdrianHB: I disagree with that.
... the whole point of the filtering is that new payment methods can be introduced that have their own unique filters

<adamR> I said it last Thursday, but for the record, I disagree with Zach’s characterizatin here. If Chrome wants to do things that way, it’s fine, but I don’t think it should be required of all browsers.

<adamR> And this is particularly distressing when you consider, e.g., Safari, which comes out every 18 to 24 months.

<AdrianHB> ian: we want to be able to support filters for 3rd party payment apps

- payment handler api needs a stnadard way to provide capability information


For each paymentMethod in request.[[serializedMethodData]]:

Consult the appropriate payment apps to see if they support any of the payment method identifiers given by the first element of the paymentMethod tuple, passing along the data string given by the second element of the tuple in order to help them determine their support.

IJ: I proposed a more neutral framing to make it possible that browsers do the matching

AdrianHB: Let's get a resolution rather than a neutral stance

IJ: We got again into the security issues

I distinguished two things:

* Unconstrained string syntax

* Unlimited list length

<AdrianHB> IJ: Nick-TR pointed out that generic string matching would also resolve an issue around the ability of networks to get included on the hard-coded network list


1) We need to clarify the process for accepting new identifiers. (e.g.,a simple anti-spam verificatino)

2) A disclaimer that appearance in the list is not a guarantee of interoperability across browsers.

<AdrianHB> Sounds like this boils down to: Is there a strong enough case for a hard coded list (enumeration) or can we have a more flexible (but still constrained) list?

<AdrianHB> For the record I would be a big +1 to doing away with the networks list if we can

IJ: Can we basically say (1) here's how you provide capabilities from a payment app and (2) here's in PR Api where that's taken into account, and leave it at that?

adamR: I'm not sure I followed that...we need to think about these things from the POV of browsers that are released less frequently, such as every 18 months.
... so a network list that is only infrequently updated in a browser is a problem.
... I also would like there to be an authoritative list of network strings (to avoid e.g., amex v. americanexpress confusion).

<AdrianHB> To be clear, having a list that helps avoid confusion and conflicts is fine but that's different to a list that has a gatekeeper to be added

AdamR: We also don't want duplicates
... so ok with WG having lightweight approval process and indicating browser support is independent

<AdrianHB> -1 to "lightweight approval process"

AdrianHB: I don't think there needs to be "approval". I think you can avoid duplicates without an approval process.
... an approval process is dangerous

<ConorhWP> I won't interrupt - I need to drop off now. Thanks all, goodbye.

next meeting

14 March

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/03/07 17:09:48 $