Skip to content

Agenda 20160428

Adrian Hope-Bailie edited this page Apr 28, 2016 · 11 revisions
  • 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?
Clone this wiki locally