- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) Manu Sporny (Thursday, 28 January)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) Adrian Hope-Bailie (Thursday, 28 January)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) Manu Sporny (Thursday, 28 January)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) ianbjacobs (Thursday, 28 January)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) Manu Sporny (Thursday, 28 January)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabalized. (#73) Manu Sporny (Thursday, 28 January)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. (#73) ianbjacobs (Thursday, 28 January)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. (#73) Dave Longley (Thursday, 28 January)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. (#73) Adrian Hope-Bailie (Friday, 29 January)
- Re: [webpayments] PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. (#73) Adrian Hope-Bailie (Friday, 29 January)
Dashboard Adrian Hope-Bailie (Wednesday, 27 January)
Process question Adrian Hope-Bailie (Tuesday, 26 January)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) Adrian Hope-Bailie (Saturday, 23 January)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) bifurcation (Saturday, 23 January)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) Manu Sporny (Saturday, 23 January)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) Manu Sporny (Saturday, 23 January)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) Zach Koch (Saturday, 23 January)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) Manu Sporny (Saturday, 23 January)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) Adrian Hope-Bailie (Saturday, 23 January)
- Re: [webpayments] PROPOSAL: The PaymentRequest object will not have code attached to it. It will be a pure data object. (#64) Adrian Hope-Bailie (Wednesday, 27 January)
- Re: [webpayments] PROPOSAL: The PaymentRequest object MUST NOT expose internal state information to the developer. (#64) Manu Sporny (Thursday, 28 January)
- Re: [webpayments] PROPOSAL: The PaymentRequest object MUST NOT expose internal state information to the developer. (#64) Manu Sporny (Thursday, 28 January)
- Re: [webpayments] PROPOSAL: The PaymentRequest object MUST NOT expose internal state information to the developer. (#64) Adrian Hope-Bailie (Thursday, 28 January)
- Re: [webpayments] PROPOSAL: The PaymentRequest object MUST NOT expose internal state information to the developer. (#64) Adrian Hope-Bailie (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) Manu Sporny (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) Manu Sporny (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) Dave Longley (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) Manu Sporny (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) Adrian Hope-Bailie (Friday, 29 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) ianbjacobs (Thursday, 21 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Manu Sporny (Thursday, 21 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Manu Sporny (Thursday, 21 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Zach Koch (Thursday, 21 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Mike West (Friday, 22 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Manu Sporny (Friday, 22 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Manu Sporny (Friday, 22 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Mike West (Friday, 22 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Dave Longley (Friday, 22 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) bifurcation (Friday, 22 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Dave Longley (Friday, 22 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Nick S (Tuesday, 26 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Manu Sporny (Tuesday, 26 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Nick S (Tuesday, 26 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Adrian Hope-Bailie (Tuesday, 26 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Adrian Hope-Bailie (Tuesday, 26 January)
- Re: [webpayments] PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls (#63) Manu Sporny (Wednesday, 27 January)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) Manu Sporny (Thursday, 21 January)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) Adrian Hope-Bailie (Thursday, 21 January)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) mattsaxon (Thursday, 21 January)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) kketels (Thursday, 21 January)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) Manu Sporny (Thursday, 21 January)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) ianbjacobs (Thursday, 21 January)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) Manu Sporny (Thursday, 21 January)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) Adrian Hope-Bailie (Saturday, 23 January)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) Adrian Hope-Bailie (Saturday, 23 January)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) mattsaxon (Monday, 25 January)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) Manu Sporny (Tuesday, 26 January)
- Re: [webpayments] PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate (#62) fredMeignien (Tuesday, 26 January)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) Adrian Hope-Bailie (Wednesday, 20 January)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) Vincent Kuntz (Wednesday, 20 January)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) Dave Longley (Wednesday, 20 January)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) Laurent Castillo (Wednesday, 20 January)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) Nick Telford-Reed (Wednesday, 20 January)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) bifurcation (Wednesday, 20 January)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) ianbjacobs (Wednesday, 20 January)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) mattsaxon (Wednesday, 20 January)
- Re: [webpayments] Terminology for payer/payee, user/merchant, debtor/creditor (#59) Manu Sporny (Thursday, 21 January)
3DS 2.0 Adrian Hope-Bailie (Monday, 18 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) ianbjacobs (Wednesday, 6 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) Adrian Hope-Bailie (Wednesday, 6 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) Manu Sporny (Wednesday, 6 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) Manu Sporny (Wednesday, 6 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) ianbjacobs (Wednesday, 6 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) Manu Sporny (Thursday, 7 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) ianbjacobs (Thursday, 7 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) Manu Sporny (Thursday, 7 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) Manu Sporny (Thursday, 7 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) Manu Sporny (Thursday, 7 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) ianbjacobs (Thursday, 7 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) Manu Sporny (Thursday, 7 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) Manu Sporny (Thursday, 7 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) ianbjacobs (Thursday, 7 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) Manu Sporny (Thursday, 7 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) Dave Longley (Thursday, 7 January)
- Re: [paymentrequest] Should well-known identifiers be used for ubiquitous payment methods (#35) ianbjacobs (Thursday, 7 January)
Last message date: Sunday, 31 January 2016 18:16:34 UTC