Sunday, 31 January 2016
- RE: Concerns around Web Payments HTTP API de-prioritization
- Re: [webpayments] Some amendmends (#75)
- Re: [webpayments] Some amendmends (#75)
Saturday, 30 January 2016
- RE: Concerns around Web Payments HTTP API de-prioritization
- Concerns around Web Payments HTTP API de-prioritization
Friday, 29 January 2016
- Re: [webpayments] Some amendmends (#75)
- [webpayments] Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? (#76)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. (#73)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. (#73)
- Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67)
- Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67)
- 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)
- Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57)
- Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57)
- Re: [web-payments-browser-api] Step 6 of the payment flow is incomplete/unclear (#5)
- Re: [webpayments] SEPA SDD one-off e-mandate Version 01 28 2016 (#74)
- Re: [webpayments] Some amendmends (#75)
- [webpayments] Some amendmends (#75)
Thursday, 28 January 2016
- wpwg-ACTION-12: Contact the ig chairs about taking up the terms
- Re: Weekly Web Payments Working Group Meetings - Update your Calendars
- 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)
- 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)
- Re: [web-payments-browser-api] Step 6 of the payment flow is incomplete/unclear (#5)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. (#73)
- 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)
- 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)
- [web-payments-browser-api] Step 6 of the payment flow is incomplete/unclear (#5)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. (#73)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73)
- Re: [webpayments] SEPA SDD one-off e-mandate Version 01 28 2016 (#74)
- Re: [webpayments] SEPA SDD one-off e-mandate Version 01 28 2016 (#74)
- [webpayments] SEPA SDD one-off e-mandate Version 01 28 2016 (#74)
- Re: [webpayments] PROPOSAL: The PaymentRequest object MUST NOT expose internal state information to the developer. (#64)
- Re: [webpayments] PROPOSAL: The PaymentRequest object MUST NOT expose internal state information to the developer. (#64)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73)
- Re: [webpayments] PROPOSAL: The PaymentRequest object MUST NOT expose internal state information to the developer. (#64)
- Re: [webpayments] PROPOSAL: The PaymentRequest object MUST NOT expose internal state information to the developer. (#64)
- Web Payments Community Group Browser API Polyfill Released
- Re: Agenda 28 January 17:00 UTC
- Re: Agenda 28 January 17:00 UTC
Wednesday, 27 January 2016
- Agenda 28 January 17:00 UTC
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64)
- [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73)
- Dashboard
- Re: [webpayments] Should we be publishing a specification for an HTTP API? (#17)
- Re: Polyfills/Wireframes for the browser API proposals
- Re: [webpayments] Should we be publishing a specification for an HTTP API? (#17)
- [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72)
- Re: [webpayments] Should we be publishing a specification for an HTTP API? (#17)
- Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
Tuesday, 26 January 2016
- Re: [webpayments] Updated skins for taskforce reviewed flows (#71)
- [webpayments] Updated skins for taskforce reviewed flows (#71)
- Re: Polyfills/Wireframes for the browser API proposals
- Re: [webpayments] Moved skin from realtime payments into include file (#70)
- Re: Polyfills/Wireframes for the browser API proposals
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39)
- Process question
- Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
- Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67)
Monday, 25 January 2016
- Re: [webpayments] Moved skin from realtime payments into include file (#70)
- [webpayments] Moved skin from realtime payments into include file (#70)
- Re: [webpayments] Added Skin file, participant name changes to ISO20022 (#69)
- [webpayments] Added Skin file, participant name changes to ISO20022 (#69)
- Re: [webpayments] Updated 3DS flow with extra detail (#68)
- [webpayments] Updated 3DS flow with extra detail (#68)
- Re: [webpayments] Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app? (#66)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
Saturday, 23 January 2016
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64)
- Re: [webpayments] PROPOSAL: Hold WG meetings every week until further notice. (#58)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64)
- Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57)
- Re: [webpayments] PROPOSAL: Hold WG meetings every week until further notice. (#58)
- Re: [webpayments] PROPOSAL: Hold WG meetings every week until further notice. (#58)
- Re: [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64)
- [webpayments] PROPOSAL: Adopt developer friendly-terminology for WG deliverables but root this in ISO20022 data dictionary through our published glossary. (#67)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
Friday, 22 January 2016
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- FYI: Web API Design Cookbook
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
Thursday, 21 January 2016
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
- Weekly Web Payments Working Group Meetings - Update your Calendars
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
- Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: Polyfills/Wireframes for the browser API proposals
- Re: [paymentrequest] Use navigator.payments rather than creating a new object instance (#42)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39)
- Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39)
- Re: Polyfills/Wireframes for the browser API proposals
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
- Re: Updated Agenda for 21 January call
- Re: Polyfills/Wireframes for the browser API proposals
- Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: [paymentrequest] Use navigator.payments rather than creating a new object instance (#42)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
- Re: [paymentrequest] Support for "enrollment" use of API (#43)
- Re: [paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46)
- [webpayments] Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app? (#66)
- [webpayments] How can the API support enrollment (future payment) use cases? (#65)
- Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39)
- Updated Agenda for 21 January call
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
- Re: [webpayments] Should a payment request be just data, or a programmable object? (#36)
- [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64)
- Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39)
- [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63)
- Re: Polyfills/Wireframes for the browser API proposals
- Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39)
- Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60)
- Re: [paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46)
- Re: [paymentrequest] Support for "enrollment" use of API (#43)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59)
- Re: Polyfills/Wireframes for the browser API proposals
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
- Re: [webpayments] Should a payment request be just data, or a programmable object? (#36)
- Re: [webpayments] Should a payment request be just data, or a programmable object? (#36)
Wednesday, 20 January 2016
- Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60)
- Additional agenda item for 21 January call
- [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62)
- Re: [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60)
- Re: [paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59)
- Re: [paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46)
- Re: [paymentrequest] Support for "enrollment" use of API (#43)
- Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57)
- RE: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59)
- Re: [paymentrequest] Use navigator.payments rather than creating a new object instance (#42)
- RE: Agenda - 21 January - 17:00 UTC
- Re: [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59)
- [paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46)
- [paymentrequest] Need a "really closed" event (#45)
- Re: [paymentrequest] CurrencyAmount description has exponent sign wrong (#39)
- Re: [paymentrequest] CurrencyAmount description has exponent sign wrong (#39)
- [webpayments] Security and Privacy Self-Review (#61)
- Re: [paymentrequest] Support for "enrollment" use of API (#43)
- Re: [paymentrequest] Use navigator.payments rather than creating a new object instance (#42)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59)
- Re: [paymentrequest] Minor spec changes based on implementation experience and feedback (#44)
- Re: [paymentrequest] Minor spec changes based on implementation experience and feedback (#44)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59)
- [webpayments] Should the Web Payments API cater for the invoicing part of the full web purchase flow ? (#60)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59)
- [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59)
- Re: [paymentrequest] Minor spec changes based on implementation experience and feedback (#44)
- Re: [paymentrequest] Minor spec changes based on implementation experience and feedback (#44)
- Re: [paymentrequest] Minor spec changes based on implementation experience and feedback (#44)
- Re: [paymentrequest] Minor spec changes based on implementation experience and feedback (#44)
- [paymentrequest] Minor spec changes based on implementation experience and feedback (#44)
Tuesday, 19 January 2016
- Agenda - 21 January - 17:00 UTC
- [webpayments] PROPOSAL: Hold WG meetings every week until further notice. (#58)
- [webpayments] PROPOSAL: Use strings to represent currency and amount per ISO20022 (#57)
- Re: European Banking Authority (EBA) Discussion Paper on strong customer and secure communication under PSD2
- Re: [webpayments] Adding ISO 20022 definitions highlights for W3C Web Payments WG (#56)
- [webpayments] Adding ISO 20022 definitions highlights for W3C Web Payments WG (#56)
Monday, 18 January 2016
Thursday, 14 January 2016
Wednesday, 13 January 2016
- [paymentrequest] Support for "enrollment" use of API (#43)
- [webpayments] What is the appropriate conversational pattern for the API? (#55)
- Re: [webpayments] Should the payment request contain line item details? (#38)
Tuesday, 12 January 2016
- RE: European Banking Authority (EBA) Discussion Paper on strong customer and secure communication under PSD2
- RE: Progress rapidification (was Re: Labels and Milestones on GitHub)
- Re: [webpayments] Capture proposed work changes in wiki (#50)
- Re: [webpayments] Capture proposed work changes in wiki (#50)
- Re: Progress rapidification (was Re: Labels and Milestones on GitHub)
- Progress rapidification (was Re: Labels and Milestones on GitHub)
Monday, 11 January 2016
- FYI: European Banking Authority (EBA) Discussion Paper on strong customer and secure communication under PSD2
- FYI: W3C Member review of Web Authentication Working Group Charter until 25 January
Sunday, 10 January 2016
- Re: [webpayments] Patch 1 (#54)
- [webpayments] Patch 1 (#54)
- Re: [webpayments] Separated PayPal flow into standard and PSP intermediated following discussions with Dave (#53)
- [webpayments] Separated PayPal flow into standard and PSP intermediated following discussions with Dave (#53)
Saturday, 9 January 2016
- Re: [webpayments] Updated PayPal with annotation based on Dave's feedback (#52)
- [webpayments] Updated PayPal with annotation based on Dave's feedback (#52)
Friday, 8 January 2016
- Re: Labels and Milestones on GitHub
- Re: Labels and Milestones on GitHub
- Re: Labels and Milestones on GitHub
- Re: [webpayments] Updated Authentication to read Authorisation (#51)
- [webpayments] Updated Authentication to read Authorisation (#51)
Thursday, 7 January 2016
- [Minutes] 7 January 2016 call
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: Labels and Milestones on GitHub
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: Labels and Milestones on GitHub
- [webpayments] Capture proposed work changes in wiki (#50)
- [webpayments] Refactor flows to use common terminology and entry/exit points (#49)
- wpwg-ACTION-11: Ping mountie about samsung and escrow flows
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- RE: Agenda: 7 Jan 2016 Web Payments WG call
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- RE: Labels and Milestones on GitHub
- Labels and Milestones on GitHub
- Re: [webpayments] Update Apple Pay flow and add Bank Mobile Wallet (#45)
- RE: SCAI - update with Credit Transfer and Direct debit flows
- Meta-issues for the group
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
Wednesday, 6 January 2016
- Re: [webpayments] Updated PayPal to correct redirect and add notifications (#48)
- [webpayments] Updated PayPal to correct redirect and add notifications (#48)
- Re: [webpayments] Added Cross Border, minor revisions to RealTime payment (#47)
- [webpayments] Added Cross Border, minor revisions to RealTime payment (#47)
- Agenda: 7 Jan 2016 Web Payments WG call
- Re: [webpayments] Gh pages (#46)
- [webpayments] Gh pages (#46)
- [webpayments] Update Apple Pay flow and add Bank Mobile Wallet (#45)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35)
- Re: SCAI - update with Credit Transfer and Direct debit flows