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

Ade Bateman

[paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46) (Wednesday, 20 January)
[paymentrequest] Need a "really closed" event (#45) (Wednesday, 20 January)
Re: [paymentrequest] CurrencyAmount description has exponent sign wrong (#39) (Wednesday, 20 January)
Re: [paymentrequest] CurrencyAmount description has exponent sign wrong (#39) (Wednesday, 20 January)
Re: [paymentrequest] Support for "enrollment" use of API (#43) (Wednesday, 20 January)
Re: [paymentrequest] Use navigator.payments rather than creating a new object instance (#42) (Wednesday, 20 January)
Re: [paymentrequest] Minor spec changes based on implementation experience and feedback (#44) (Wednesday, 20 January)
Re: [paymentrequest] Minor spec changes based on implementation experience and feedback (#44) (Wednesday, 20 January)
[paymentrequest] Minor spec changes based on implementation experience and feedback (#44) (Wednesday, 20 January)

Adrian Hope-Bailie

[webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76) (Friday, 29 January)
Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. (#73) (Friday, 29 January)
Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. (#73) (Friday, 29 January)
Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67) (Friday, 29 January)
Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67) (Friday, 29 January)
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, 29 January)
Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57) (Friday, 29 January)
Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57) (Friday, 29 January)
Re: [web-payments-browser-api] Step 6 of the payment flow is incomplete/unclear (#5) (Friday, 29 January)
Re: [webpayments] SEPA SDD one-off e-mandate Version 01 28 2016 (#74) (Friday, 29 January)
Re: [webpayments] Some amendmends (#75) (Friday, 29 January)
[web-payments-browser-api] Step 6 of the payment flow is incomplete/unclear (#5) (Thursday, 28 January)
Re: [webpayments] PROPOSAL: The PaymentRequest object MUST NOT expose internal state information to the developer. (#64) (Thursday, 28 January)
Re: [webpayments] PROPOSAL: The PaymentRequest object MUST NOT expose internal state information to the developer. (#64) (Thursday, 28 January)
Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) (Thursday, 28 January)
Agenda 28 January 17:00 UTC (Wednesday, 27 January)
Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) (Wednesday, 27 January)
[webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) (Wednesday, 27 January)
Dashboard (Wednesday, 27 January)
[webpayments] ACTION: Summarize arguments for/against shipping address capture (#72) (Wednesday, 27 January)
Re: [webpayments] Should we be publishing a specification for an HTTP API? (#17) (Wednesday, 27 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Tuesday, 26 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Tuesday, 26 January)
Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39) (Tuesday, 26 January)
Process question (Tuesday, 26 January)
Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67) (Tuesday, 26 January)
Re: [webpayments] Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app? (#66) (Monday, 25 January)
Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: Hold WG meetings every week until further notice. (#58) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: Hold WG meetings every week until further notice. (#58) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) (Saturday, 23 January)
[webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Saturday, 23 January)
Re: Polyfills/Wireframes for the browser API proposals (Thursday, 21 January)
Re: [paymentrequest] Use navigator.payments rather than creating a new object instance (#42) (Thursday, 21 January)
Re: [paymentrequest] Support for "enrollment" use of API (#43) (Thursday, 21 January)
Re: [paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46) (Thursday, 21 January)
[webpayments] Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app? (#66) (Thursday, 21 January)
[webpayments] How can the API support enrollment (future payment) use cases? (#65) (Thursday, 21 January)
Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39) (Thursday, 21 January)
Updated Agenda for 21 January call (Thursday, 21 January)
Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Thursday, 21 January)
Re: [webpayments] Should a payment request be just data, or a programmable object? (#36) (Thursday, 21 January)
[webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) (Thursday, 21 January)
Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39) (Thursday, 21 January)
[webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Thursday, 21 January)
Re: Polyfills/Wireframes for the browser API proposals (Thursday, 21 January)
Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60) (Wednesday, 20 January)
Additional agenda item for 21 January call (Wednesday, 20 January)
[webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Wednesday, 20 January)
Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57) (Wednesday, 20 January)
Re: [paymentrequest] Minor spec changes based on implementation experience and feedback (#44) (Wednesday, 20 January)
Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Wednesday, 20 January)
[webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Wednesday, 20 January)
Agenda - 21 January - 17:00 UTC (Tuesday, 19 January)
[webpayments] PROPOSAL: Hold WG meetings every week until further notice. (#58) (Tuesday, 19 January)
[webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57) (Tuesday, 19 January)
Re: [webpayments] Adding ISO 20022 definitions highlights for W3C Web Payments WG (#56) (Tuesday, 19 January)
3DS 2.0 (Monday, 18 January)
Polyfills/Wireframes for the browser API proposals (Thursday, 14 January)
[webpayments] What is the appropriate conversational pattern for the API? (#55) (Wednesday, 13 January)
Re: [webpayments] Should the payment request contain line item details? (#38) (Wednesday, 13 January)
Re: [webpayments] Capture proposed work changes in wiki (#50) (Tuesday, 12 January)
Re: [webpayments] Capture proposed work changes in wiki (#50) (Tuesday, 12 January)
Re: Progress rapidification (was Re: Labels and Milestones on GitHub) (Tuesday, 12 January)
Re: Labels and Milestones on GitHub (Friday, 8 January)
Re: Labels and Milestones on GitHub (Friday, 8 January)
Re: Labels and Milestones on GitHub (Thursday, 7 January)
[webpayments] Capture proposed work changes in wiki (#50) (Thursday, 7 January)
[webpayments] Refactor flows to use common terminology and entry/exit points (#49) (Thursday, 7 January)
Labels and Milestones on GitHub (Thursday, 7 January)
Re: [webpayments] Update Apple Pay flow and add Bank Mobile Wallet (#45) (Thursday, 7 January)
Meta-issues for the group (Thursday, 7 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Wednesday, 6 January)

Alessio Basso

Re: [webpayments] Some amendmends (#75) (Sunday, 31 January)
[webpayments] Some amendmends (#75) (Friday, 29 January)

Anders Rundgren

Re: SCAI - update with Credit Transfer and Direct debit flows (Wednesday, 6 January)

bifurcation

Re: [webpayments] Should we be publishing a specification for an HTTP API? (#17) (Wednesday, 27 January)
Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67) (Tuesday, 26 January)
Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Friday, 22 January)
Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Wednesday, 20 January)
Re: [paymentrequest] Use navigator.payments rather than creating a new object instance (#42) (Wednesday, 20 January)
Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57) (Wednesday, 20 January)

Dave Longley

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, 28 January)
Re: [web-payments-browser-api] Step 6 of the payment flow is incomplete/unclear (#5) (Thursday, 28 January)
Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. (#73) (Thursday, 28 January)
Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67) (Tuesday, 26 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Friday, 22 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Friday, 22 January)
Re: [paymentrequest] Use navigator.payments rather than creating a new object instance (#42) (Thursday, 21 January)
Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Wednesday, 20 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Thursday, 7 January)

David Ezell

RE: Concerns around Web Payments HTTP API de-prioritization (Sunday, 31 January)
RE: Agenda: 7 Jan 2016 Web Payments WG call (Thursday, 7 January)

fredMeignien

Re: [webpayments] SEPA SDD one-off e-mandate Version 01 28 2016 (#74) (Thursday, 28 January)
Re: [webpayments] SEPA SDD one-off e-mandate Version 01 28 2016 (#74) (Thursday, 28 January)
[webpayments] SEPA SDD one-off e-mandate Version 01 28 2016 (#74) (Thursday, 28 January)
Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Tuesday, 26 January)

Håvard Molland

Re: Polyfills/Wireframes for the browser API proposals (Wednesday, 27 January)
Re: Polyfills/Wireframes for the browser API proposals (Tuesday, 26 January)

Ian Jacobs

Re: Weekly Web Payments Working Group Meetings - Update your Calendars (Thursday, 28 January)
FYI: Web API Design Cookbook (Friday, 22 January)
Weekly Web Payments Working Group Meetings - Update your Calendars (Thursday, 21 January)
Re: European Banking Authority (EBA) Discussion Paper on strong customer and secure communication under PSD2 (Tuesday, 19 January)
FYI: European Banking Authority (EBA) Discussion Paper on strong customer and secure communication under PSD2 (Monday, 11 January)
FYI: W3C Member review of Web Authentication Working Group Charter until 25 January (Monday, 11 January)
Re: Labels and Milestones on GitHub (Friday, 8 January)
[Minutes] 7 January 2016 call (Thursday, 7 January)
Agenda: 7 Jan 2016 Web Payments WG call (Wednesday, 6 January)

ianbjacobs

Re: [webpayments] Some amendmends (#75) (Sunday, 31 January)
Re: [webpayments] Some amendmends (#75) (Friday, 29 January)
Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. (#73) (Thursday, 28 January)
Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) (Thursday, 28 January)
Re: [webpayments] Should we be publishing a specification for an HTTP API? (#17) (Wednesday, 27 January)
Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Thursday, 21 January)
Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39) (Thursday, 21 January)
Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60) (Thursday, 21 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Thursday, 21 January)
Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60) (Wednesday, 20 January)
Re: [paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46) (Wednesday, 20 January)
Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Wednesday, 20 January)
[webpayments] Security and Privacy Self-Review (#61) (Wednesday, 20 January)
[paymentrequest] Support for "enrollment" use of API (#43) (Wednesday, 13 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Thursday, 7 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Thursday, 7 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Thursday, 7 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Thursday, 7 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Wednesday, 6 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Wednesday, 6 January)

jayrenn

Re: [paymentrequest] Refactor PaymentDetails. (383c224) (Monday, 4 January)
Re: [paymentrequest] Refactor PaymentDetails. (383c224) (Monday, 4 January)

Katie Haritos-Shea GMAIL

RE: Concerns around Web Payments HTTP API de-prioritization (Saturday, 30 January)
RE: Labels and Milestones on GitHub (Thursday, 7 January)

kevingordonwp

Re: [webpayments] Should list of accepted payment methods be strings or objects? (#37) (Tuesday, 5 January)

kketels

Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Thursday, 21 January)

Laurent Castillo

Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Wednesday, 20 January)
[webpayments] Adding ISO 20022 definitions highlights for W3C Web Payments WG (#56) (Tuesday, 19 January)
[webpayments] Update Apple Pay flow and add Bank Mobile Wallet (#45) (Wednesday, 6 January)

Manu Sporny

Concerns around Web Payments HTTP API de-prioritization (Saturday, 30 January)
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, 28 January)
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, 28 January)
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, 28 January)
Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) (Thursday, 28 January)
Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) (Thursday, 28 January)
Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) (Thursday, 28 January)
Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) (Thursday, 28 January)
Re: [webpayments] PROPOSAL: The PaymentRequest object MUST NOT expose internal state information to the developer. (#64) (Thursday, 28 January)
Re: [webpayments] PROPOSAL: The PaymentRequest object MUST NOT expose internal state information to the developer. (#64) (Thursday, 28 January)
Web Payments Community Group Browser API Polyfill Released (Thursday, 28 January)
Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39) (Wednesday, 27 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Wednesday, 27 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Tuesday, 26 January)
Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Tuesday, 26 January)
Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67) (Tuesday, 26 January)
Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: Hold WG meetings every week until further notice. (#58) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Friday, 22 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Friday, 22 January)
Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Thursday, 21 January)
Re: Polyfills/Wireframes for the browser API proposals (Thursday, 21 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Thursday, 21 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Thursday, 21 January)
Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39) (Thursday, 21 January)
Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39) (Thursday, 21 January)
Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Thursday, 21 January)
Re: Updated Agenda for 21 January call (Thursday, 21 January)
Re: Polyfills/Wireframes for the browser API proposals (Thursday, 21 January)
Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39) (Thursday, 21 January)
Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60) (Thursday, 21 January)
Re: [paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46) (Thursday, 21 January)
Re: [paymentrequest] Support for "enrollment" use of API (#43) (Thursday, 21 January)
Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Thursday, 21 January)
Re: Polyfills/Wireframes for the browser API proposals (Thursday, 21 January)
Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Thursday, 21 January)
Re: [webpayments] Should a payment request be just data, or a programmable object? (#36) (Thursday, 21 January)
Re: [webpayments] Should a payment request be just data, or a programmable object? (#36) (Thursday, 21 January)
Progress rapidification (was Re: Labels and Milestones on GitHub) (Tuesday, 12 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Thursday, 7 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Thursday, 7 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Thursday, 7 January)
Re: Labels and Milestones on GitHub (Thursday, 7 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Thursday, 7 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Thursday, 7 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Thursday, 7 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Thursday, 7 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Wednesday, 6 January)
Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Wednesday, 6 January)

mattsaxon

Re: [webpayments] Updated skins for taskforce reviewed flows (#71) (Tuesday, 26 January)
[webpayments] Updated skins for taskforce reviewed flows (#71) (Tuesday, 26 January)
Re: [webpayments] Moved skin from realtime payments into include file (#70) (Tuesday, 26 January)
Re: [webpayments] Moved skin from realtime payments into include file (#70) (Monday, 25 January)
[webpayments] Moved skin from realtime payments into include file (#70) (Monday, 25 January)
Re: [webpayments] Added Skin file, participant name changes to ISO20022 (#69) (Monday, 25 January)
[webpayments] Added Skin file, participant name changes to ISO20022 (#69) (Monday, 25 January)
Re: [webpayments] Updated 3DS flow with extra detail (#68) (Monday, 25 January)
[webpayments] Updated 3DS flow with extra detail (#68) (Monday, 25 January)
Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Monday, 25 January)
Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) (Thursday, 21 January)
Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Wednesday, 20 January)
Re: [paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46) (Wednesday, 20 January)
Re: [paymentrequest] Support for "enrollment" use of API (#43) (Wednesday, 20 January)
Re: [webpayments] Patch 1 (#54) (Sunday, 10 January)
Re: [webpayments] Separated PayPal flow into standard and PSP intermediated following discussions with Dave (#53) (Sunday, 10 January)
[webpayments] Separated PayPal flow into standard and PSP intermediated following discussions with Dave (#53) (Sunday, 10 January)
Re: [webpayments] Updated PayPal with annotation based on Dave's feedback (#52) (Saturday, 9 January)
[webpayments] Updated PayPal with annotation based on Dave's feedback (#52) (Saturday, 9 January)
Re: [webpayments] Updated Authentication to read Authorisation (#51) (Friday, 8 January)
[webpayments] Updated Authentication to read Authorisation (#51) (Friday, 8 January)
Re: [webpayments] Updated PayPal to correct redirect and add notifications (#48) (Wednesday, 6 January)
[webpayments] Updated PayPal to correct redirect and add notifications (#48) (Wednesday, 6 January)
Re: [webpayments] Added Cross Border, minor revisions to RealTime payment (#47) (Wednesday, 6 January)
[webpayments] Added Cross Border, minor revisions to RealTime payment (#47) (Wednesday, 6 January)
Re: [webpayments] Gh pages (#46) (Wednesday, 6 January)
[webpayments] Gh pages (#46) (Wednesday, 6 January)

Mike West

Mountie Lee

Re: Agenda 28 January 17:00 UTC (Thursday, 28 January)

mountielee

[webpayments] Patch 1 (#54) (Sunday, 10 January)

Nick S

Nick Shearer

Re: Agenda 28 January 17:00 UTC (Thursday, 28 January)

Nick Telford-Reed

Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Wednesday, 20 January)

Stefan Thomas

Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) (Wednesday, 6 January)

Telford-Reed, Nick

RE: Agenda - 21 January - 17:00 UTC (Wednesday, 20 January)
RE: Progress rapidification (was Re: Labels and Milestones on GitHub) (Tuesday, 12 January)

VIGNET cyril

RE: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Wednesday, 20 January)
RE: European Banking Authority (EBA) Discussion Paper on strong customer and secure communication under PSD2 (Tuesday, 12 January)
RE: SCAI - update with Credit Transfer and Direct debit flows (Thursday, 7 January)
SCAI - update with Credit Transfer and Direct debit flows (Monday, 4 January)

Vincent Kuntz

Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) (Wednesday, 20 January)
[webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60) (Wednesday, 20 January)

Web Payments Working Group Issue Tracker

wpwg-ACTION-12: Contact the ig chairs about taking up the terms (Thursday, 28 January)
wpwg-ACTION-11: Ping mountie about samsung and escrow flows (Thursday, 7 January)

Zach Koch

Re: Polyfills/Wireframes for the browser API proposals (Tuesday, 26 January)
Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) (Saturday, 23 January)
Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) (Thursday, 21 January)
Re: [paymentrequest] Minor spec changes based on implementation experience and feedback (#44) (Wednesday, 20 January)
Re: [paymentrequest] Minor spec changes based on implementation experience and feedback (#44) (Wednesday, 20 January)
Re: [paymentrequest] Minor spec changes based on implementation experience and feedback (#44) (Wednesday, 20 January)

Last message date: Sunday, 31 January 2016 18:16:34 UTC