Agenda 20160428

• Priorities (proposed, in order)

  • Extensibility (and specifically payment app registration and architecture for browser-payment-api)
  • Moving published working drafts forward and supporting implementations
  • Widening the scope of our published work (HTTP API, additional payment methods)

• Face-to-face meeting update

  • Original tentative workshop dates: 29-30 June clashed with W3C blockchain workshop
  • Looking for non-conflicting FTF meeting in July in London
  • Possible dates are:
    • Wednesday 13th July and Thursday 14th July
    • Monday 18th July and Tuesday 19th July
    • Tuesday 19th July and Wednesday 20th July
  • Questionnaire at https://www.w3.org/2002/09/wbs/83744/F2F_London/

• Proposals (AHB) - marked with 28th April Milestone in Github

  • Complete()

    • PR #161 Change from boolean to enum and update descriptions
    • PR #153 Drop parameter
    • Issue #129 complete does not talk to the Payment App
    • Issue #122 Consider revising the design of complete()
    • Issue #17 complete() should take a string argument not boolean

  • How total amount is passed in

    • PR #158 Move out of items which are now displayItems. Leave as PaymentItem.
    • PR #133 Move to same parameter as payment method data. Expressed as array of CurrencyAmount to support multiple-amounts per currency
    • Issue #18 Constructor should not include "total" in list of items
    • Issue #3 Should it be possible to provide amounts in more than one currency
    • Issue #4 Should it be possible to vary amounts depending on payment method

  • Merging of supported methods and method data

    • PR #162 Merge list of payment methods with payment method data
    • PR #133 Merge list of payment methods with payment method data and requested amount. Move items and shippingOptions to options
    • Issue #15 Combine API parameters into a single request object + options
    • Issue #48 Should list of accepted payment methods be strings or objects?

  • Requesting user data

    • PR #65 Thread includes a proposal and multiple-counter proposals
    • Issue #1 Should the merchant be able to request your email and recipient phone number?
    • Issue #27 Should API support billing address capture (for tax computation)?

• Issues (some implicit in proposal discussion)

  • Issue #16 Use navigator.payments singleton, factory method, or PaymentRequest constructor
  • Issue #19 Should the API handle pre-auth, recurring payments, and similar scenarios
  • Issue #119 Support for negative amounts
  • Issue #2 Should the Payment Request API only be available in a top-level browsing context?