public-webpayments-specs@w3.org from March 2017 by date

Friday, 31 March 2017

• [w3c/browser-payment-api] Adding legal entity types for consistency (#491) Alexander Batishchev
• [w3c/webpayments-payment-apps-api] Share user data with Payment App (#123) frank-hoffmann
• Re: [w3c/browser-payment-api] Should user agent validate currency? (#490) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Should user agent validate currency? (#490) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Should user agent validate currency? (#490) Domenic Denicola
• Re: [w3c/browser-payment-api] Should user agent validate currency? (#490) Domenic Denicola
• Re: [w3c/browser-payment-api] Should user agent validate currency? (#490) Per Thomas Jahr
• Re: [w3c/browser-payment-api] should .show() be user gated? (#486) Marcos Cáceres
• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Domenic Denicola
• Re: [w3c/browser-payment-api] Use "NotAllowedError" instead of "QuotaExceededError" (#488) Marcos Cáceres
• Re: [w3c/browser-payment-api] Disallow multiple showing payment requests per user agent (#487) Domenic Denicola
• Re: [w3c/browser-payment-api] editorial: grouped payment details dictionaries into section (#479) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: grouped payment details dictionaries into section (#479) kayakalan
• Re: [w3c/browser-payment-api] Disallow multiple showing payment requests per user agent (#487) Marcos Cáceres
• Re: [w3c/browser-payment-api] Should user agent validate currency? (#490) Marcos Cáceres
• Re: [w3c/browser-payment-api] Should user agent validate currency? (#490) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: grouped payment details dictionaries into section (#479) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: grouped payment details dictionaries into section (#479) Marcos Cáceres
• Re: [w3c/browser-payment-api] Group payment dictionaries into a section (#427) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: grouped payment details dictionaries into section (#479) Marcos Cáceres
• Re: [w3c/browser-payment-api] Add payerGivenName + payerFamilyName to PaymentAddress (#480) Marcos Cáceres
• Re: [w3c/browser-payment-api] Should user agent validate currency? (#490) Marcos Cáceres
• Re: [w3c/browser-payment-api] Should user agent validate currency? (#490) Marcos Cáceres
• Re: [w3c/browser-payment-api] Should user agent validate currency? (#490) Marcos Cáceres
• Re: [w3c/browser-payment-api] markup issues (#441) Marcos Cáceres
• Re: [w3c/browser-payment-api] markup issues (#441) Marcos Cáceres

Thursday, 30 March 2017

• Re: [w3c/browser-payment-api] Clarify wording to not imply 'pull' only payments (#474) ianbjacobs
• Re: [w3c/browser-payment-api] Should user agent validate currency? (#490) Per Thomas Jahr
• Re: [w3c/browser-payment-api] Should user agent validate currency? (#490) ianbjacobs
• [w3c/browser-payment-api] Should user agent validate currency? (#490) Per Thomas Jahr
• Re: [w3c/browser-payment-api] Why are two sections non-normative? (#466) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Domenic Denicola
• Re: [w3c/browser-payment-api] Add payerGivenName + payerFamilyName to PaymentAddress (#480) lararennie
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Domenic Denicola
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Domenic Denicola
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Domenic Denicola
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Domenic Denicola
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Domenic Denicola
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Domenic Denicola
• [w3c/browser-payment-api] fix: change Events section to normative (closes #466) (#489) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Origin should include iframe(s) (#120) frank-hoffmann
• Re: [w3c/browser-payment-api] Behavior for multiple modifiers for the same payment method is not defined (#309) Domenic Denicola
• Re: [w3c/browser-payment-api] Why are two sections non-normative? (#466) Domenic Denicola
• Re: [w3c/browser-payment-api] Why are two sections non-normative? (#466) Domenic Denicola
• [w3c/browser-payment-api] Use "NotAllowedError" instead of "QuotaExceededError" (#488) Domenic Denicola
• [w3c/browser-payment-api] Disallow multiple showing payment requests per user agent (#487) Domenic Denicola
• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Domenic Denicola

Wednesday, 29 March 2017

• Re: [w3c/browser-payment-api] should .show() be user gated? (#486) Matt N.
• Re: [w3c/browser-payment-api] Add payerGivenName + payerFamilyName to PaymentAddress (#480) Zach Koch
• Re: [w3c/browser-payment-api] Behavior for multiple modifiers for the same payment method is not defined (#309) Zach Koch
• Re: [w3c/browser-payment-api] supportedMethods (URL and DOMString) (#464) Marcos Cáceres
• Re: [w3c/browser-payment-api] Does PR API need to include text around matching to take payment method manifest into account? (#478) Marcos Cáceres
• Re: [w3c/browser-payment-api] Does PR API need to include text around matching to take payment method manifest into account? (#478) Marcos Cáceres
• Re: [w3c/browser-payment-api] Why are two sections non-normative? (#466) Marcos Cáceres
• Re: [w3c/browser-payment-api] should .show() be user gated? (#486) Marcos Cáceres
• Re: [w3c/browser-payment-api] should .show() be user gated? (#486) Zach Koch
• Re: [w3c/browser-payment-api] should .show() be user gated? (#486) Nick Shearer
• Re: [w3c/webpayments-methods-card] Clarify the required behaviour for options parameters (#26) ianbjacobs
• Re: [w3c/webpayments-methods-card] Clarify the required behaviour for options parameters (#26) mattsaxon
• Re: [w3c/browser-payment-api] should .show() be user gated? (#486) mattsaxon
• Re: [w3c/webpayments-payment-apps-api] Should `modifiers` be passed to the payment handler? (#118) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Should `modifiers` be passed to the payment handler? (#118) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] should .show() be user gated? (#486) Dave Longley
• Re: [w3c/webpayments-methods-card] Clarify the required behaviour for options parameters (#26) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Origin should include iframe(s) (#120) Dave Longley
• Re: [w3c/webpayments-payment-apps-api] Origin should include iframe(s) (#120) frank-hoffmann
• Re: [w3c/webpayments-methods-card] Clarify the required behaviour for options parameters (#26) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Origin should include iframe(s) (#120) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] should .show() be user gated? (#486) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] should .show() be user gated? (#486) ianbjacobs
• Re: [w3c/browser-payment-api] complete() does not match all payment apps (#484) ianbjacobs
• Re: [w3c/browser-payment-api] complete() does not match all payment apps (#484) Anders Rundgren
• Re: [w3c/webpayments-payment-apps-api] Origin should include iframe(s) (#120) frank-hoffmann
• Re: [w3c/webpayments-payment-apps-api] Origin should include iframe(s) (#120) Marcos Cáceres
• Re: [w3c/webpayments-methods-card] Clarify the required behaviour for options parameters (#26) Marcos Cáceres
• Re: [w3c/browser-payment-api] should .show() be user gated? (#486) Matt N.
• [w3c/browser-payment-api] should .show() be user gated? (#486) Marcos Cáceres
• Re: [w3c/browser-payment-api] Supplement QuoteExceededError with NotAllowedError for canMakePayments (#485) Domenic Denicola
• Re: [w3c/webpayments-payment-apps-api] [Editorial] Clean up respec errors (#122) Marcos Cáceres

Tuesday, 28 March 2017

• [w3c/webpayments-payment-apps-api] [Editorial] Clean up respec errors (#122) ianbjacobs
• Re: [w3c/browser-payment-api] Consider removing merchant preference language (#481) ianbjacobs
• Re: [w3c/browser-payment-api] Consider removing merchant preference language (#481) Zach Koch
• Re: [w3c/browser-payment-api] Supplement QuoteExceededError with NotAllowedError for canMakePayments (#485) Zach Koch
• Re: [w3c/browser-payment-api] Add payerGivenName + payerFamilyName to PaymentAddress (#480) ianbjacobs
• [w3c/webpayments-payment-apps-api] The instrumnets/wallets attributes should be readonly and [SameObject]. (#121) Jinho Bang
• Re: [w3c/browser-payment-api] Add payerGivenName + payerFamilyName to PaymentAddress (#480) lararennie
• Re: [w3c/browser-payment-api] Add payerGivenName + payerFamilyName to PaymentAddress (#480) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Supplement QuoteExceededError with NotAllowedError for canMakePayments (#485) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Origin should include iframe(s) (#120) Rouslan Solomakhin
• Re: [w3c/webpayments-methods-card] Clarify the required behaviour for options parameters (#26) ianbjacobs
• [w3c/webpayments-payment-apps-api] Origin should include iframe(s) (#120) frank-hoffmann
• Re: [w3c/browser-payment-api] Consider removing merchant preference language (#481) Michel Weksler
• [w3c/browser-payment-api] Supplement QuoteExceededError with NotAllowedError for canMakePayments (#485) Nick Shearer
• Re: [w3c/browser-payment-api] Consider removing merchant preference language (#481) Nick Shearer
• Re: [w3c/browser-payment-api] Recipient and payerName are lacking i18n support (#471) Nick Shearer
• Re: [w3c/browser-payment-api] Recipient and payerName are lacking i18n support (#471) Nick Shearer
• [w3c/browser-payment-api] complete() does not match all payment apps (#484) Anders Rundgren
• Re: [w3c/browser-payment-api] Add payerGivenName + payerFamilyName to PaymentAddress (#480) Nick Shearer
• Re: [w3c/webpayments-payment-apps-api] Open Window Algorithm (#115) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• [w3c/webpayments-payment-apps-api] PaymentRequestEvent incompatible with DOM events (#119) Marcos Cáceres
• Re: [w3c/webpayments-methods-card] Clarify the required behaviour for options parameters (#26) Marcos Cáceres
• Re: [w3c/browser-payment-api] Recipient and payerName are lacking i18n support (#471) Marcos Cáceres
• Re: [w3c/browser-payment-api] Clarify wording to not imply 'pull' only payments (#474) Marcos Cáceres
• Re: [w3c/browser-payment-api] "User accepts the payment request algorithm" needs to clarify where Payment Handlers are invoked (#476) Marcos Cáceres
• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Marcos Cáceres
• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Marcos Cáceres
• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Domenic Denicola
• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Marcos Cáceres
• Re: [w3c/browser-payment-api] Should the user agent generate the `id` when it's empty? (#483) Marcos Cáceres

Monday, 27 March 2017

• Re: [w3c/browser-payment-api] Should the user agent generate the `id` when it's empty? (#483) Domenic Denicola
• [w3c/browser-payment-api] Should the user agent generate the `id` when it's empty? (#483) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Should `modifiers` be passed to the payment handler? (#118) Rouslan Solomakhin
• [w3c/webpayments-payment-apps-api] Should `modifiers` be passed to the payment handler? (#118) Rouslan Solomakhin

Saturday, 25 March 2017

• [w3c/browser-payment-api] mark currencySystem as feature at risk (#482) Marcos Caceres
• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Domenic Denicola

Friday, 24 March 2017

• Re: [w3c/webpayments-payment-apps-api] Support for Abort() being delegated to Payment Handler (#117) mattsaxon
• Re: [w3c/webpayments-payment-apps-api] Support for Abort() being delegated to Payment Handler (#117) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Consider removing merchant preference language (#481) Michel Weksler
• Re: [w3c/browser-payment-api] Consider removing merchant preference language (#481) ianbjacobs
• [w3c/browser-payment-api] Consider removing merchant preference language (#481) Zach Koch
• Re: [w3c/browser-payment-api] Aborting of in progress push payments (#473) mattsaxon
• [w3c/webpayments-payment-apps-api] Support for Abort() being delegated to Payment Handler (#117) mattsaxon
• [w3c/webpayments-method-identifiers] Check what happens if URL parsing throws.... (#27) Marcos Caceres
• [w3c/browser-payment-api] Add payerGivenName + payerFamilyName to PaymentAddress (#480) Marcos Caceres
• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] editorial: grouped payment details dictionaries into section (#479) Marcos Caceres
• [w3c/browser-payment-api] editorial: grouped payment details dictionaries into section (#479) kayakalan
• [w3c/browser-payment-api] Does PR API need to include text around matching to take payment method manifest into account? (#478) ianbjacobs
• [w3c/browser-payment-api] Editors to figure out text on line items (#477) Zach Koch
• [w3c/browser-payment-api] "User accepts the payment request algorithm" needs to clarify where Payment Handlers are invoked (#476) mattsaxon
• [w3c/browser-payment-api] Clarity required in section 21.2 regarding (#475) mattsaxon
• [w3c/browser-payment-api] Clarify wording to not imply 'pull' only payhments (#474) mattsaxon
• Re: [w3c/browser-payment-api] Aborting of in progress push payments (#473) mattsaxon
• Re: [w3c/webpayments-methods-card] Leave Off Unneeded Information (#5) mattsaxon

Thursday, 23 March 2017

• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Domenic Denicola
• [w3c/webpayments-payment-apps-api] Relation between merchant order of payment methods and payment app order of instruments (#116) ianbjacobs
• Re: [w3c/webpayments-methods-card] PaymentResponse missing filters (#28) mattsaxon
• Re: [w3c/webpayments-methods-card] PaymentResponse missing filters (#28) mattsaxon
• Re: [w3c/webpayments-methods-card] PaymentResponse missing filters (#28) Zach Koch
• Re: [w3c/browser-payment-api] fix(complete): bugus result value will have thrown already (#468) Zach Koch
• Re: [w3c/browser-payment-api] fix(complete): bugus result value will have thrown already (#468) Zach Koch
• [w3c/webpayments-methods-card] PymentResponse missing filters (#28) mattsaxon
• [w3c/browser-payment-api] Aborting of in progress push payments (#473) mattsaxon
• [w3c/browser-payment-api] Request `shippingType` attribute is not defined (#472) Marcos Caceres
• [w3c/browser-payment-api] Recipient and payerName are lacking i18n support (#471) Nick Shearer
• [w3c/browser-payment-api] Add explicit extension point to matching algo (#470) Zach Koch
• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] 'Interactive' Bias in API (#467) Zach Koch
• Re: [w3c/browser-payment-api] 'Interactive' Bias in API (#467) Nick Shearer
• Re: [w3c/browser-payment-api] editorial: remove redundant event declaration (#469) Domenic Denicola
• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Domenic Denicola
• Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) Zach Koch

Wednesday, 22 March 2017

• Re: [w3c/browser-payment-api] Unclear what happens when multiple PRs call show() (#462) Zach Koch
• Re: [w3c/browser-payment-api] updateWith will silently ignore data in hard-to-debug ways (#350) Zach Koch
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Zach Koch
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Zach Koch
• [w3c/browser-payment-api] editorial: remove redundant event declaration (#469) Marcos Caceres
• [w3c/browser-payment-api] fix(complete): bugus result value will have thrown already (#468) Marcos Caceres
• [w3c/webpayments-methods-card] Clarify this specification is intended to become a W3C Note (#27) ianbjacobs
• Re: [w3c/webpayments-methods-card] Clarify the required behaviour for options parameters (#26) Rouslan Solomakhin
• [w3c/browser-payment-api] 'Interactive' Bias in API (#467) mattsaxon
• Re: [w3c/webpayments-methods-card] Clarify the required behaviour for options parameters (#26) ianbjacobs
• [w3c/webpayments-methods-card] Clarify the required behaviour for options parameters (#26) mattsaxon

Tuesday, 21 March 2017

• [w3c/webpayments-method-identifiers] Link to registry of W3C-published short strings (#26) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Revisiting payment app filtering (#96) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Revisiting payment app filtering (#96) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Multiple payment apps per origin (#98) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Multiple payment apps per origin (#98) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Use PaymentRequest and PaymentResponse (#99) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Use PaymentRequest and PaymentResponse (#99) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• [w3c/webpayments-payment-apps-api] Open Window Algorithm (#115) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Small fixes (#114) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Small fixes (#114) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] `appRequest` attribute should not be a dictionary (#111) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] `appRequest` attribute should not be a dictionary (#111) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] `appRequest` attribute should not be a dictionary (#111) adamroach
• Re: [w3c/browser-payment-api] Editorial changes (#465) Marcos Cáceres
• Re: [w3c/browser-payment-api] Editorial changes (#465) Marcos Cáceres
• Re: [w3c/browser-payment-api] Editorial changes (#465) ianbjacobs
• Re: [w3c/browser-payment-api] Editorial changes (#465) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: make supportedMethod conforming (#463) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: make supportedMethod conforming (#463) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Small fixes (#114) ianbjacobs
• Re: [w3c/browser-payment-api] Editorial changes (#465) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] `appRequest` attribute should not be a dictionary (#111) Marcos Cáceres

Monday, 20 March 2017

• Re: [w3c/webpayments-payment-apps-api] `appRequest` attribute should not be a dictionary (#111) adamroach
• Re: [w3c/webpayments-payment-apps-api] `appRequest` attribute should not be a dictionary (#111) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] `appRequest` attribute should not be a dictionary (#111) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] `appRequest` attribute should not be a dictionary (#111) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Small fixes (#114) Marcos Cáceres
• Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Renaming PaymentApp* classes (#109) adamroach
• Re: [w3c/browser-payment-api] Editorial changes (#465) Marcos Cáceres
• Re: [w3c/browser-payment-api] Editorial changes (#465) ianbjacobs
• Re: [w3c/browser-payment-api] Editorial changes (#465) Marcos Cáceres
• Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) Domenic Denicola
• [w3c/browser-payment-api] Why are two sections non-normative? (#466) ianbjacobs
• [w3c/browser-payment-api] Editorial changes (#465) ianbjacobs
• [w3c/webpayments-payment-apps-api] Small fixes (#114) ianbjacobs
• Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) ianbjacobs
• Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) Marcos Cáceres
• Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) ianbjacobs
• Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Renaming PaymentApp* classes (#109) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] `appRequest` attribute should not be a dictionary (#111) Marcos Cáceres
• Re: [w3c/webpayments-methods-card] Say how we integrate with PaymentRequest (#23) Marcos Cáceres
• Re: [w3c/webpayments-method-identifiers] chore: tidy (#25) Marcos Cáceres
• Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) Marcos Cáceres
• Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) Marcos Cáceres
• Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) Domenic Denicola
• Re: [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) ianbjacobs
• [w3c/browser-payment-api] supportedMethods (URL and enums) (#464) Marcos Cáceres
• Re: [w3c/webpayments-method-identifiers] Add marcoscaceres as collaborator (#24) ianbjacobs
• Re: [w3c/webpayments-method-identifiers] Add marcoscaceres as collaborator (#24) ianbjacobs
• [w3c/webpayments-method-identifiers] chore: tidy (#25) Marcos Cáceres
• [w3c/webpayments-method-identifiers] Add marcosscaceres as collaborator (#24) Marcos Cáceres
• Re: [w3c/webpayments-method-identifiers] Why are payment ids restricted to [a-z0-9]? (#20) Marcos Cáceres
• [w3c/browser-payment-api] fix: make supportedMethod conforming (#463) Marcos Cáceres

Sunday, 19 March 2017

• Re: [w3c/webpayments-payment-apps-api] Per 16 March teleconf [1], displayItems are not handed to the payment app (#110) adamroach
• Re: [w3c/webpayments-payment-apps-api] Per 16 March teleconf [1], displayItems are not handed to the payment app (#110) adamroach

Saturday, 18 March 2017

• Re: [w3c/webpayments-payment-apps-api] Updates for F2F meeting (#113) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Updates for F2F meeting (#113) ianbjacobs
• [w3c/webpayments-payment-apps-api] Updates for F2F meeting (#113) adamroach
• Re: [w3c/webpayments-payment-apps-api] Renaming PaymentApp* classes (#109) adamroach
• Re: [w3c/browser-payment-api] Need to define the interaction of payment API with navigation and browsing context destruction (#360) Boris Zbarsky

Friday, 17 March 2017

• Re: [w3c/webpayments-payment-apps-api] `appRequest` attribute should not be a dictionary (#111) adamroach
• Re: [w3c/webpayments-payment-apps-api] Use PaymentRequest and PaymentResponse (#99) adamroach
• Re: [w3c/webpayments-payment-apps-api] Merging from main branch (#112) adamroach
• [w3c/webpayments-payment-apps-api] Merging from main branch (#112) adamroach
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• [w3c/webpayments-payment-apps-api] `appRequest` attribute should not be a dictionary (#111) Rouslan Solomakhin
• [w3c/webpayments-payment-apps-api] Per 16 March teleconf [1], displayItems are not handed to the payment app (#110) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• [w3c/browser-payment-api] Unclear what happens when multiple PRs are created (#462) Marcos Cáceres
• [w3c/browser-payment-api] show() method lacks developer guidance (#461) Marcos Cáceres
• Re: [w3c/browser-payment-api] PaymentRequest type checks (valid non-negative monetary value) (#306) Marcos Cáceres
• Re: [w3c/browser-payment-api] PaymentRequest type checks (valid non-negative monetary value) (#306) Marcos Cáceres
• Re: [w3c/browser-payment-api] maybe add `DisplayItem` dictionary (#457) Marcos Cáceres
• Re: [w3c/browser-payment-api] maybe add `DisplayItem` dictionary (#457) Marcos Cáceres
• Re: [w3c/browser-payment-api] valid decimal monetary value maybe overly restrictive (#304) Marcos Cáceres
• Re: [w3c/browser-payment-api] Ambiguity in "Process payment methods:" (#458) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Different approaches to opening windows (#97) Dave Longley
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Dave Longley
• Re: [w3c/webpayments-payment-apps-api] Renaming PaymentApp* classes (#109) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Structural changes based on task force discussion (#107) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres

Thursday, 16 March 2017

• Re: [w3c/webpayments-payment-apps-api] Renaming PaymentApp* classes (#109) Tommy Thorsen
• Re: [w3c/browser-payment-api] Add dir/lang member on dictionaries whose content is displayed in browser UI (#327) r12a
• Re: [w3c/browser-payment-api] Ambiguity in "Process payment methods:" (#458) Domenic Denicola
• Re: [w3c/webpayments-payment-apps-api] Renaming PaymentApp* classes (#109) Adrian Hope-Bailie
• Re: [w3c/webpayments-payment-apps-api] Why does a Payment App need to see the line items? (#91) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Why does a Payment App need to see the line items? (#91) Adrian Hope-Bailie
• Re: [w3c/webpayments-payment-apps-api] Why does a Payment App need to see the line items? (#91) Adrian Hope-Bailie
• Re: [w3c/browser-payment-api] Addition of flag on PaymentMethodData to indicate that line items should be shared with apps (#446) Zach Koch
• Re: [w3c/browser-payment-api] Addition of flag on PaymentMethodData to indicate that line items should be shared with apps (#446) Zach Koch
• Re: [w3c/webpayments-payment-apps-api] Renaming PaymentApp* classes (#109) PASCAL J. BAZIN
• Re: [w3c/browser-payment-api] Ambiguity in "Process payment methods:" (#458) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Renaming PaymentApp* classes (#109) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) ianbjacobs
• Re: [w3c/browser-payment-api] Define payment option filtering algorithm. (#420) ianbjacobs
• [w3c/webpayments-payment-apps-api] Renaming PaymentApp* classes (#109) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/browser-payment-api] Ambiguity in "Process payment methods:" (#458) Marcos Cáceres
• Re: [w3c/browser-payment-api] Define payment option filtering algorithm. (#420) Adrian Hope-Bailie
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Marcos Cáceres
• Re: [w3c/browser-payment-api] Badness in constructor... (#459) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial(constructor): remove redundant line (closes #459) (#460) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial(constructor): remove redundant line (closes #459) (#460) Marcos Cáceres
• [w3c/browser-payment-api] editorial(constructor): remove redundant line (closes #459) (#460) Marcos Cáceres
• [w3c/browser-payment-api] Badness in constructor... (#459) Marcos Cáceres
• [w3c/browser-payment-api] Ambiguity in "Process payment methods:" (#458) Marcos Cáceres
• Re: [w3c/browser-payment-api] Add Guidance Text for User Consent (#229) ianbjacobs
• Re: [w3c/browser-payment-api] Add Guidance Text for User Consent (#229) ianbjacobs
• Re: [w3c/browser-payment-api] Add Guidance Text for User Consent (#229) ianbjacobs

Wednesday, 15 March 2017

• Re: [w3c/browser-payment-api] Add Guidance Text for User Consent (#229) chaals
• Re: [w3c/browser-payment-api] valid decimal monetary value maybe overly restrictive (#304) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] valid decimal monetary value maybe overly restrictive (#304) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] NotSupportedError in private browsing mode (#448) Domenic Denicola
• Re: [w3c/browser-payment-api] NotSupportedError in private browsing mode (#448) Domenic Denicola
• Re: [w3c/browser-payment-api] valid decimal monetary value maybe overly restrictive (#304) Marcos Cáceres
• Re: [w3c/browser-payment-api] valid decimal monetary value maybe overly restrictive (#304) Marcos Cáceres
• Re: [w3c/browser-payment-api] Add Guidance Text for User Consent (#229) Zach Koch
• Re: [w3c/browser-payment-api] Add Guidance Text for User Consent (#229) Zach Koch
• Re: [w3c/browser-payment-api] How can a user agent not accept a payment method? (#273) Zach Koch
• Re: [w3c/browser-payment-api] How can a user agent not accept a payment method? (#273) Zach Koch
• Re: [w3c/browser-payment-api] What does it mean to "accept the payment"? (#278) Marcos Cáceres
• Re: [w3c/browser-payment-api] What does it mean to "accept the payment"? (#278) Zach Koch
• Re: [w3c/browser-payment-api] Should values for supportedNetworks be defined in Basic Card or separately? (#325) Zach Koch
• Re: [w3c/browser-payment-api] Should values for supportedNetworks be defined in Basic Card or separately? (#325) Zach Koch
• Re: [w3c/webpayments-methods-card] Add link to list of card networks (#25) Zach Koch
• Re: [w3c/browser-payment-api] Need to define the interaction of payment API with navigation and browsing context destruction (#360) Marcos Cáceres
• Re: [w3c/browser-payment-api] Add billing shipping type (#409) Zach Koch
• Re: [w3c/browser-payment-api] Add billing shipping type (#409) Zach Koch
• Re: [w3c/browser-payment-api] Define payment option filtering algorithm. (#420) Zach Koch
• Re: [w3c/browser-payment-api] Define payment option filtering algorithm. (#420) Zach Koch
• Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Marcos Cáceres
• Re: [w3c/browser-payment-api] maybe add `DisplayItem` dictionary (#457) Domenic Denicola
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Anne van Kesteren
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Adrian Hope-Bailie
• Re: [w3c/webpayments-payment-apps-api] Run the spec through HTML5-Tidy. (#108) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Run the spec through HTML5-Tidy. (#108) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Structural changes based on task force discussion (#107) ianbjacobs
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Simon Pieters
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Simon Pieters
• [w3c/webpayments-payment-apps-api] Run the spec through HTML5-Tidy. (#108) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Michael[tm] Smith
• Re: [w3c/webpayments-payment-apps-api] Different approaches to opening windows (#97) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Different approaches to opening windows (#97) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Structural changes based on task force discussion (#107) Marcos Cáceres
• Re: [w3c/browser-payment-api] maybe add `DisplayItem` dictionary (#457) Marcos Cáceres
• [w3c/browser-payment-api] maybe add `DisplayItem` dictionary (#457) Marcos Cáceres
• [w3c/webpayments-payment-apps-api] Structural changes based on task force discussion (#107) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Structural changes based on task force discussion (#107) ianbjacobs

Tuesday, 14 March 2017

• Re: [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Adrian Hope-Bailie
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Domenic Denicola
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) ianbjacobs
• [w3c/webpayments-payment-apps-api] Change from clients.openWindow to event.openWindow. (#106) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Need to specify behavior for Clients.openWindow (#73) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Need to specify behavior for Clients.openWindow (#73) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Replace setManifest()/getManifest() with set()/get()/keys()/has()/delete() (#95) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Replace setManifest()/getManifest() with set()/get()/keys()/has()/delete() (#95) ianbjacobs
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Tobie Langel
• Re: [w3c/browser-payment-api] PaymentRequest does not handle the case of store pickup (#389) Adrian Hope-Bailie
• Re: [w3c/browser-payment-api] PaymentRequest type checks (valid non-negative monetary value) (#306) Marcos Cáceres
• Re: [w3c/browser-payment-api] PaymentRequest type checks (valid non-negative monetary value) (#306) Marcos Cáceres
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Anne van Kesteren
• Re: [w3c/browser-payment-api] Initial values for internal slots (#436) Marcos Cáceres
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Marcos Cáceres
• [w3c/browser-payment-api] Move examples to top of document (#456) Marcos Cáceres
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Domenic Denicola
• Re: [w3c/browser-payment-api] Initial values for internal slots (#436) Domenic Denicola
• Re: [w3c/browser-payment-api] Add dir/lang member on dictionaries whose content is displayed in browser UI (#327) Marcos Cáceres
• Re: [w3c/browser-payment-api] Add dir/lang member on dictionaries whose content is displayed in browser UI (#327) Marcos Cáceres
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Marcos Cáceres
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Marcos Cáceres
• Re: [w3c/browser-payment-api] Should values for supportedNetworks be defined in Basic Card or separately? (#325) ianbjacobs
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Marcos Cáceres
• Re: [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Marcos Cáceres
• [w3c/browser-payment-api] l10n: adds Localizable dict + TextDirection enum (closes #327) (#455) Marcos Cáceres

Monday, 13 March 2017

• Re: [w3c/browser-payment-api] PaymentRequest type checks (valid non-negative monetary value) (#306) Zach Koch
• Re: [w3c/browser-payment-api] PaymentRequest does not handle the case of store pickup (#389) Zach Koch
• Re: [w3c/browser-payment-api] PaymentApp fails to abort payment flow (#384) Zach Koch
• Re: [w3c/browser-payment-api] PaymentApp fails to abort payment flow (#384) Zach Koch
• Re: [w3c/browser-payment-api] Should values for supportedNetworks be defined in Basic Card or separately? (#325) Zach Koch
• Re: [w3c/browser-payment-api] Initial values for internal slots (#436) Zach Koch

Friday, 10 March 2017

• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Domenic Denicola
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Domenic Denicola
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Changes to show() and canMakePayment() to take into account (#454) Domenic Denicola
• Re: [w3c/browser-payment-api] Changes to show() and canMakePayment() to take into account (#454) Domenic Denicola
• Re: [w3c/browser-payment-api] Changes to show() and canMakePayment() to take into account (#454) Domenic Denicola
• Re: [w3c/browser-payment-api] Changes to show() and canMakePayment() to take into account (#454) ianbjacobs
• Re: [w3c/browser-payment-api] Changes to show() and canMakePayment() to take into account (#454) Domenic Denicola
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Domenic Denicola
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Domenic Denicola
• [w3c/browser-payment-api] Changes to show() and canMakePayment() to take into account (#454) ianbjacobs
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Domenic Denicola
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Domenic Denicola
• Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Domenic Denicola
• Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Domenic Denicola
• Re: [w3c/browser-payment-api] Remove trailing comma from IDL enums (#453) Marcos Cáceres
• Re: [w3c/browser-payment-api] Remove trailing comma from IDL enums (#453) Marcos Cáceres
• [w3c/browser-payment-api] Remove trailing comma from IDL enums (#453) Simon Pieters
• Re: [w3c/webpayments-payment-apps-api] Different approaches to opening windows (#97) Marcos Cáceres
• Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Domenic Denicola
• Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Zach Koch

Thursday, 9 March 2017

• Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Domenic Denicola
• Re: [w3c/browser-payment-api] Add dir/lang member on dictionaries whose content is displayed in browser UI (#327) Marcos Cáceres
• Re: [w3c/browser-payment-api] Add dir/lang member on dictionaries whose content is displayed in browser UI (#327) ianbjacobs
• Re: [w3c/browser-payment-api] Add dir/lang member on dictionaries whose content is displayed in browser UI (#327) Addison Phillips
• Re: [w3c/browser-payment-api] Add dir/lang member on dictionaries whose content is displayed in browser UI (#327) ianbjacobs
• Re: [w3c/browser-payment-api] Add dir/lang member on dictionaries whose content is displayed in browser UI (#327) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] How can we optimize user experience when there is only one match? (#14) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] How can we optimize user experience when there is only one match? (#14) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] How does the payee provide information about recommended payment apps? (#79) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] How does the payee provide information about recommended payment apps? (#79) ianbjacobs
• Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Zach Koch
• Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) Adrian Hope-Bailie
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) ianbjacobs
• Re: [w3c/browser-payment-api] Add dir/lang member on dictionaries whose content is displayed in browser UI (#327) Marcos Cáceres
• Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Domenic Denicola
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Domenic Denicola
• Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Marcos Cáceres
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Marcos Cáceres
• Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Domenic Denicola
• Re: [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Marcos Cáceres

Wednesday, 8 March 2017

• Re: [w3c/browser-payment-api] Supporting push payment methods (#224) Marcos Cáceres
• Re: [w3c/browser-payment-api] Supporting push payment methods (#224) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) Marcos Cáceres
• Re: [w3c/browser-payment-api] Section for A11Y Considerations (#450) ianbjacobs
• [w3c/browser-payment-api] Fix constructor handling of shippingType (#452) Domenic Denicola
• Re: [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Domenic Denicola
• [w3c/browser-payment-api] Make updateWith() reject the show() promise on validation failures (#451) Domenic Denicola
• Re: [w3c/browser-payment-api] Make updateWith() return a promise signaling any update failures (#418) Domenic Denicola
• Re: [w3c/browser-payment-api] Make updateWith() return a promise signaling any update failures (#418) Domenic Denicola
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) Dave Longley
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) Adrian Hope-Bailie
• Re: [w3c/webpayments-payment-apps-api] Why does a Payment App need to see the line items? (#91) Adrian Hope-Bailie
• Re: [w3c/browser-payment-api] Specify how to abort a payment request (#449) Domenic Denicola
• Re: [w3c/browser-payment-api] Section for A11Y Considerations (#450) chaals
• Re: [w3c/browser-payment-api] Section for A11Y Considerations (#450) ianbjacobs
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) Dave Longley
• Re: [w3c/webpayments-payment-apps-api] Why does a Payment App need to see the line items? (#91) ianbjacobs
• Re: [w3c/browser-payment-api] Specify how to abort a payment request (#449) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] Section for A11Y Considerations (#450) chaals
• Re: [w3c/browser-payment-api] Section for A11Y Considerations (#450) chaals
• Re: [w3c/browser-payment-api] Section for A11Y Considerations (#450) Shane McCarron
• Re: [w3c/browser-payment-api] Section for A11Y Considerations (#450) Shane McCarron
• Re: [w3c/browser-payment-api] Section for A11Y Considerations (#450) Shane McCarron
• Re: [w3c/browser-payment-api] Section for A11Y Considerations (#450) Shane McCarron
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) Adrian Hope-Bailie
• Re: [w3c/webpayments-payment-apps-api] Why does a Payment App need to see the line items? (#91) frank-hoffmann
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) Marcos Cáceres
• Re: [w3c/browser-payment-api] Specify how to abort a payment request (#449) Marcos Cáceres
• Re: [w3c/browser-payment-api] Section for A11Y Considerations (#450) Marcos Cáceres
• Re: [w3c/browser-payment-api] Introductory explanations of methods should be non-normative notes (#379) Marcos Cáceres
• Re: [w3c/browser-payment-api] PaymentResponse attributes should be separate sections (#442) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: attr/method intros are notes (closes #379) (#438) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: attr/method intros are notes (closes #379) (#438) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: attr/method intros are notes (closes #379) (#438) Marcos Cáceres

Tuesday, 7 March 2017

• Re: [w3c/webpayments-payment-apps-api] Proposed changes for #95 (and #96) (#104) Adrian Hope-Bailie
• Re: [w3c/browser-payment-api] editorial: attr/method intros are notes (closes #379) (#438) Domenic Denicola
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) Dave Longley
• Re: [w3c/webpayments-payment-apps-api] Proposed changes for #95 (and #96) (#104) Dave Longley
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) Adrian Hope-Bailie
• Re: [w3c/webpayments-payment-apps-api] Add explicit permission call to allow payment app to handle payments (#94) ianbjacobs
• Re: [w3c/browser-payment-api] Fix markup errors that broke autopublishing (#444) ianbjacobs
• [w3c/browser-payment-api] Section for A11Y Considerations (#450) Shane McCarron
• Re: [w3c/webpayments-payment-apps-api] Proposed changes for #95 (and #96) (#104) Tommy Thorsen
• Re: [w3c/browser-payment-api] Fix markup errors that broke autopublishing (#444) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Fix markup errors that broke autopublishing (#444) Marcos Cáceres
• Re: [w3c/browser-payment-api] Fix markup errors that broke autopublishing (#444) Marcos Cáceres

Monday, 6 March 2017

• Re: [w3c/browser-payment-api] editorial: attr/method intros are notes (closes #379) (#438) Marcos Cáceres
• Re: [w3c/browser-payment-api] Make updateWith() return a promise signaling any update failures (#418) Marcos Cáceres
• Re: [w3c/browser-payment-api] PaymentDetails should include a transaction ID (#287) Marcos Cáceres
• Re: [w3c/browser-payment-api] PaymentDetails should include a transaction ID (#287) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: attr/method intros are notes (closes #379) (#438) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: attr/method intros are notes (closes #379) (#438) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: attr/method intros are notes (closes #379) (#438) Marcos Cáceres
• Re: [w3c/browser-payment-api] PaymentRequestID initialization (#412) Marcos Cáceres
• Re: [w3c/browser-payment-api] PaymentRequestID initialization (#412) Marcos Cáceres
• Re: [w3c/browser-payment-api] It is never stated how the payment request ID is used (#415) Marcos Cáceres
• Re: [w3c/browser-payment-api] Providing/Generating paymentRequestID during construction (#388) Marcos Cáceres
• Re: [w3c/browser-payment-api] It is never stated how the payment request ID is used (#415) Marcos Cáceres
• Re: [w3c/browser-payment-api] feat: put request id in details dictionary (#426) Marcos Cáceres
• Re: [w3c/browser-payment-api] feat: put request id in details dictionary (#426) Domenic Denicola
• Re: [w3c/browser-payment-api] feat: put request id in details dictionary (#426) Marcos Cáceres
• Re: [w3c/browser-payment-api] feat: put request id in details dictionary (#426) Marcos Cáceres
• Re: [w3c/browser-payment-api] feat: put request id in details dictionary (#426) Marcos Cáceres
• Re: [w3c/browser-payment-api] feat: put request id in details dictionary (#426) Domenic Denicola
• Re: [w3c/browser-payment-api] feat: put request id in details dictionary (#426) Marcos Cáceres
• Re: [w3c/browser-payment-api] feat: put request id in details dictionary (#426) Marcos Cáceres
• Re: [w3c/browser-payment-api] feat: put request id in details dictionary (#426) Marcos Cáceres
• Re: [w3c/browser-payment-api] feat: put request id in details dictionary (#426) Domenic Denicola
• Re: [w3c/browser-payment-api] feat: put request id in details dictionary (#426) Marcos Cáceres
• Re: [w3c/browser-payment-api] PaymentDetails "total" member should be required (#320) Domenic Denicola
• Re: [w3c/browser-payment-api] PaymentDetails "total" member should be required (#320) Domenic Denicola
• Re: [w3c/browser-payment-api] feat: put request id in details dictionary (#426) Marcos Cáceres
• Re: [w3c/browser-payment-api] Why does PaymentRequest constructor throw on details.error (#302) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: delegate total and error member checks to WebIDL (#425) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: delegate total and error member checks to WebIDL (#425) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: delegate total and error member checks to WebIDL (#425) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: delegate total and error member checks to WebIDL (#425) Domenic Denicola
• Re: [w3c/browser-payment-api] Specify how to abort a payment request (#449) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: delegate total and error member checks to WebIDL (#425) Marcos Cáceres
• [w3c/browser-payment-api] Specify how to abort a payment request (#449) Domenic Denicola
• Re: [w3c/browser-payment-api] NotSupportedError in private browsing mode (#448) Domenic Denicola
• Re: [w3c/browser-payment-api] NotSupportedError in private browsing mode (#448) Rouslan Solomakhin
• Re: [w3c/browser-payment-api] NotSupportedError in private browsing mode (#448) Domenic Denicola
• Re: [w3c/browser-payment-api] NotSupportedError in private browsing mode (#448) Marcos Cáceres
• [w3c/browser-payment-api] NotSupportedError in private browsing mode (#448) Rouslan Solomakhin
• Re: [w3c/webpayments-payment-apps-api] Proposed changes for #95 (and #96) (#104) Adrian Hope-Bailie

Friday, 3 March 2017

• Re: [w3c/browser-payment-api] API assumes Issuer communication is OOB (#447) Anders Rundgren
• Re: [w3c/browser-payment-api] API assumes Issuer communication is OOB (#447) ianbjacobs
• Re: [w3c/browser-payment-api] API assumes Issuer communication is OOB (#447) ianbjacobs
• Re: [w3c/browser-payment-api] API assumes Issuer communication is OOB (#447) Ben Tian
• Re: [w3c/browser-payment-api] API assumes Issuer communication is OOB (#447) Marcos Cáceres
• Re: [w3c/browser-payment-api] API assumes Issuer communication is OOB (#447) Anders Rundgren
• Re: [w3c/browser-payment-api] API assumes Issuer communication is OOB (#447) Marcos Cáceres
• [w3c/browser-payment-api] API assumes Issuer communication is OOB (#447) Anders Rundgren

Thursday, 2 March 2017

• Re: [w3c/browser-payment-api] Add billing shipping type (#409) stan-stripe
• Re: [w3c/browser-payment-api] fix: delegate total and error member checks to WebIDL (#425) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: delegate total and error member checks to WebIDL (#425) Domenic Denicola
• Re: [w3c/webpayments-payment-apps-api] Proposed changes for #95 (and #96) (#104) ianbjacobs
• Re: [w3c/browser-payment-api] fix: delegate total and error member checks to WebIDL (#425) Domenic Denicola
• Re: [w3c/browser-payment-api] Add billing shipping type (#409) ianbjacobs
• Re: [w3c/browser-payment-api] editorial: s/fields/members + xref fixes (closes #424) (#443) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: s/user interaction/transaction (closes #402) (#432) Zach Koch
• Re: [w3c/browser-payment-api] editorial: s/fields/members + xref fixes (closes #424) (#443) Marcos Cáceres
• Re: [w3c/browser-payment-api] PaymentApp fails to abort payment flow (#384) Zach Koch
• Re: [w3c/browser-payment-api] PaymentRequest does not handle the case of store pickup (#389) Zach Koch
• Re: [w3c/browser-payment-api] editorial: s/fields/members + xref fixes (closes #424) (#443) Tobie Langel
• Re: [w3c/browser-payment-api] Add billing shipping type (#409) Zach Koch
• Re: [w3c/browser-payment-api] `PaymentInstrument.complete(result)` wording (#402) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: s/user interaction/transaction (closes #402) (#432) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: s/fields/members + xref fixes (closes #424) (#443) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: s/user interaction/transaction (closes #402) (#432) Marcos Cáceres
• Re: [w3c/browser-payment-api] Spec talks about dictionary fields instead of dictionary members (#424) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: s/shown/presented (closes #428) (#435) Marcos Cáceres
• Re: [w3c/browser-payment-api] "Shown" should be "presented" in prose (#428) Marcos Cáceres
• Re: [w3c/browser-payment-api] editorial: s/fields/members + xref fixes (closes #424) (#443) Marcos Cáceres
• Re: [w3c/browser-payment-api] fix: s/user interaction/transaction (closes #402) (#432) Zach Koch
• Re: [w3c/browser-payment-api] editorial: s/shown/presented (closes #428) (#435) Zach Koch
• Re: [w3c/browser-payment-api] editorial: s/fields/members + xref fixes (closes #424) (#443) Zach Koch
• Re: [w3c/browser-payment-api] editorial: s/fields/members + xref fixes (closes #424) (#443) Zach Koch

Wednesday, 1 March 2017

• Re: [w3c/webpayments-payment-apps-api] What is a Payment App? (#105) Adrian Hope-Bailie
• Re: [w3c/webpayments-payment-apps-api] Why does a Payment App need to see the line items? (#91) Manu Sporny
• Re: [w3c/webpayments-payment-apps-api] Why does a Payment App need to see the line items? (#91) Zach Koch
• Re: [w3c/webpayments-payment-apps-api] Why does a Payment App need to see the line items? (#91) frank-hoffmann
• Re: [w3c/browser-payment-api] Fix markup errors that broke autopublishing (#444) Marcos Cáceres
• Re: [w3c/browser-payment-api] Fix markup errors that broke autopublishing (#444) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Fix markup errors that broke autopublishing (#444) Marcos Cáceres
• Re: [w3c/browser-payment-api] Create pr-preview config file. (#445) Marcos Cáceres
• Re: [w3c/browser-payment-api] Create pr-preview config file. (#445) Tobie Langel
• Re: [w3c/browser-payment-api] Create pr-preview config file. (#445) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Create pr-preview config file. (#445) Marcos Cáceres
• Re: [w3c/browser-payment-api] Create pr-preview config file. (#445) Michael[tm] Smith
• Re: [w3c/browser-payment-api] Create pr-preview config file. (#445) Michael[tm] Smith
• Re: [w3c/webpayments-payment-apps-api] Why does a Payment App need to see the line items? (#91) Marcos Cáceres
• Re: [w3c/browser-payment-api] Create pr-preview config file. (#445) Marcos Cáceres
• Re: [w3c/browser-payment-api] Create pr-preview config file. (#445) Marcos Cáceres
• Re: [w3c/browser-payment-api] Fix markup errors that broke autopublishing (#444) Marcos Cáceres
• Re: [w3c/browser-payment-api] Fix markup errors that broke autopublishing (#444) Marcos Cáceres
• Re: [w3c/webpayments-payment-apps-api] What is a Payment App? (#105) Tommy Thorsen
• Re: [w3c/webpayments-payment-apps-api] Why does a Payment App need to see the line items? (#91) Zach Koch
• Re: [w3c/browser-payment-api] fix: delegate total and error member checks to WebIDL (#425) Ben Tian
• Re: [w3c/browser-payment-api] fix: delegate total and error member checks to WebIDL (#425) Marcos Cáceres

Tuesday, 28 February 2017

• Re: [w3c/webpayments-payment-apps-api] Why does a Payment App need to see the line items? (#91) Adrian Hope-Bailie

Last message date: Friday, 31 March 2017 18:12:33 UTC