Agenda 20161201

• Payment Request API
  • Issue 311: Send HTMLIFrameElement.allowPaymentRequest to HTML spec. Should we use .allowPaymentRequest and anticipate migration to Feature Policy? See suggestions on how to specify this.
  • Status of pull request about Detecting Payment Method Availability
    • Link to pull request.
    • AdrianB: 'can live with it without "active" check'
  • 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.
  • Question: Hard code path to manifest or something else (e.g., content negotiation).
  • 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
  • Upcoming calls: 8 Dec, 15 Dec. No calls 22 and 29 December. Next call 5 Jan 2017.
  • Ian is writing a proposal about WPWG teleconferences
  • FTF update

Coming soon:

• 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