• Editor update
• Payment Request API
  • Review of updated pull request related to Detecting Payment Method Availability. We would like to make a decision to merge the updated request at this meeting.
  • Push payments next steps
    • Summary of proposal
    • Proposal for paymentRequestID
    • Updated payment method good practice on reconciliation
  • Question from Roy: How to handle encryption for tokenization spec.
• Basic Card
  • Proposal to Manage Card Network Identifiers Separate from Basic Card Spec
  • Behavior when method-specific data is invalid #20
• Payment Method Identifier Specification
  • Updated PMI specification based on recent discussions
  • Questions from AdrianHB for discussion including Payment app identifier to manifest filename mapping
• Manifest Specification
  • See Manifest Proposal, by Max based on Zach initial work. See also Ian's pull request.
  • Discussion about how to address the payment method manifest file (e.g., link header or hard-coded path; or make JSON the data you get back for the PMI and that includes link to human documentation).
  • Any optimization desirable for the case where someone wants to say "I have a URL for my payment method and want to allow any payment app to implement it; but don't want to host a manifest file."
• Meetings
  • Next: 15 December, then 5 Jan 2017
  • Possible FTF meeting update (March 2017)
  • Ian is writing a proposal about WPWG teleconferences
• Autopublishing

Coming soon:

• Issue 311. We discussed on 1 December 2016 and indicated that more GitHub discussion of a transition plan was in order. Any updates?
• Deployment
  • Who would like to work with Nick and Ian on updated communications around the benefits (to merchants (and merchant service providers)) of the payments APIs?
  • Samsung colleagues and Ian have been chatting about organizing business-level support for merchant adoption; Ian is preparing to reach out to WPWG member business/PR for unified outreach effort and welcomes expressions of interest.
• Updated publications milestones
• Recently raised issues
  • Issue 330: Making this API work with HTML Forms

Notes on manifest file addressing

• Hard-coded URL
  • Pro: Simple configuration
  • Con: Limits server to one manifest file per payment method. Squats URI space.
• HTTP Link header (used in conjunction with caching)
  • Pro: Greater flexibility in naming, serving multiple resources.
• Content negotiation
  • Pro: One URL
  • Con: May be challenging to configure; support may not be as widespread as we'd like (@@to be fleshed out@@).
• Serve JSON for PMI; link to human readable content from there
  • Pro: Optimizes for the information we know today we want to associate with a PMI. Still allows follow your nose to get more information.
  • Con: People get back data instead of human readable info by default so less friendly.