public-payments-wg@w3.org from February 2016 by author

Ade Bateman

• [paymentrequest] At the time complete() is called, your ability to say success (true) or failure (false) may depend on the payment method (#67) (Wednesday, 24 February)
• Re: [paymentrequest] Write-up initial proposal for payment app registration spec (#27) (Tuesday, 23 February)
• Re: [paymentrequest] Write-up initial proposal for payment app registration spec (#27) (Tuesday, 23 February)
• Re: [paymentrequest] Write-up initial proposal for card payment method spec (#31) (Tuesday, 23 February)
• Re: [paymentrequest] Write-up initial proposal for card payment method spec (#31) (Tuesday, 23 February)
• Re: [paymentrequest] Add link to registration explainer to index page. (#65) (Tuesday, 23 February)
• [paymentrequest] Add link to registration explainer to index page. (#65) (Tuesday, 23 February)
• Re: [paymentrequest] Add registration explainer (#64) (Tuesday, 23 February)
• Re: [paymentrequest] Add registration explainer (#64) (Tuesday, 23 February)
• Re: [paymentrequest] Error types used are weird and excessive (#56) (Tuesday, 23 February)
• Re: [paymentrequest] "JSON object" is confusing; consider "JSON-serializable object" (#59) (Tuesday, 23 February)
• Re: [paymentrequest] Error types used are weird and excessive (#56) (Tuesday, 23 February)
• Re: [paymentrequest] Algorithm for complete(success) does not use its argument (#55) (Tuesday, 23 February)
• Re: [paymentrequest] Algorithm for complete(success) does not use its argument (#55) (Tuesday, 23 February)
• Re: [paymentrequest] "JSON object" is confusing; consider "JSON-serializable object" (#59) (Tuesday, 23 February)
• Re: [paymentrequest] Don't have a <dfn> for "user agent" (#60) (Tuesday, 23 February)
• Re: [paymentrequest] Don't have a <dfn> for "user agent" (#60) (Tuesday, 23 February)
• [paymentrequest] Add skeleton of basic card spec and tidy-up API spec (#63) (Monday, 22 February)
• Re: [paymentrequest] Add rationale and update document locations (#62) (Friday, 19 February)
• Re: [paymentrequest] Add rationale and update document locations (#62) (Friday, 19 February)
• Re: [paymentrequest] Add rationale and update document locations (#62) (Friday, 19 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Tuesday, 16 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Monday, 15 February)
• [paymentrequest] Tidy-up per discussion (#52) (Saturday, 13 February)
• Re: [paymentrequest] Fix spec nits based on implementation experience. (#51) (Friday, 12 February)
• Re: [paymentrequest] Fix spec nits based on implementation experience. (#51) (Friday, 12 February)
• [paymentrequest] Fix spec nits based on implementation experience. (#51) (Friday, 12 February)
• Re: [paymentrequest] Change the PaymentRequestUpdateEvent model to better match FetchEvent (#50) (Friday, 12 February)
• Re: [paymentrequest] Change the PaymentRequestUpdateEvent model to better match FetchEvent (#50) (Friday, 12 February)
• Re: [paymentrequest] Change the PaymentRequestUpdateEvent model to better match FetchEvent (#50) (Friday, 12 February)
• Re: [paymentrequest] Change the PaymentRequestUpdateEvent model to better match FetchEvent (#50) (Friday, 12 February)
• Re: [paymentrequest] Change the PaymentRequestUpdateEvent model to better match FetchEvent (#50) (Friday, 12 February)
• [paymentrequest] Change the PaymentRequestUpdateEvent model to better match FetchEvent (#50) (Friday, 12 February)
• Re: [paymentrequest] Clarify that decimal separator is optional to match regex. (#49) (Friday, 12 February)
• [paymentrequest] Clarify that decimal separator is optional to match regex. (#49) (Friday, 12 February)
• Re: [paymentrequest] Shipping: should merchant supply supported destinations (#2) (Thursday, 11 February)
• Re: [paymentrequest] Shipping: should merchant supply supported destinations (#2) (Thursday, 11 February)
• Re: [paymentrequest] Need a "really closed" event (#45) (Thursday, 11 February)
• Re: [paymentrequest] Need a "really closed" event (#45) (Thursday, 11 February)
• Re: [paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46) (Thursday, 11 February)
• Re: [paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46) (Thursday, 11 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Thursday, 11 February)
• Re: [webpayments] How are third-party native wallets integrated? (#42) (Thursday, 11 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Thursday, 11 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Thursday, 11 February)
• Re: [webpayments] How do we protect certian data in the messages from certain parties in the flow as the use case requires? (#78) (Thursday, 11 February)
• Re: [webpayments] Should the payment request support multiple pricing options? (#79) (Thursday, 11 February)
• Re: [webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76) (Thursday, 11 February)
• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Thursday, 11 February)
• [paymentrequest] Proposal to move the complete() method to the PaymentResponse interface (#48) (Thursday, 11 February)
• Re: [paymentrequest] Spec correctness updates based on review feedback (#47) (Thursday, 11 February)
• Re: [paymentrequest] Spec correctness updates based on review feedback (#47) (Thursday, 11 February)
• [paymentrequest] Spec correctness updates based on review feedback (#47) (Thursday, 11 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Thursday, 4 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Thursday, 4 February)
• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Thursday, 4 February)

Adrian Hope-Bailie

• Re: [webpayments] Repo my apps (#103) (Wednesday, 24 February)
• Re: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66) (Wednesday, 24 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Sunday, 21 February)
• Re: Dinner at Croqueta on Sunday at 7pm in San Francisco (Saturday, 20 February)
• Re: The Open Banking Standard (HTTP API) (Thursday, 18 February)
• Re: Sanity check on API using flows from Flows Task Force (Wednesday, 17 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Tuesday, 16 February)
• Re: [webpayments] Fix typos (#91) (Tuesday, 16 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Tuesday, 16 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Monday, 15 February)
• Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60) (Monday, 15 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Monday, 15 February)
• Re: [webpayments] How can the API support enrollment (future payment) use cases? (#65) (Monday, 15 February)
• Re: [webpayments] How do we prevent keyboard hooking during payment? (#90) (Monday, 15 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Monday, 15 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Monday, 15 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Monday, 15 February)
• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Monday, 15 February)
• Re: ACTION STRONGLY ENCOURAGED: Flows ready for wider review (Monday, 15 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Thursday, 11 February)
• Re: [paymentrequest] No mention of non-decimal currencies (#40) (Thursday, 11 February)
• Re: [webpayments] Should we expose status change events in the browser API? (#41) (Thursday, 11 February)
• Re: [webpayments] PROPOSAL: Include an extensibility section in the browser API spec with an ISSUE marker indicating WIP. (#83) (Thursday, 11 February)
• Re: [webpayments] PROPOSAL: Include an extensibility section in the browser API spec with an ISSUE marker indicating WIP. (#83) (Thursday, 11 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Thursday, 11 February)
• Re: [webpayments] PROPOSAL: Include an extensibility section in the browser API spec with an ISSUE marker indicating WIP. (#83) (Thursday, 11 February)
• Re: [webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76) (Thursday, 11 February)
• Re: [webpayments] Should the payment request support multiple pricing options? (#79) (Thursday, 11 February)
• Re: [webpayments] How do we protect certian data in the messages from certain parties in the flow as the use case requires? (#78) (Thursday, 11 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Thursday, 11 February)
• Re: [webpayments] How are third-party native wallets integrated? (#42) (Thursday, 11 February)
• Re: Checkout API spec published (Thursday, 11 February)
• Re: PROPOSAL regarding JSON-LD material (Thursday, 11 February)
• [webpayments] PROPOSAL: Include an extensibility section in the browser API spec with an ISSUE marker indicating WIP. (#83) (Thursday, 11 February)
• Re: Checkout API spec published (Thursday, 11 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Thursday, 11 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Thursday, 11 February)
• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Thursday, 11 February)
• Re: Checkout API spec published (Tuesday, 9 February)
• Re: Checkout API spec published (Monday, 8 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Wednesday, 3 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Wednesday, 3 February)
• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] Should the payment request support multiple pricing options? (#79) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] Should a payment method identifier (URL) resolve to a machine readable resource that describes the payment method? (#30) (Tuesday, 2 February)
• Re: [paymentrequest] Combine API parameters into a single request object + options (#41) (Tuesday, 2 February)
• [webpayments] Should the payment request support multiple pricing options? (#79) (Tuesday, 2 February)
• Re: [paymentrequest] Combine API parameters into a single request object + options (#41) (Tuesday, 2 February)
• Re: [webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76) (Monday, 1 February)
• Registration for ILP Workshop is OPEN (Monday, 1 February)
• Re: [webpayments] How are cloud-based payment apps supported? (#16) (Monday, 1 February)
• Re: [webpayments] How are cloud-based payment apps supported? (#16) (Monday, 1 February)
• Re: [webpayments] How are payment apps shared between different browser brands? (#15) (Monday, 1 February)
• Re: Concerns around Web Payments HTTP API de-prioritization (Monday, 1 February)
• Re: [webpayments] How are payment apps shared between different browser brands? (#15) (Monday, 1 February)
• Re: [webpayments] How are third-party native wallets integrated? (#42) (Monday, 1 February)
• Re: [webpayments] Should we have separate specifications for payment and registration of payment apps? (#26) (Monday, 1 February)
• Re: [webpayments] How are payment apps registered? (#14) (Monday, 1 February)
• Re: [webpayments] How are cloud-based payment apps supported? (#16) (Monday, 1 February)
• [webpayments] How do we protect certian data in the messages from certain parties in the flow as the use case requires? (#78) (Monday, 1 February)
• Re: [webpayments] Is tracking payment request state necessary? (#35) (Monday, 1 February)
• Re: [webpayments] What gets registered - apps, wallets, or payment instruments? (#28) (Monday, 1 February)
• Re: [webpayments] What gets registered - apps, wallets, or payment instruments? (#28) (Monday, 1 February)
• Re: [webpayments] How are third-party native wallets integrated? (#42) (Monday, 1 February)
• [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Monday, 1 February)
• Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Monday, 1 February)
• Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Monday, 1 February)
• Re: [webpayments] Expression of monetary amounts (#40) (Monday, 1 February)
• Re: [webpayments] Expression of monetary amounts (#40) (Monday, 1 February)
• Re: [webpayments] Some amendmends (#75) (Monday, 1 February)
• Re: [webpayments] Some amendmends (#75) (Monday, 1 February)
• Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60) (Monday, 1 February)
• Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57) (Monday, 1 February)
• Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57) (Monday, 1 February)

Alessio Basso

• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Thursday, 4 February)
• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Thursday, 4 February)
• Re: [webpayments] Should the payment request support multiple pricing options? (#79) (Thursday, 4 February)
• Re: [webpayments] Should the payment request support multiple pricing options? (#79) (Tuesday, 2 February)
• Re: [paymentrequest] Combine API parameters into a single request object + options (#41) (Tuesday, 2 February)
• Re: [paymentrequest] Combine API parameters into a single request object + options (#41) (Tuesday, 2 February)
• Re: [webpayments] Some amendmends (#75) (Monday, 1 February)

Anders Rundgren

• JSON signatures for "node.js" (Monday, 29 February)
• JSON Signatures for Financial Messaging (Sunday, 21 February)

Dan Brickley

• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)

Daniel Torres

• [webpayments] Repo my apps (#103) (Sunday, 21 February)

Dave Longley

• Re: [paymentrequest] Constructor should not include "total" in list of items (#68) (Thursday, 25 February)
• Re: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66) (Thursday, 25 February)
• Re: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66) (Wednesday, 24 February)
• Re: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66) (Wednesday, 24 February)
• Re: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66) (Wednesday, 24 February)
• Re: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66) (Wednesday, 24 February)
• Re: [paymentrequest] Write-up proposal for shipping address fields (#28) (Monday, 22 February)
• Re: [paymentrequest] Write-up proposal for shipping address fields (#28) (Monday, 22 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Sunday, 21 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Sunday, 21 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Thursday, 18 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Thursday, 18 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Thursday, 18 February)
• Re: [webpayments] Transition and Adoption (#94) (Thursday, 18 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Tuesday, 16 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Tuesday, 16 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Tuesday, 16 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Friday, 12 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Friday, 12 February)
• Re: [webpayments] How can the API support enrollment (future payment) use cases? (#65) (Friday, 12 February)
• Re: [webpayments] Should we expose status change events in the browser API? (#41) (Friday, 12 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Friday, 12 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Friday, 12 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Friday, 12 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Friday, 12 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Thursday, 11 February)
• Re: [webpayments] Should the payment request support multiple pricing options? (#79) (Thursday, 11 February)
• Re: Checkout API spec published (Thursday, 11 February)
• Re: PROPOSAL regarding JSON-LD material (Thursday, 11 February)
• Re: Checkout API spec published (Thursday, 11 February)
• Re: Checkout API (Tuesday, 9 February)
• Re: Checkout API spec published (Tuesday, 9 February)
• Re: Checkout API spec published (Tuesday, 9 February)
• Re: Checkout API spec published (Tuesday, 9 February)
• Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39) (Thursday, 4 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Thursday, 4 February)
• Checkout API (Thursday, 4 February)
• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Wednesday, 3 February)
• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] Should the payment request support multiple pricing options? (#79) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] Should the payment request support multiple pricing options? (#79) (Tuesday, 2 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Monday, 1 February)
• Re: [webpayments] How are payment apps shared between different browser brands? (#15) (Monday, 1 February)
• Re: [webpayments] How are cloud-based payment apps supported? (#16) (Monday, 1 February)

dezell

• Re: [paymentrequest] Constructor should not include "total" in list of items (#68) (Thursday, 25 February)
• Re: [webpayments] How can the API support enrollment (future payment) use cases? (#65) (Friday, 12 February)

Domenic Denicola

• [paymentrequest] State in each class's definition which internal slots it has (#61) (Thursday, 18 February)
• [paymentrequest] Don't have a <dfn> for "user agent" (#60) (Thursday, 18 February)
• [paymentrequest] "JSON object" is confusing; consider "JSON-serializable object" (#59) (Thursday, 18 February)
• [paymentrequest] Use [SecureContext] instead of manually checking inside the PaymentRequest constructor (#58) (Thursday, 18 February)
• [paymentrequest] Spec references are all pretty outdated (#57) (Thursday, 18 February)
• [paymentrequest] Error types used are weird and excessive (#56) (Thursday, 18 February)
• [paymentrequest] Algorithm for complete(success) does not use its argument (#55) (Thursday, 18 February)
• [paymentrequest] boolean arguments are an anti-pattern; consider separate methods for complete() (#54) (Thursday, 18 February)
• [paymentrequest] Example 1 typo: payment.complete(true) should be paymentResponse.complete(true) (#53) (Thursday, 18 February)

Doug Schepers

• Re: [Minutes] 23-24 February face-to-face meeting (Monday, 29 February)
• Re: Dinner at Croqueta on Sunday at 7pm in San Francisco (Sunday, 21 February)
• Re: Checkout API spec published (Thursday, 11 February)

Erik Anderson

• Re: [webpayments] Synonym Mapping from Web Environment Terminology to ISO 20022 Terminonogy (#95) (Wednesday, 17 February)
• Re: [webpayments] ISO20022 terminology adoption (#93) (Wednesday, 17 February)
• Re: [webpayments] Synonym Mapping from Web Environment Terminology to ISO 20022 Terminonogy (#95) (Wednesday, 17 February)
• [webpayments] Synonym Mapping from Web Environment Terminology to ISO 20022 Terminonogy (#95) (Wednesday, 17 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76) (Monday, 1 February)

fredMeignien

• [webpayments] PISP under PSD2_SCT flows_Shopper PISP (#99) (Wednesday, 17 February)
• [webpayments] PISP under PSD2_SCT flows_Merchant PISP.pml (#97) (Wednesday, 17 February)
• Re: [webpayments] Synonym Mapping from Web Environment Terminology to ISO 20022 Terminonogy (#95) (Wednesday, 17 February)
• Re: [webpayments] ISO20022 terminology adoption (#93) (Wednesday, 17 February)
• Re: [webpayments] ISO20022 terminology adoption (#93) (Wednesday, 17 February)
• Re: [webpayments] How can the API support enrollment (future payment) use cases? (#65) (Friday, 12 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Friday, 12 February)
• [webpayments] PSD2 about Payment Initiation 4 Feb 2016 (#82) (Thursday, 4 February)

Frédéric Meignien

• Re: The Open Banking Standard (HTTP API) (Thursday, 18 February)
• Re: The Open Banking Standard (HTTP API) (Thursday, 18 February)
• Re: Sanity check on API using flows from Flows Task Force (Wednesday, 17 February)
• Re: Sanity check on API using flows from Flows Task Force (Wednesday, 17 February)
• Re: Sanity check on API using flows from Flows Task Force (Wednesday, 17 February)
• Re: Sanity check on API using flows from Flows Task Force (Monday, 15 February)

Gregory Estrade

• Re: Dinner at Croqueta on Sunday at 7pm in San Francisco (Saturday, 20 February)

haavardmolland

• Re: [webpayments] How do we protect certian data in the messages from certain parties in the flow as the use case requires? (#78) (Tuesday, 2 February)
• Re: [webpayments] How are third-party native wallets integrated? (#42) (Monday, 1 February)
• Re: [webpayments] How are third-party native wallets integrated? (#42) (Monday, 1 February)

Håvard Molland

• Re: [webpayments] How are third-party native wallets integrated? (#42) (Friday, 19 February)
• Re: [webpayments] How are third-party native wallets integrated? (#42) (Thursday, 18 February)

Ian Jacobs

• Under W3C Member Review: Hardware Security Working Group Charter (until 1 April) (Monday, 29 February)
• Comments on Payment Request API (Friday, 26 February)
• Re: [Minutes] 23-24 February face-to-face meeting (Friday, 26 February)
• Re: [Minutes] 23-24 February face-to-face meeting (Friday, 26 February)
• [Minutes] 23-24 February face-to-face meeting (Thursday, 25 February)
• Re: Dinner at Croqueta on Sunday at 7pm in San Francisco (Saturday, 20 February)
• Re: Draft requirements for discussion at the WPWG FTF meeting (Friday, 19 February)
• Draft requirements for discussion at the WPWG FTF meeting (Friday, 19 February)
• [Minutes] 18 Feb WPWG call (Thursday, 18 February)
• Re: The Open Banking Standard (HTTP API) (Thursday, 18 February)
• Re: The Open Banking Standard (HTTP API) (Thursday, 18 February)
• Question about I18N comment [Was: Checkout API spec published] (Friday, 12 February)
• Comments on MasterPass flow (Thursday, 11 February)
• Re: PROPOSAL regarding JSON-LD material (Thursday, 11 February)
• Re: PROPOSAL regarding JSON-LD material (Thursday, 11 February)
• Comments on 3DS Flow (Thursday, 11 February)
• Re: PROPOSAL regarding JSON-LD material (Thursday, 11 February)
• Re: PROPOSAL regarding JSON-LD material (Thursday, 11 February)
• Re: PROPOSAL regarding JSON-LD material (Wednesday, 10 February)
• Re: PROPOSAL regarding JSON-LD material (Wednesday, 10 February)
• Re: PROPOSAL regarding JSON-LD material (Tuesday, 9 February)
• Re: Checkout API spec published (Tuesday, 9 February)
• PROPOSAL regarding JSON-LD material (Tuesday, 9 February)
• Re: Checkout API spec published (Tuesday, 9 February)
• Re: Checkout API spec published (Tuesday, 9 February)
• Re: Checkout API spec published (Tuesday, 9 February)
• Re: Checkout API spec published (Tuesday, 9 February)
• Re: Checkout API spec published (Monday, 8 February)
• Web Authentication Working Group Launched (Monday, 8 February)
• [Minutes] 4 Feb 2016 WPWG teleconference (Thursday, 4 February)

ianbjacobs

• Re: [paymentrequest] At the time complete() is called, your ability to say success (true) or failure (false) may depend on the payment method (#67) (Friday, 26 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Monday, 22 February)
• Re: [paymentrequest] Add rationale and update document locations (#62) (Friday, 19 February)
• Re: [webpayments] Review: UPI - a method and standard that went BETA in India (#100) (Thursday, 18 February)
• Re: [webpayments] How do we prevent keyboard hooking during payment? (#90) (Thursday, 18 February)
• Re: [webpayments] Multilingual Support for human-readable labels (#84) (Thursday, 18 February)
• Re: [webpayments] Security and Privacy Self-Review (#61) (Tuesday, 16 February)
• Re: [webpayments] How do we prevent keyboard hooking during payment? (#90) (Tuesday, 16 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Monday, 15 February)
• [webpayments] Multilingual Support for human-readable labels (#84) (Friday, 12 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Friday, 12 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Friday, 12 February)
• [web-payments-browser-api] Use of "MUST" in sentence might cause confusion (#6) (Thursday, 11 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Thursday, 11 February)
• Re: [webpayments] PROPOSAL: Include an extensibility section in the browser API spec with an ISSUE marker indicating WIP. (#83) (Thursday, 11 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Wednesday, 10 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Wednesday, 10 February)
• Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60) (Wednesday, 10 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Tuesday, 9 February)
• Re: [webpayments] How do we protect certian data in the messages from certain parties in the flow as the use case requires? (#78) (Thursday, 4 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How are cloud-based payment apps supported? (#16) (Monday, 1 February)

Jake Archibald

• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Tuesday, 16 February)
• Re: [paymentrequest] Change the PaymentRequestUpdateEvent model to better match FetchEvent (#50) (Friday, 12 February)
• Re: [paymentrequest] Change the PaymentRequestUpdateEvent model to better match FetchEvent (#50) (Friday, 12 February)
• Re: [paymentrequest] Change the PaymentRequestUpdateEvent model to better match FetchEvent (#50) (Friday, 12 February)
• Re: [webpayments] Should we expose status change events in the browser API? (#41) (Friday, 12 February)

Jeff Burdges

• Re: [paymentrequest] Write-up proposal for shipping address fields (#28) (Monday, 29 February)
• Re: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66) (Wednesday, 24 February)
• Re: [webpayments] Taler flows (#106) (Wednesday, 24 February)
• Re: [webpayments] Taler flows (#106) (Tuesday, 23 February)
• [webpayments] Taler flows (#106) (Tuesday, 23 February)

Joerg.Heuer@telekom.de

• RE: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66) (Wednesday, 24 February)
• RE: Dinner at Croqueta on Sunday at 7pm in San Francisco (Sunday, 21 February)
• RE: Dinner at Croqueta on Sunday at 7pm in San Francisco (Sunday, 21 February)

Katie Haritos-Shea

• RE: Dinner at Croqueta on Sunday at 7pm in San Francisco (Sunday, 21 February)
• Re: CHANGE OF VENUE: Sunday dinner now at La Mar Cebichería Peruana at 7:30pm (Sunday, 21 February)
• Re: Dinner at Croqueta on Sunday at 7pm in San Francisco (Saturday, 20 February)

Laurent Castillo

• Re: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66) (Wednesday, 24 February)
• Re: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66) (Wednesday, 24 February)
• [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66) (Tuesday, 23 February)

Madhu

• Re: [webpayments] Review: UPI - a method and standard that went BETA in India (#100) (Thursday, 18 February)
• [webpayments] Review: UPI - a method and standard that went BETA in India (#100) (Thursday, 18 February)

Manu Sporny

• Re: [Minutes] 23-24 February face-to-face meeting (Friday, 26 February)
• Re: [Minutes] 23-24 February face-to-face meeting (Friday, 26 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Monday, 22 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Monday, 22 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Monday, 22 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Sunday, 21 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Sunday, 21 February)
• CHANGE OF VENUE: Sunday dinner now at La Mar Cebichería Peruana at 7:30pm (Saturday, 20 February)
• Dinner at Croqueta on Sunday at 7pm in San Francisco (Saturday, 20 February)
• Re: [paymentrequest] Add rationale and update document locations (#62) (Friday, 19 February)
• Re: Draft requirements for discussion at the WPWG FTF meeting (Friday, 19 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Thursday, 18 February)
• The Open Banking Standard (HTTP API) (Thursday, 18 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Monday, 15 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Monday, 15 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Monday, 15 February)
• [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Monday, 15 February)
• Re: ACTION STRONGLY ENCOURAGED: Flows ready for wider review (Monday, 15 February)
• Re: ACTION STRONGLY ENCOURAGED: Flows ready for wider review (Sunday, 14 February)
• Re: Sanity check on API using flows from Flows Task Force (Sunday, 14 February)
• Sanity check on API using flows from Flows Task Force (Friday, 12 February)
• Re: Checkout API spec published (Thursday, 11 February)
• Re: [web-payments-browser-api] Use of "MUST" in sentence might cause confusion (#6) (Thursday, 11 February)
• Re: [webpayments] PROPOSAL: Include an extensibility section in the browser API spec with an ISSUE marker indicating WIP. (#83) (Thursday, 11 February)
• Re: PROPOSAL regarding JSON-LD material (Thursday, 11 February)
• Re: PROPOSAL regarding JSON-LD material (Thursday, 11 February)
• Re: [webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76) (Thursday, 11 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Thursday, 11 February)
• Re: PROPOSAL regarding JSON-LD material (Thursday, 11 February)
• Re: PROPOSAL regarding JSON-LD material (Thursday, 11 February)
• Re: PROPOSAL regarding JSON-LD material (Wednesday, 10 February)
• Re: PROPOSAL regarding JSON-LD material (Wednesday, 10 February)
• Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60) (Wednesday, 10 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Wednesday, 10 February)
• Re: Checkout API spec published (Tuesday, 9 February)
• Re: Checkout API spec published (Tuesday, 9 February)
• Re: Checkout API spec published (Monday, 8 February)
• Checkout API spec published (Monday, 8 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Sunday, 7 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Saturday, 6 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Saturday, 6 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Saturday, 6 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Saturday, 6 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Thursday, 4 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 3 February)
• Re: [webpayments] Should the payment request support multiple pricing options? (#79) (Wednesday, 3 February)
• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)

Matt Saxon

• RE: Sanity check on API using flows from Flows Task Force (Wednesday, 17 February)
• RE: Sanity check on API using flows from Flows Task Force (Wednesday, 17 February)
• RE: Sanity check on API using flows from Flows Task Force (Tuesday, 16 February)
• Re: ACTION STRONGLY ENCOURAGED: Flows ready for wider review (Monday, 15 February)
• Re: ACTION STRONGLY ENCOURAGED: Flows ready for wider review (Sunday, 14 February)
• RE: Sanity check on API using flows from Flows Task Force (Sunday, 14 February)
• RE: ACTION STRONGLY ENCOURAGED: Flows ready for wider review (Sunday, 14 February)

mattsaxon

• Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60) (Thursday, 25 February)
• Re: [webpayments] Gh pages (#108) (Thursday, 25 February)
• [webpayments] Gh pages (#108) (Thursday, 25 February)
• [webpayments] Gh pages (#107) (Thursday, 25 February)
• Re: [webpayments] Gh pages (#107) (Thursday, 25 February)
• Re: [webpayments] Gh pages (#105) (Tuesday, 23 February)
• [webpayments] Gh pages (#105) (Tuesday, 23 February)
• [webpayments] Minor Changes (#104) (Monday, 22 February)
• Re: [webpayments] Minor Changes (#104) (Monday, 22 February)
• Re: [webpayments] Removed Spaces From File Name (#102) (Friday, 19 February)
• [webpayments] Removed Spaces From File Name (#102) (Friday, 19 February)
• Re: [webpayments] Gh pages (#101) (Friday, 19 February)
• [webpayments] Gh pages (#101) (Friday, 19 February)
• Re: [webpayments] PISP under PSD2_SCT flows_Shopper PISP (#99) (Wednesday, 17 February)
• Re: [webpayments] Added Credit Transfer clarifications (#98) (Wednesday, 17 February)
• Re: [webpayments] Synonym Mapping from Web Environment Terminology to ISO 20022 Terminonogy (#95) (Wednesday, 17 February)
• [webpayments] Added Credit Transfer clarifications (#98) (Wednesday, 17 February)
• Re: [webpayments] PISP under PSD2_SCT flows_Merchant PISP.pml (#97) (Wednesday, 17 February)
• Re: [webpayments] Minor fixes/annoatations (#96) (Wednesday, 17 February)
• [webpayments] Minor fixes/annoatations (#96) (Wednesday, 17 February)
• Re: [webpayments] ISO20022 terminology adoption (#93) (Wednesday, 17 February)
• Re: [webpayments] Synonym Mapping from Web Environment Terminology to ISO 20022 Terminonogy (#95) (Wednesday, 17 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Wednesday, 17 February)
• Re: [webpayments] ISO20022 terminology adoption (#93) (Wednesday, 17 February)
• Re: [webpayments] Flow terminology (#92) (Wednesday, 17 February)
• Re: [webpayments] Flow terminology (#92) (Wednesday, 17 February)
• Re: [webpayments] ISO20022 terminology adoption (#93) (Wednesday, 17 February)
• Re: [webpayments] ISO20022 terminology adoption (#93) (Wednesday, 17 February)
• Re: [webpayments] ISO20022 terminology adoption (#93) (Wednesday, 17 February)
• [webpayments] Transition and Adoption (#94) (Wednesday, 17 February)
• [webpayments] ISO20022 terminology adoption (#93) (Wednesday, 17 February)
• [webpayments] Flow terminology (#92) (Wednesday, 17 February)
• Re: [webpayments] Consolidate updated from Freed into single file (#88) (Sunday, 14 February)
• [webpayments] Consolidate updated from Freed into single file (#88) (Sunday, 14 February)
• [webpayments] Consolidate updated from Freed into single file (#87) (Sunday, 14 February)
• Re: [webpayments] Consolidate updated from Freed into single file (#87) (Sunday, 14 February)
• Re: [webpayments] Returned Skin to default, moved target flows out of directory structure, removed partial flows for SEPA Credit Transfer (#80) (Sunday, 14 February)
• Re: [webpayments] Consolidate updated from Freed into single file (#86) (Sunday, 14 February)
• [webpayments] Consolidate updated from Freed into single file (#86) (Sunday, 14 February)
• Re: [webpayments] Changes based on discussion with Ian Jacobs (#85) (Sunday, 14 February)
• [webpayments] Changes based on discussion with Ian Jacobs (#85) (Sunday, 14 February)
• Re: [webpayments] PSD2 about Payment Initiation 4 Feb 2016 (#82) (Sunday, 14 February)
• Re: [webpayments] How are third-party native wallets integrated? (#42) (Friday, 12 February)
• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Wednesday, 10 February)
• Re: [webpayments] How can the API support enrollment (future payment) use cases? (#65) (Wednesday, 10 February)
• Re: [webpayments] Updated card participants for ISO20022 (#81) (Wednesday, 3 February)
• [webpayments] Updated card participants for ISO20022 (#81) (Wednesday, 3 February)
• Re: [webpayments] Returned Skin to default, moved target flows out of directory structure, removed partial flows for SEPA Credit Transfer (#80) (Wednesday, 3 February)
• [webpayments] Returned Skin to default, moved target flows out of directory structure, removed partial flows for SEPA Credit Transfer (#80) (Wednesday, 3 February)

Melvin Carvalho

• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Wednesday, 10 February)

Mountie Lee

• Re: [paymentrequest] Write-up proposal for shipping address fields (#28) (Wednesday, 24 February)
• Re: Dinner at Croqueta on Sunday at 7pm in San Francisco (Saturday, 20 February)
• Re: ACTION STRONGLY ENCOURAGED: Flows ready for wider review (Tuesday, 2 February)

Nick S

• Re: [paymentrequest] Constructor should not include "total" in list of items (#68) (Friday, 26 February)
• Re: [paymentrequest] At the time complete() is called, your ability to say success (true) or failure (false) may depend on the payment method (#67) (Friday, 26 February)
• Re: [paymentrequest] Write-up proposal for shipping address fields (#28) (Tuesday, 23 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Sunday, 21 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Thursday, 18 February)
• Re: [webpayments] Multilingual Support for human-readable labels (#84) (Saturday, 13 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Friday, 12 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Thursday, 11 February)
• Re: [paymentrequest] No mention of non-decimal currencies (#40) (Thursday, 11 February)

Nick Shearer

• Re: [webpayments] How can the API support enrollment (future payment) use cases? (#65) (Thursday, 11 February)
• Re: [webpayments] Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app? (#66) (Wednesday, 10 February)

Nick Telford-Reed

• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Thursday, 18 February)

obkhan

• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Thursday, 4 February)

oldoldb

• Re: [webpayments] How do we prevent keyboard hooking during payment? (#90) (Tuesday, 16 February)
• Re: [webpayments] How do we prevent keyboard hooking during payment? (#90) (Tuesday, 16 February)
• [webpayments] How do we prevent keyboard hooking during payment? (#90) (Monday, 15 February)

omar.khan@wellsfargo.com

• Re: PROPOSAL regarding JSON-LD material (Tuesday, 9 February)
• interested in JSON-LD (Saturday, 6 February)

Paddy Ramanathan

• Re: Dinner at Croqueta on Sunday at 7pm in San Francisco (Saturday, 20 February)

Prayag Verma

• [webpayments] Fix typos (#91) (Monday, 15 February)

Rouslan Solomakhin

• Re: [paymentrequest] At the time complete() is called, your ability to say success (true) or failure (false) may depend on the payment method (#67) (Monday, 29 February)
• Re: [paymentrequest] Constructor should not include "total" in list of items (#68) (Monday, 29 February)
• Re: [paymentrequest] Write-up proposal for shipping address fields (#28) (Monday, 29 February)
• Re: [paymentrequest] Write-up proposal for shipping address fields (#28) (Tuesday, 23 February)
• Re: [paymentrequest] Write-up proposal for shipping address fields (#28) (Monday, 22 February)
• Re: [paymentrequest] Write-up proposal for shipping address fields (#28) (Monday, 22 February)
• Re: [paymentrequest] Write-up proposal for shipping address fields (#28) (Monday, 22 February)
• Re: [paymentrequest] Example 1 typo: payment.complete(true) should be paymentResponse.complete(true) (#53) (Monday, 22 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Thursday, 18 February)
• Re: [webpayments] How are third-party native wallets integrated? (#42) (Thursday, 18 February)
• Re: [webpayments] How do we prevent keyboard hooking during payment? (#90) (Thursday, 18 February)
• Re: [webpayments] How are third-party native wallets integrated? (#42) (Thursday, 18 February)
• Re: [webpayments] Multilingual Support for human-readable labels (#84) (Thursday, 18 February)
• Re: [webpayments] Transition and Adoption (#94) (Thursday, 18 February)
• Re: [webpayments] How do we prevent keyboard hooking during payment? (#90) (Thursday, 18 February)
• Re: [webpayments] Transition and Adoption (#94) (Thursday, 18 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Thursday, 18 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Thursday, 18 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Friday, 12 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Thursday, 11 February)
• Re: [webpayments] How can the API support enrollment (future payment) use cases? (#65) (Wednesday, 10 February)
• Re: Checkout API spec published (Wednesday, 10 February)
• Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60) (Wednesday, 10 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Tuesday, 9 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Tuesday, 9 February)
• Re: [webpayments] How can the API support enrollment (future payment) use cases? (#65) (Tuesday, 9 February)
• Re: [webpayments] Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app? (#66) (Tuesday, 9 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Tuesday, 9 February)
• Re: [webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76) (Tuesday, 9 February)
• Re: Checkout API (Tuesday, 9 February)
• Re: Checkout API (Tuesday, 9 February)
• Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77) (Wednesday, 3 February)
• Re: [webpayments] How do we protect certian data in the messages from certain parties in the flow as the use case requires? (#78) (Wednesday, 3 February)
• Re: [webpayments] Should the payment request support multiple pricing options? (#79) (Wednesday, 3 February)

Shane McCarron

• Re: [paymentrequest] Constructor should not include "total" in list of items (#68) (Monday, 29 February)
• Re: [paymentrequest] Constructor should not include "total" in list of items (#68) (Friday, 26 February)
• Re: [paymentrequest] Constructor should not include "total" in list of items (#68) (Thursday, 25 February)
• Re: [paymentrequest] Constructor should not include "total" in list of items (#68) (Thursday, 25 February)
• [paymentrequest] Constructor should not include "total" in list of items (#68) (Wednesday, 24 February)
• Re: Dinner at Croqueta on Sunday at 7pm in San Francisco (Saturday, 20 February)
• Re: Sanity check on API using flows from Flows Task Force (Tuesday, 16 February)
• Re: Checkout API spec published (Friday, 12 February)
• Re: [webpayments] Should the payment request support multiple pricing options? (#79) (Sunday, 7 February)
• Re: [webpayments] How do we protect certian data in the messages from certain parties in the flow as the use case requires? (#78) (Sunday, 7 February)
• Re: [webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76) (Sunday, 7 February)
• Re: [webpayments] Returned Skin to default, moved target flows out of directory structure, removed partial flows for SEPA Credit Transfer (#80) (Wednesday, 3 February)
• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)

Telford-Reed, Nick

• RE: The Open Banking Standard (HTTP API) (Friday, 19 February)
• Face to face - some important reading (Thursday, 18 February)
• Meeting today (Thursday, 18 February)
• AGENDA for our call February 11th 2016 at 17h00 (Wednesday, 10 February)
• Some things that might help with PROPOSAL regarding JSON-LD material (Wednesday, 10 February)
• Telecon 4th February 2016 at 17:00 UTC (Wednesday, 3 February)
• ACTION STRONGLY ENCOURAGED: Flows ready for wider review (Monday, 1 February)
• RE: Concerns around Web Payments HTTP API de-prioritization (Monday, 1 February)

Vincent Kuntz

• Re: [webpayments] How should the message schemas for the payment request and response be defined? (#27) (Tuesday, 2 February)
• Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60) (Monday, 1 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Monday, 1 February)
• Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57) (Monday, 1 February)
• Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57) (Monday, 1 February)

Zach Koch

• Re: [paymentrequest] Constructor should not include "total" in list of items (#68) (Monday, 29 February)
• Re: [paymentrequest] Constructor should not include "total" in list of items (#68) (Wednesday, 24 February)
• Re: [paymentrequest] Payment App Registration: Same Origin is problematic for identifying_url (#66) (Wednesday, 24 February)
• Draft of PaymentRequest Registration Doc Available (Tuesday, 23 February)
• [paymentrequest] Add registration explainer (#64) (Tuesday, 23 February)
• Re: [paymentrequest] Example 1 typo: payment.complete(true) should be paymentResponse.complete(true) (#53) (Tuesday, 23 February)
• Re: [paymentrequest] State in each class's definition which internal slots it has (#61) (Tuesday, 23 February)
• Re: [paymentrequest] Add skeleton of basic card spec and tidy-up API spec (#63) (Tuesday, 23 February)
• New PaymentRequest Doc (Friday, 19 February)
• Re: [paymentrequest] Add rationale and update document locations (#62) (Friday, 19 February)
• Re: [paymentrequest] Add rationale and update document locations (#62) (Friday, 19 February)
• Re: [paymentrequest] Add rationale and update document locations (#62) (Friday, 19 February)
• [paymentrequest] Add rationale and update document locations (#62) (Friday, 19 February)
• Re: Face to face - some important reading (Thursday, 18 February)
• Re: [webpayments] What are the WPWG February 2016 face-to-face prioritized issues (#89) (Thursday, 18 February)
• Re: [paymentrequest] Tidy-up per discussion (#52) (Saturday, 13 February)
• Re: [webpayments] Should we expose status change events in the browser API? (#41) (Friday, 12 February)
• Re: [webpayments] What is the appropriate conversational pattern for the API? (#55) (Friday, 12 February)
• Checkout API spec published (Thursday, 11 February)
• Re: [paymentrequest] Proposal to move the complete() method to the PaymentResponse interface (#48) (Thursday, 11 February)
• Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Wednesday, 10 February)
• Re: [webpayments] How can the API support enrollment (future payment) use cases? (#65) (Wednesday, 10 February)
• Re: Checkout API spec published (Monday, 8 February)
• Re: [webpayments] PROPOSAL: The PaymentRequest object SHOULD NOT expose internal state information to the developer. Any design that requires developers to manage or understand the request state is a compromise in the API design that should be avoided where possible. (#64) (Friday, 5 February)
• Re: [webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76) (Monday, 1 February)

Last message date: Monday, 29 February 2016 21:50:31 UTC