Web Payments Working Group - Activity in 2016
No matches.
TR publications
-
9 documents published.
-
Basic Card Payment published twice as a Working Draft. History of Basic Card Payment
-
Payment Request API published 6 times as a Working Draft. History of Payment Request API
-
Payment Method Identifiers published as a Working Draft. History of Payment Method Identifiers
-
GitHub
w3c/payment-request
-
17 issues opened.
-
Adding dialog close event w3c/payment-request#387, by @rvm4.
-
ReSpec error viewing the spec w3c/payment-request#386, by @domenic.
-
Serializer behavior w3c/payment-request#385, by @rsolomakhin.
-
PaymentApp fails to abort payment flow w3c/payment-request#384, by @maheshkk.
-
Introductory explanations of methods should be non-normative notes w3c/payment-request#379, by @domenic.
-
Editorial: refer to methods with parentheses for clarity, and spell out their params in their definition w3c/payment-request#378, by @domenic.
-
Editorial: don't capitalize RFC 2119 terms w3c/payment-request#377, by @domenic.
-
Editorial: define and link to the different states w3c/payment-request#376, by @domenic.
-
Editorial: use new language for DOMExceptions w3c/payment-request#375, by @domenic.
-
PaymentRequest constructor validation ordering does not match Blink at all w3c/payment-request#373, by @domenic.
-
waitForUpdate is not defined w3c/payment-request#371, by @domenic.
-
What is the mechanism for limiting repeated calls to canMakePayments ? w3c/payment-request#367, by @ianbjacobs.
-
"allowed to use" check is incorrect w3c/payment-request#363, by @bzbarsky.
-
There is no concept of "called from" some browsing context w3c/payment-request#362, by @bzbarsky.
-
Security hole in payment API when a constructor from a no longer active document is invoked w3c/payment-request#361, by @bzbarsky.
-
Need to define the interaction of payment API with navigation and browsing context destruction w3c/payment-request#360, by @bzbarsky.
-
-
20 issues closed.
-
Adding dialog close event w3c/payment-request#387.
-
ReSpec error viewing the spec w3c/payment-request#386.
-
Add canMakePayment() function to PaymentRequest object. w3c/payment-request#310.
-
The shippingOptions field is used in more cases than the spec claims, as far as I can tell w3c/payment-request#345.
-
The target of a PaymentRequestUpdateEvent may not be a PaymentRequest object w3c/payment-request#347.
-
Please define your internal slot notation before using it w3c/payment-request#336.
-
"asynchronously perform the remaining steps" is not defined w3c/payment-request#341.
-
"store" value in [[internalSlot]] w3c/payment-request#353.
-
What is "the script calling the constructor"? w3c/payment-request#323.
-
There is no concept of "called from" some browsing context w3c/payment-request#362.
-
"allowed to use" check is incorrect w3c/payment-request#363.
-
Send HTMLIFrameElement.allowPaymentRequest to HTML spec w3c/payment-request#311.
-
Browsing contexts don't have an "origin" w3c/payment-request#324.
-
The origin restrictions in the PaymentRequest are not nearly strong enough w3c/payment-request#332.
-
What does it mean for a user agent to validate displayItems? w3c/payment-request#344.
-
PaymentRequest constructor errors should be properly annotated w3c/payment-request#290.
-
enum PaymentComplete's "" w3c/payment-request#308.
-
-
1 issue reopened.
-
What is the mechanism for limiting repeated calls to canMakePayments ? w3c/payment-request#367, by @ianbjacobs.
-
-
30 issues received 132 new comments.
-
The "data" member of PaymentMethodData doesn't seem to actually be used for anything w3c/payment-request#338 (21 comments by @delapuente, @dlongley, @domenic, @rsolomakhin)
-
The myth of JSON-serializable object w3c/payment-request#307 (20 comments by @bzbarsky, @domenic, @littledan, @RByers, @rsolomakhin, @zkoch)
-
Making this API work with HTML Forms w3c/payment-request#330 (12 comments by @adrianba, @adrianhopebailie, @marcoscaceres, @rsolomakhin, @zkoch)
-
Security hole in payment API when a constructor from a no longer active document is invoked w3c/payment-request#361 (9 comments by @bzbarsky, @rsolomakhin, @zcorpan)
-
There is no concept of "called from" some browsing context w3c/payment-request#362 (6 comments by @adrianba, @annevk, @bzbarsky)
-
Why is the "shippingType" member of PaymentOptions not a PaymentShippingType? w3c/payment-request#337 (5 comments by @domenic, @zkoch)
-
The "data" member of PaymentDetailsModifier doesn't seem to be used for anything w3c/payment-request#346 (5 comments by @bzbarsky, @ianbjacobs, @nickjshearer, @rsolomakhin)
-
Adding dialog close event w3c/payment-request#387 (4 comments by @rsolomakhin, @rvm4, @webpayments-specs)
-
The shippingOptions field is used in more cases than the spec claims, as far as I can tell w3c/payment-request#345 (4 comments by @bzbarsky, @domenic, @zkoch)
-
PaymentDetails "total" member should be required w3c/payment-request#320 (4 comments by @bzbarsky, @domenic, @foolip)
-
Send HTMLIFrameElement.allowPaymentRequest to HTML spec w3c/payment-request#311 (4 comments by @ojanvafai, @sideshowbarker, @zkoch)
-
The origin restrictions in the PaymentRequest are not nearly strong enough w3c/payment-request#332 (4 comments by @adrianhopebailie, @bzbarsky)
-
The "if d is resolved" section of updateWith needs to be more explicit about how it gets a PaymentDetails dictionary w3c/payment-request#349 (3 comments by @bzbarsky, @domenic)
-
PaymentOptions seems overly verbose/overlaps with HTML w3c/payment-request#326 (3 comments by @marcoscaceres, @zkoch)
-
How are currency systems expected to be implemented in practice? w3c/payment-request#343 (3 comments by @marcoscaceres, @zkoch)
-
How are digital signatures supported for Payment Requests? w3c/payment-request#291 (2 comments by @adrianhopebailie, @msporny)
-
Need to define the interaction of payment API with navigation and browsing context destruction w3c/payment-request#360 (2 comments by @bzbarsky, @rsolomakhin)
-
PaymentApp fails to abort payment flow w3c/payment-request#384 (2 comments by @ianbjacobs, @rsolomakhin)
-
What is "the script calling the constructor"? w3c/payment-request#323 (2 comments by @domenic, @sideshowbarker)
-
What does it mean for a user agent to validate displayItems? w3c/payment-request#344 (2 comments by @marcoscaceres, @zkoch)
-
What is the mechanism for limiting repeated calls to canMakePayments ? w3c/payment-request#367 (1 comment by @ianbjacobs)
-
Why does PaymentRequest constructor throw on details.error w3c/payment-request#302 (1 comment by @domenic)
-
updateWith will silently ignore data in hard-to-debug ways w3c/payment-request#350 (1 comment by @domenic)
-
Setting internal slots of objects from asynchronous steps is not OK w3c/payment-request#339 (1 comment by @domenic)
-
Add canMakePayment() function to PaymentRequest object. w3c/payment-request#310 (1 comment by @ianbjacobs)
-
Explicitly state any cases where an iframe with an allowpaymentrequest attribute is not allowed to make payment requests w3c/payment-request#358 (1 comment by @sideshowbarker)
-
-
15 pull requests opened.
-
Invoke "allowed to use" always w3c/payment-request#383, by @zcorpan.
-
Straighten out the payment method data flow w3c/payment-request#382, by @domenic.
-
Validate payment method data w3c/payment-request#381, by @domenic.
-
Add canMakePayment() method w3c/payment-request#380, by @domenic.
-
Various fixes to the PaymentRequest constructor w3c/payment-request#374, by @domenic.
-
Various fixes to updateWith w3c/payment-request#372, by @domenic.
-
Switch internal slot notation to ., not @ w3c/payment-request#370, by @domenic.
-
In parallel w3c/payment-request#369, by @domenic.
-
Minor typographical fixes w3c/payment-request#368, by @domenic.
-
Use current settings object. w3c/payment-request#366, by @adrianba.
-
Add `enableLegacyCheckout` option to PaymentOptions. w3c/payment-request#365, by @dlongley.
-
Update allowed to use check. w3c/payment-request#364, by @adrianba.
-
Reference W3C HTML for allowpaymentrequest definition w3c/payment-request#359, by @sideshowbarker.
-
fix: don't validate display items (closes #344) w3c/payment-request#357, by @marcoscaceres.
-
Change "SHOULD NEVER" to "MUST NOT" w3c/payment-request#356, by @ianbjacobs.
-
-
14 pull requests merged.
-
Introduce paymenRequestID w3c/payment-request#292.
-
Add canMakePayment() method w3c/payment-request#380.
-
Various fixes to updateWith w3c/payment-request#372.
-
Change "SHOULD NEVER" to "MUST NOT" w3c/payment-request#356.
-
Switch internal slot notation to ., not @ w3c/payment-request#370.
-
In parallel w3c/payment-request#369.
-
Minor typographical fixes w3c/payment-request#368.
-
Use current settings object. w3c/payment-request#366.
-
Update allowed to use check. w3c/payment-request#364.
-
editorial: clarify examples w3c/payment-request#329.
-
Reference W3C HTML for allowpaymentrequest definition w3c/payment-request#359.
-
fix: don't validate display items (closes #344) w3c/payment-request#357.
-
editorial: PaymentRequest ctor, describe errors (closes #290) w3c/payment-request#355.
-
normative(PaymentComplete): replace '' with 'unknown' (closes #308) w3c/payment-request#312.
-
-
2 pull requests closed.
-
Detecting Payment Method Availability w3c/payment-request#316.
-
Validate payment method data w3c/payment-request#381.
-
-
14 pull requests received 90 new comments.
-
Detecting Payment Method Availability w3c/payment-request#316 (25 comments by @adamroach, @burdges, @dlongley, @ianbjacobs, @lyverovski, @maheshkk, @marcoscaceres, @mattdevaney, @rsolomakhin, @zkoch)
-
Add `enableLegacyCheckout` option to PaymentOptions. w3c/payment-request#365 (11 comments by @dlongley, @ianbjacobs, @lyverovski, @marcoscaceres, @nickjshearer, @rsolomakhin)
-
Reference W3C HTML for allowpaymentrequest definition w3c/payment-request#359 (10 comments by @rsolomakhin, @sideshowbarker, @zcorpan)
-
Various fixes to the PaymentRequest constructor w3c/payment-request#374 (8 comments by @adrianba, @domenic, @marcoscaceres)
-
Change "SHOULD NEVER" to "MUST NOT" w3c/payment-request#356 (8 comments by @ianbjacobs, @marcoscaceres, @sideshowbarker)
-
Invoke "allowed to use" always w3c/payment-request#383 (7 comments by @bzbarsky, @clelland, @rsolomakhin, @zcorpan)
-
Various fixes to updateWith w3c/payment-request#372 (6 comments by @domenic, @marcoscaceres, @zkoch)
-
Straighten out the payment method data flow w3c/payment-request#382 (4 comments by @adrianba, @domenic)
-
Add canMakePayment() method w3c/payment-request#380 (3 comments by @burdges, @domenic, @rsolomakhin)
-
w3c/web-based-payment-handler
-
2 issues opened.
-
Recommended payment apps w3c/web-based-payment-handler#74, by @rsolomakhin.
-
Need to specify behavior for Clients.openWindow w3c/web-based-payment-handler#73, by @rsolomakhin.
-
-
2 issues closed.
-
Pass along a Transaction ID w3c/web-based-payment-handler#47.
-
Should payment instrument details be included at registration? w3c/web-based-payment-handler#12.
-
-
5 issues received 9 new comments.
-
Should payment apps implement payment method-specific filters? w3c/web-based-payment-handler#63 (4 comments by @ianbjacobs, @rsolomakhin)
-
Need to specify behavior for Clients.openWindow w3c/web-based-payment-handler#73 (1 comment by @tommythorsen)
-
Should payment instrument details be included at registration? w3c/web-based-payment-handler#12 (1 comment by @ianbjacobs)
-
-
4 pull requests opened.
-
(Deleted this edit by mistake before merged) w3c/web-based-payment-handler#78, by @ianbjacobs.
-
Updated intro on display of apps and openWindow w3c/web-based-payment-handler#77, by @ianbjacobs.
-
Lambda functions for app matching w3c/web-based-payment-handler#76, by @adamroach.
-
added link to issue 73 w3c/web-based-payment-handler#75, by @ianbjacobs.
-
-
2 pull requests merged.
-
added link to issue 73 w3c/web-based-payment-handler#75.
-
Edited specification to remove notions of open/proprietary w3c/web-based-payment-handler#70.
-
-
1 pull request closed.
-
Updated intro on display of apps and openWindow w3c/web-based-payment-handler#77.
-
-
2 pull requests received 5 new comments.
-
Lambda functions for app matching w3c/web-based-payment-handler#76 (4 comments by @adrianhopebailie, @dlongley, @ianbjacobs, @rsolomakhin)
-
Updated intro on display of apps and openWindow w3c/web-based-payment-handler#77 (1 comment by @ianbjacobs)
-
w3c/payment-method-id
-
1 issue opened.
-
How should we address payment method manifest files? w3c/payment-method-id#19, by @ianbjacobs.
-
-
6 issues closed.
-
Schema.org PaymentMethod as namespace for short strings w3c/payment-method-id#13.
-
Resolve whether browsers need to police payment app claims of supported methods w3c/payment-method-id#11.
-
PROPOSAL: PMI identifies payment method specification, use meta-data for additional granularity w3c/payment-method-id#5.
-
Should we define nesting/grouping semantics for payment method identifier matching? w3c/payment-method-id#1.
-
Should a payment method identifier (URL) resolve to a machine readable resource that describes it? w3c/payment-method-id#3.
-
-
8 issues received 13 new comments.
-
How should we address payment method manifest files? w3c/payment-method-id#19 (4 comments by @adamroach, @adrianhopebailie, @halindrome, @zkoch)
-
Support for PMI's with schemes other than https? w3c/payment-method-id#17 (3 comments by @marcoscaceres, @rsolomakhin)
-
Schema.org PaymentMethod as namespace for short strings w3c/payment-method-id#13 (1 comment by @ianbjacobs)
-
Should a payment method identifier that is a URL bind that payment method to a single payment app or origin? w3c/payment-method-id#12 (1 comment by @ianbjacobs)
-
Resolve whether browsers need to police payment app claims of supported methods w3c/payment-method-id#11 (1 comment by @ianbjacobs)
-
PROPOSAL: PMI identifies payment method specification, use meta-data for additional granularity w3c/payment-method-id#5 (1 comment by @ianbjacobs)
-
Should we define nesting/grouping semantics for payment method identifier matching? w3c/payment-method-id#1 (1 comment by @ianbjacobs)
-
Should a payment method identifier (URL) resolve to a machine readable resource that describes it? w3c/payment-method-id#3 (1 comment by @ianbjacobs)
-
w3c/webpayments
-
3 issues closed.
-
Should payment method specifications contain WebIDL? w3c/webpayments#133.
-
How should the group update documents in 'TR' space? w3c/webpayments#167.
-
-
3 issues received 3 new comments.
-
[Payment Request] Should we allow a "polling" mechanism for websites to not invoke the API if there are no enabled methods w3c/webpayments#159 (1 comment by @ianbjacobs)
-
8 pull requests opened.
-
Operational considerations w3c/webpayments#201, by @ianbjacobs.
-
Updated links on README w3c/webpayments#200, by @ianbjacobs.
-
Added tokenized cards link w3c/webpayments#199, by @ianbjacobs.
-
try again issue 19 w3c/webpayments#198, by @ianbjacobs.
-
Add link to issue 19 w3c/webpayments#197, by @ianbjacobs.
-
comma fix w3c/webpayments#196, by @ianbjacobs.
-
Big reorg w3c/webpayments#195, by @ianbjacobs.
-
updated proposals home page w3c/webpayments#194, by @ianbjacobs.
-
-
8 pull requests merged.
-
Operational considerations w3c/webpayments#201.
-
Updated links on README w3c/webpayments#200.
-
Added tokenized cards link w3c/webpayments#199.
-
try again issue 19 w3c/webpayments#198.
-
Add link to issue 19 w3c/webpayments#197.
-
comma fix w3c/webpayments#196.
-
Big reorg w3c/webpayments#195.
-
updated proposals home page w3c/webpayments#194.
-
Participants
-
1 participant joined.
-
Olivier Yiptong (Airbnb Inc) joined.
-
-
3 organizations joined.
-
Stripe joined.
-
Shift4 Corporation joined.
-
Klarna joined.
-
GitHub
w3c/payment-request
-
49 issues opened.
-
Ambiguous conformance requirement in constructor w3c/payment-request#354, by @marcoscaceres.
-
"store" value in [[internalSlot]] w3c/payment-request#353, by @marcoscaceres.
-
What is the shippingAddress/shippingOption of a PaymentResponse if requestShipping was false? w3c/payment-request#352, by @bzbarsky.
-
The shipping address/option changed algorithms should not be synchronously poking internal slots w3c/payment-request#351, by @bzbarsky.
-
updateWith will silently ignore data in hard-to-debug ways w3c/payment-request#350, by @bzbarsky.
-
The target of a PaymentRequestUpdateEvent may not be a PaymentRequest object w3c/payment-request#347, by @bzbarsky.
-
The "data" member of PaymentDetailsModifier doesn't seem to be used for anything w3c/payment-request#346, by @bzbarsky.
-
The shippingOptions field is used in more cases than the spec claims, as far as I can tell w3c/payment-request#345, by @bzbarsky.
-
What does it mean for a user agent to validate displayItems? w3c/payment-request#344, by @bzbarsky.
-
How are currency systems expected to be implemented in practice? w3c/payment-request#343, by @bzbarsky.
-
Is section 3.4 informative or normative? w3c/payment-request#342, by @bzbarsky.
-
"asynchronously perform the remaining steps" is not defined w3c/payment-request#341, by @bzbarsky.
-
Is it intended that abort() rejects the acceptPromise and resolves its return value in separate tasks? w3c/payment-request#340, by @bzbarsky.
-
Setting internal slots of objects from asynchronous steps is not OK w3c/payment-request#339, by @bzbarsky.
-
The "data" member of PaymentMethodData doesn't seem to actually be used for anything w3c/payment-request#338, by @bzbarsky.
-
Why is the "shippingType" member of PaymentOptions not a PaymentShippingType? w3c/payment-request#337, by @bzbarsky.
-
Please define your internal slot notation before using it w3c/payment-request#336, by @bzbarsky.
-
A PaymentDetailsModifier may not have an additionalDisplayItems value present w3c/payment-request#335, by @bzbarsky.
-
A `PaymentItem` can't be a "valid decimal monetary value" w3c/payment-request#334, by @bzbarsky.
-
The origin restrictions in the PaymentRequest are not nearly strong enough w3c/payment-request#332, by @bzbarsky.
-
Collect Privacy and Security considerations w3c/payment-request#331, by @marcoscaceres.
-
Making this API work with HTML Forms w3c/payment-request#330, by @marcoscaceres.
-
PaymentResponse's details could lead to problems w3c/payment-request#328, by @marcoscaceres.
-
Add dir/lang member on dictionaries whose content is displayed in browser UI w3c/payment-request#327, by @marcoscaceres.
-
PaymentOptions seems overly verbose/overlaps with HTML w3c/payment-request#326, by @marcoscaceres.
-
Should values for supportedNetworks be defined in Basic Card or separately? w3c/payment-request#325, by @ianbjacobs.
-
Browsing contexts don't have an "origin" w3c/payment-request#324, by @bzbarsky.
-
What is "the script calling the constructor"? w3c/payment-request#323, by @bzbarsky.
-
DOMStrings don't contain "characters" w3c/payment-request#322, by @bzbarsky.
-
"contains a value for" isn't defined for dictionaries w3c/payment-request#321, by @bzbarsky.
-
PaymentDetails "total" member should be required w3c/payment-request#320, by @bzbarsky.
-
DOMExceptions are now in WebIDL w3c/payment-request#314, by @marcoscaceres.
-
Send HTMLIFrameElement.allowPaymentRequest to HTML spec w3c/payment-request#311, by @marcoscaceres.
-
Add canMakePayment() function to PaymentRequest object. w3c/payment-request#310, by @rsolomakhin.
-
Behavior for multiple modifiers for the same payment method is not defined w3c/payment-request#309, by @nickjshearer.
-
enum PaymentComplete's "" w3c/payment-request#308, by @marcoscaceres.
-
The myth of JSON-serializable object w3c/payment-request#307, by @marcoscaceres.
-
PaymentRequest type checks (valid non-negative monetary value) w3c/payment-request#306, by @marcoscaceres.
-
currencySystem seems like a recipe for interop hell w3c/payment-request#305, by @marcoscaceres.
-
valid decimal monetary value maybe overly restrictive w3c/payment-request#304, by @marcoscaceres.
-
"valid decimal monetary value" should move to its own section w3c/payment-request#303, by @marcoscaceres.
-
Why does PaymentRequest constructor throw on details.error w3c/payment-request#302, by @marcoscaceres.
-
Use HTML's (or infra) definition of “valid decimal monetary value”, once available w3c/payment-request#301, by @marcoscaceres.
-
Should PaymentDetails.total be marked as required in IDL? w3c/payment-request#300, by @marcoscaceres.
-
PaymentAddress should be a dictionary w3c/payment-request#299, by @marcoscaceres.
-
Response/Request semantics and cancellation w3c/payment-request#298, by @marcoscaceres.
-
-
4 issues closed.
-
PaymentResponse's details could lead to problems w3c/payment-request#328.
-
currencySystem seems like a recipe for interop hell w3c/payment-request#305.
-
"valid decimal monetary value" should move to its own section w3c/payment-request#303.
-
Should PaymentDetails.total be marked as required in IDL? w3c/payment-request#300.
-
-
1 issue reopened.
-
Use HTML's (or infra) definition of “valid decimal monetary value”, once available w3c/payment-request#301, by @marcoscaceres.
-
-
33 issues received 143 new comments.
-
Send HTMLIFrameElement.allowPaymentRequest to HTML spec w3c/payment-request#311 (42 comments by @adrianhopebailie, @annevk, @clelland, @esprehn, @foolip, @halindrome, @ianbjacobs, @igrigorik, @marcoscaceres, @mikewest, @ojanvafai, @raymeskhoury, @rsolomakhin, @tommythorsen)
-
currencySystem seems like a recipe for interop hell w3c/payment-request#305 (13 comments by @adamroach, @adrianhopebailie, @halindrome, @ianbjacobs, @marcoscaceres, @rsolomakhin, @webpayments-specs)
-
The myth of JSON-serializable object w3c/payment-request#307 (11 comments by @adrianba, @bzbarsky, @marcoscaceres, @RByers, @rsolomakhin, @webpayments-specs)
-
Use HTML's (or infra) definition of “valid decimal monetary value”, once available w3c/payment-request#301 (11 comments by @adrianhopebailie, @burdges, @halindrome, @marcoscaceres, @nickjshearer, @sideshowbarker)
-
Add canMakePayment() function to PaymentRequest object. w3c/payment-request#310 (8 comments by @adrianba, @dlongley, @halindrome, @ianbjacobs, @rsolomakhin)
-
PaymentOptions seems overly verbose/overlaps with HTML w3c/payment-request#326 (7 comments by @adrianba, @annevk, @marcoscaceres, @nickjshearer, @sideshowbarker)
-
PaymentDetails "total" member should be required w3c/payment-request#320 (5 comments by @adrianba, @bzbarsky, @foolip)
-
Making this API work with HTML Forms w3c/payment-request#330 (4 comments by @marcoscaceres, @rsolomakhin, @zkoch)
-
Behavior for multiple modifiers for the same payment method is not defined w3c/payment-request#309 (3 comments by @ianbjacobs, @rsolomakhin, @tommythorsen)
-
Should PaymentDetails.total be marked as required in IDL? w3c/payment-request#300 (3 comments by @ianbjacobs, @marcoscaceres)
-
PaymentRequest constructor errors should be properly annotated w3c/payment-request#290 (3 comments by @marcoscaceres, @zkoch)
-
Is section 3.4 informative or normative? w3c/payment-request#342 (2 comments by @bzbarsky, @marcoscaceres)
-
What does it mean for a user agent to validate displayItems? w3c/payment-request#344 (2 comments by @bzbarsky, @ianbjacobs)
-
"asynchronously perform the remaining steps" is not defined w3c/payment-request#341 (2 comments by @adamroach, @bzbarsky)
-
The "data" member of PaymentMethodData doesn't seem to actually be used for anything w3c/payment-request#338 (2 comments by @adamroach, @bzbarsky)
-
How are currency systems expected to be implemented in practice? w3c/payment-request#343 (2 comments by @bzbarsky, @marcoscaceres)
-
PaymentDetails may not have values present for various sequences, but the PaymentRequest constructor assumes that it does w3c/payment-request#333 (2 comments by @bzbarsky)
-
"valid decimal monetary value" should move to its own section w3c/payment-request#303 (2 comments by @adrianhopebailie, @marcoscaceres)
-
Response/Request semantics and cancellation w3c/payment-request#298 (2 comments by @adrianba, @marcoscaceres)
-
PaymentRequest type checks (valid non-negative monetary value) w3c/payment-request#306 (2 comments by @halindrome, @marcoscaceres)
-
What is the shippingAddress/shippingOption of a PaymentResponse if requestShipping was false? w3c/payment-request#352 (1 comment by @bzbarsky)
-
It's probably a good idea to use https://www.w3.org/2001/tag/doc/promises-guide#shorthand-reacting in updateWith w3c/payment-request#348 (1 comment by @marcoscaceres)
-
Please define your internal slot notation before using it w3c/payment-request#336 (1 comment by @bzbarsky)
-
"contains a value for" isn't defined for dictionaries w3c/payment-request#321 (1 comment by @bzbarsky)
-
PaymentResponse's details could lead to problems w3c/payment-request#328 (1 comment by @marcoscaceres)
-
Add dir/lang member on dictionaries whose content is displayed in browser UI w3c/payment-request#327 (1 comment by @marcoscaceres)
-
-
14 pull requests opened.
-
editorial: PaymentRequest ctor, describe errors (closes #290) w3c/payment-request#355, by @marcoscaceres.
-
editorial: clarify examples w3c/payment-request#329, by @marcoscaceres.
-
chore: xref internal slots w3c/payment-request#319, by @marcoscaceres.
-
Fix example w3c/payment-request#318, by @marcoscaceres.
-
Example update w3c/payment-request#317, by @ianbjacobs.
-
Detecting Payment Method Availability w3c/payment-request#316, by @maheshkk.
-
Merge pull request #1 from w3c/gh-pages w3c/payment-request#315, by @maheshkk.
-
editorial: move monetary value to Definitions sec (closes #303) w3c/payment-request#313, by @marcoscaceres.
-
normative(PaymentComplete): replace '' with 'unknown' (closes #308) w3c/payment-request#312, by @marcoscaceres.
-
Tidy up document w3c/payment-request#297, by @marcoscaceres.
-
chore: fix xrefs and dfns w3c/payment-request#296, by @marcoscaceres.
-
Relocate conformance section + markup fixes w3c/payment-request#295, by @marcoscaceres.
-
Combine scope and goal + relocate/reduce conformance w3c/payment-request#294, by @marcoscaceres.
-
style(abstract): simplify abstract w3c/payment-request#293, by @marcoscaceres.
-
-
8 pull requests merged.
-
chore: xref internal slots w3c/payment-request#319.
-
Fix example w3c/payment-request#318.
-
editorial: move monetary value to Definitions sec (closes #303) w3c/payment-request#313.
-
Tidy up document w3c/payment-request#297.
-
chore: fix xrefs and dfns w3c/payment-request#296.
-
Relocate conformance section + markup fixes w3c/payment-request#295.
-
Combine scope and goal + relocate/reduce conformance w3c/payment-request#294.
-
style(abstract): simplify abstract w3c/payment-request#293.
-
-
2 pull requests closed.
-
Example update w3c/payment-request#317.
-
Merge pull request #1 from w3c/gh-pages w3c/payment-request#315.
-
-
14 pull requests received 70 new comments.
-
Detecting Payment Method Availability w3c/payment-request#316 (28 comments by @adrianba, @jenan-stripe, @jenanwise, @marcoscaceres, @mkruisselbrink, @nickjshearer, @rsolomakhin)
-
Introduce paymenRequestID w3c/payment-request#292 (12 comments by @adamroach, @adrianhopebailie, @halindrome, @ianbjacobs, @nickjshearer, @rvm4, @stan-stripe)
-
normative(PaymentComplete): replace '' with 'unknown' (closes #308) w3c/payment-request#312 (5 comments by @adrianba, @marcoscaceres, @rsolomakhin, @zkoch)
-
editorial: move monetary value to Definitions sec (closes #303) w3c/payment-request#313 (4 comments by @marcoscaceres, @sideshowbarker)
-
style(abstract): simplify abstract w3c/payment-request#293 (2 comments by @adrianhopebailie, @marcoscaceres)
-
editorial: PaymentRequest ctor, describe errors (closes #290) w3c/payment-request#355 (1 comment by @zkoch)
-
Combine scope and goal + relocate/reduce conformance w3c/payment-request#294 (1 comment by @marcoscaceres)
-
w3c/webpayments
-
11 pull requests opened.
-
updated text on reconciliation with payment request ID w3c/webpayments#193, by @ianbjacobs.
-
fix: typo w3c/webpayments#192, by @marcoscaceres.
-
Add trademark question w3c/webpayments#191, by @ianbjacobs.
-
Title fix w3c/webpayments#190, by @ianbjacobs.
-
Add note on doc structure w3c/webpayments#189, by @ianbjacobs.
-
delete wrong url w3c/webpayments#188, by @ianbjacobs.
-
First draft of proposal w3c/webpayments#187, by @ianbjacobs.
-
Merge remote-tracking branch 'w3c/gh-pages' into gh-pages w3c/webpayments#186, by @ianbjacobs.
-
(1) versioning (2) transaction id w3c/webpayments#185, by @ianbjacobs.
-
Move gateway tokens out of this spec w3c/webpayments#184, by @kphfb.
-
Add Interledger Payment Method draft w3c/webpayments#183, by @adrianhopebailie.
-
-
11 pull requests merged.
-
fix: typo w3c/webpayments#192.
-
updated text on reconciliation with payment request ID w3c/webpayments#193.
-
Add trademark question w3c/webpayments#191.
-
Title fix w3c/webpayments#190.
-
Add note on doc structure w3c/webpayments#189.
-
delete wrong url w3c/webpayments#188.
-
First draft of proposal w3c/webpayments#187.
-
Merge remote-tracking branch 'w3c/gh-pages' into gh-pages w3c/webpayments#186.
-
(1) versioning (2) transaction id w3c/webpayments#185.
-
Move gateway tokens out of this spec w3c/webpayments#184.
-
Add Interledger Payment Method draft w3c/webpayments#183.
-
-
2 pull requests received 6 new comments.
w3c/web-based-payment-handler
-
2 issues opened.
-
What does "icon" mean? w3c/web-based-payment-handler#69, by @ianbjacobs.
-
No definition of Open and Proprietary payment methods w3c/web-based-payment-handler#67, by @maxpassion.
-
-
3 issues closed.
-
How can a Browser-based Payment App cancel the payment flow? w3c/web-based-payment-handler#37.
-
Users MUST be able to prevent the display of unregistered payment apps w3c/web-based-payment-handler#59.
-
No definition of Open and Proprietary payment methods w3c/web-based-payment-handler#67.
-
-
9 issues received 28 new comments.
-
Payment app identifier to manifest filename mapping w3c/web-based-payment-handler#48 (15 comments by @adrianhopebailie, @ianbjacobs, @jakearchibald, @rsolomakhin, @tommythorsen)
-
How can a Browser-based Payment App cancel the payment flow? w3c/web-based-payment-handler#37 (3 comments by @ianbjacobs, @rsolomakhin, @tommythorsen)
-
Analyse security properties of payment app execution environment w3c/web-based-payment-handler#23 (1 comment by @ianbjacobs)
-
Users MUST be able to prevent the display of unregistered payment apps w3c/web-based-payment-handler#59 (1 comment by @ianbjacobs)
-
Should payment apps implement payment method-specific filters? w3c/web-based-payment-handler#63 (1 comment by @ianbjacobs)
-
No definition of Open and Proprietary payment methods w3c/web-based-payment-handler#67 (1 comment by @ianbjacobs)
-
-
4 pull requests opened.
-
Modify section 10.4 Payment App Response to allow an app to cancel. w3c/web-based-payment-handler#72, by @tommythorsen.
-
(Promise<PaymentResponse> or PaymentResponse) is invalid Web IDL. w3c/web-based-payment-handler#71, by @romandev.
-
Edited specification to remove notions of open/proprietary w3c/web-based-payment-handler#70, by @ianbjacobs.
-
Display order edits w3c/web-based-payment-handler#68, by @ianbjacobs.
-
-
3 pull requests merged.
-
(Promise<PaymentResponse> or PaymentResponse) is invalid Web IDL. w3c/web-based-payment-handler#71.
-
Modify section 10.4 Payment App Response to allow an app to cancel. w3c/web-based-payment-handler#72.
-
Display order edits w3c/web-based-payment-handler#68.
-
-
3 pull requests received 13 new comments.
-
Edited specification to remove notions of open/proprietary w3c/web-based-payment-handler#70 (6 comments by @adrianhopebailie, @ianbjacobs)
-
Modify section 10.4 Payment App Response to allow an app to cancel. w3c/web-based-payment-handler#72 (4 comments by @adrianhopebailie, @ianbjacobs, @tommythorsen)
-
(Promise<PaymentResponse> or PaymentResponse) is invalid Web IDL. w3c/web-based-payment-handler#71 (3 comments by @adamroach, @ianbjacobs)
-
w3c/payment-method-id
-
2 issues opened.
-
SRI on manifest w3c/payment-method-id#18, by @adrianhopebailie.
-
Support for PMI's with schemes other than https? w3c/payment-method-id#17, by @adrianhopebailie.
-
-
1 pull request opened.
-
Update of PMI spec w3c/payment-method-id#16, by @ianbjacobs.
-
-
1 pull request merged.
-
Update of PMI spec w3c/payment-method-id#16.
-
-
1 pull request received 18 new comments.
TR publications
-
1 document published.
-
Web Payments Overview 1.0 published as a Note. History of Web Payments Overview 1.0
-
GitHub
w3c/payment-request
-
1 issue opened.
-
How are digital signatures supported for Payment Requests? w3c/payment-request#291, by @msporny.
-
-
5 issues received 23 new comments.
-
How are digital signatures supported for Payment Requests? w3c/payment-request#291 (11 comments by @adrianhopebailie, @dlongley, @ianbjacobs, @msporny)
-
Add Guidance Text for User Consent w3c/payment-request#229 (5 comments by @burdges, @ianbjacobs, @lknik)
-
notifying the payment app when a payment is complete w3c/payment-request#286 (4 comments by @adrianhopebailie, @halindrome)
-
PaymentDetails should include a transaction ID w3c/payment-request#287 (2 comments by @lyverovski, @mattsaxon)
-
-
1 pull request opened.
-
Introduce paymenRequestID w3c/payment-request#292, by @rvm4.
-
-
1 pull request received 7 new comments.
-
Introduce paymenRequestID w3c/payment-request#292 (7 comments by @adrianhopebailie, @dlongley, @ianbjacobs, @zkoch)
-
w3c/web-based-payment-handler
-
1 issue opened.
-
Should payment apps implement payment method-specific filters? w3c/web-based-payment-handler#63, by @ianbjacobs.
-
-
2 issues received 3 new comments.
-
Should payment apps implement payment method-specific filters? w3c/web-based-payment-handler#63 (2 comments by @adamroach, @ianbjacobs)
-
Should merchants be able to limit matching to trusted apps? w3c/web-based-payment-handler#1 (1 comment by @ianbjacobs)
-
-
3 pull requests opened.
-
Editorial fixes and clarifications w3c/web-based-payment-handler#66, by @ianbjacobs.
-
Add note to design considerations about ephemeral data for unregistered apps and step in invokation procedure w3c/web-based-payment-handler#65, by @jnormore.
-
Update w3c/web-based-payment-handler#64, by @ianbjacobs.
-
-
3 pull requests merged.
-
Editorial fixes and clarifications w3c/web-based-payment-handler#66.
-
Add note to design considerations about ephemeral data for unregistered apps and step in invokation procedure w3c/web-based-payment-handler#65.
-
Update w3c/web-based-payment-handler#64.
-
-
2 pull requests closed.
-
Editorial tweaks after Rouslan edits w3c/web-based-payment-handler#62.
-
Cleaned up text w3c/web-based-payment-handler#52.
-
-
2 pull requests received 2 new comments.
w3c/webpayments
-
2 issues received 2 new comments.
TR publications
-
2 documents published.
-
Web Payments HTTP API 1.0 published as a First Public Working Draft. History of Web Payments HTTP API 1.0
-
Web Payments HTTP Messages 1.0 published as a First Public Working Draft. History of Web Payments HTTP Messages 1.0
-
Participants
-
1 participant joined.
-
Lauren Jones (W3C Invited Experts) joined.
-
-
1 organization joined.
-
Department of Human Services joined.
-
GitHub
w3c/payment-request
-
15 issues opened.
-
PaymentRequest constructor errors should be properly annotated w3c/payment-request#290, by @msporny.
-
Dynamic Currency Conversion requirements w3c/payment-request#289, by @Yongsta.
-
PaymentDetails should include a transaction ID w3c/payment-request#287, by @halindrome.
-
notifying the payment app when a payment is complete w3c/payment-request#286, by @halindrome.
-
Should show() depend on a user action? w3c/payment-request#283, by @adrianhopebailie.
-
What if the user refuses to supply a shipping address w3c/payment-request#279, by @halindrome.
-
What does it mean to "accept the payment"? w3c/payment-request#278, by @halindrome.
-
Throwing exceptions rather than permitting broken usage w3c/payment-request#275, by @halindrome.
-
Examples in the spec w3c/payment-request#274, by @halindrome.
-
How can a user agent not accept a payment method? w3c/payment-request#273, by @halindrome.
-
There might be a conflict between 'shippingType' in PaymentOptions and WebIDL binding. w3c/payment-request#271, by @romandev.
-
What should happen when invalid data is provided? w3c/payment-request#265, by @rsolomakhin.
-
Specify UA requirements if “value” field of PaymentCurrencyAmount does not match syntax requirements w3c/payment-request#260, by @sideshowbarker.
-
Detecting payment method support w3c/payment-request#247, by @baloo.
-
Request to remove 'careOf' field from the PaymentAddress interface w3c/payment-request#244, by @andyst.
-
-
29 issues closed.
-
notifying the payment app when a payment is complete w3c/payment-request#286.
-
Should show() depend on a user action? w3c/payment-request#283.
-
What if the user refuses to supply a shipping address w3c/payment-request#279.
-
Detecting payment method support w3c/payment-request#247.
-
There might be a conflict between 'shippingType' in PaymentOptions and WebIDL binding. w3c/payment-request#271.
-
Expand Privacy Considerations Section w3c/payment-request#228.
-
Should the Payment Request API only be available in a top-level browsing context? w3c/payment-request#2.
-
Add security text regarding payment apps and phishing w3c/payment-request#233.
-
Expand Security Considerations Section w3c/payment-request#231.
-
Currency Types and Rendering w3c/payment-request#185.
-
Update Introduction to describe actors better w3c/payment-request#121.
-
What should happen when invalid data is provided? w3c/payment-request#265.
-
Payment Instrument clarification w3c/payment-request#104.
-
Payment app discovery w3c/payment-request#155.
-
Can the merchant influence order of presentation of payment apps to the user w3c/payment-request#23.
-
Ensure references are up-to-date w3c/payment-request#20.
-
Update references to "Payment Transaction Message Specification" w3c/payment-request#218.
-
Specify UA requirements if “value” field of PaymentCurrencyAmount does not match syntax requirements w3c/payment-request#260.
-
Unambiguously specify UA requirements for instances that are not valid w3c/payment-request#235.
-
Normative References w3c/payment-request#227.
-
Request to remove 'careOf' field from the PaymentAddress interface w3c/payment-request#244.
-
Cannot use 2119 terms in notes w3c/payment-request#240.
-
Specify UA requirements if “id” field of PaymentShippingOption is not unique w3c/payment-request#243.
-
Annotate all interfaces with SecureContext w3c/payment-request#241.
-
Clarify that HTTPS is required to use the API w3c/payment-request#232.
-
Make ISO4217 an informative reference rather than normative w3c/payment-request#242.
-
Propose a payment method specification that includes an example of field level security w3c/payment-request#141.
-
Should the payment mediator pass all payment method data to the payment app or just relevant data? w3c/payment-request#157.
-
Add Guidance Text for Incognito Mode w3c/payment-request#230.
-
-
2 issues reopened.
-
Request to remove 'careOf' field from the PaymentAddress interface w3c/payment-request#244, by @adrianba.
-
Can the merchant influence order of presentation of payment apps to the user w3c/payment-request#23, by @ianbjacobs.
-
-
26 issues received 80 new comments.
-
PaymentDetails should include a transaction ID w3c/payment-request#287 (12 comments by @adamroach, @adrianhopebailie, @burdges, @dlongley, @halindrome, @nickjshearer, @rsolomakhin)
-
What if the user refuses to supply a shipping address w3c/payment-request#279 (10 comments by @adrianba, @adrianhopebailie, @burdges, @zkoch)
-
Request to remove 'careOf' field from the PaymentAddress interface w3c/payment-request#244 (8 comments by @adamroach, @andyst, @dlongley, @ianbjacobs, @zkoch)
-
notifying the payment app when a payment is complete w3c/payment-request#286 (7 comments by @adrianba, @adrianhopebailie, @burdges, @halindrome, @rsolomakhin)
-
Add Guidance Text for User Consent w3c/payment-request#229 (7 comments by @adamroach, @adrianba, @burdges, @ianbjacobs)
-
Detecting payment method support w3c/payment-request#247 (6 comments by @adrianba, @adrianhopebailie, @baloo, @rsolomakhin)
-
What does it mean to "accept the payment"? w3c/payment-request#278 (4 comments by @adrianba, @dlongley, @halindrome, @ianbjacobs)
-
Add Guidance Text for Incognito Mode w3c/payment-request#230 (3 comments by @adrianhopebailie, @ianbjacobs)
-
What should happen when invalid data is provided? w3c/payment-request#265 (3 comments by @adrianba, @rsolomakhin)
-
Can the merchant influence order of presentation of payment apps to the user w3c/payment-request#23 (2 comments by @adrianba, @ianbjacobs)
-
There might be a conflict between 'shippingType' in PaymentOptions and WebIDL binding. w3c/payment-request#271 (1 comment by @adrianba)
-
Add security text regarding payment apps and phishing w3c/payment-request#233 (1 comment by @adrianba)
-
If a card payment fails, should we support exclusion of that card instrument from matching? w3c/payment-request#237 (1 comment by @adrianba)
-
Unambiguously specify UA requirements for instances that are not valid w3c/payment-request#235 (1 comment by @adrianba)
-
Specify UA requirements if “value” field of PaymentCurrencyAmount does not match syntax requirements w3c/payment-request#260 (1 comment by @adrianba)
-
Propose a payment method specification that includes an example of field level security w3c/payment-request#141 (1 comment by @ianbjacobs)
-
Should the payment mediator pass all payment method data to the payment app or just relevant data? w3c/payment-request#157 (1 comment by @ianbjacobs)
-
-
32 pull requests opened.
-
Update editor list w3c/payment-request#288, by @rvm4.
-
Fix shippingType to avoid TypeError w3c/payment-request#285, by @adrianba.
-
Describe risk of exposing available payment methods w3c/payment-request#284, by @adrianba.
-
Added clarification about target of details w3c/payment-request#282, by @halindrome.
-
Fixed typos w3c/payment-request#281, by @halindrome.
-
Remove must in complete() w3c/payment-request#280, by @halindrome.
-
Add informative reference to CLDR w3c/payment-request#277, by @halindrome.
-
Fixed a typo w3c/payment-request#276, by @halindrome.
-
Make text active voice, present tense w3c/payment-request#272, by @halindrome.
-
Reducing the gap to Apple's API w3c/payment-request#270, by @adrianba.
-
Remove issue markers for issues postponed past v1. w3c/payment-request#269, by @adrianba.
-
Add allowpaymentrequest attribute for iframe support w3c/payment-request#268, by @adrianba.
-
Add support for currency system. w3c/payment-request#267, by @adrianba.
-
Remove explanation using "parties" w3c/payment-request#266, by @adrianba.
-
Update the issues links to exclude postponed issues that we don't pla… w3c/payment-request#264, by @adrianba.
-
PR #259 and #262 updated the references w3c/payment-request#263, by @adrianba.
-
Remove the dependency on PAYMENT-ARCH. w3c/payment-request#262, by @adrianba.
-
Remove restriction that payment method identifier only appear once w3c/payment-request#261, by @adrianba.
-
Updated WebIDL and Secure Contexts references w3c/payment-request#259, by @adrianba.
-
Remove careOf field and add note to recipient field. w3c/payment-request#258, by @adrianba.
-
Add error message that can be provided as part of updateWith w3c/payment-request#257, by @adrianba.
-
Make UAs throw for invalid monetary amounts w3c/payment-request#256, by @sideshowbarker.
-
Fix typo in PaymentItem definition w3c/payment-request#255, by @sideshowbarker.
-
Tidied up text in notes. w3c/payment-request#254, by @adrianba.
-
Implementations may choose to implement a timeouts w3c/payment-request#253, by @adrianba.
-
Make response serializable. w3c/payment-request#252, by @adrianba.
-
Decorate all interfaces with [SecureContext] w3c/payment-request#251, by @adrianba.
-
ISO4217 is informative. w3c/payment-request#250, by @adrianba.
-
Ignore shipping options if there are duplicate IDs. w3c/payment-request#249, by @adrianba.
-
Create failure-handling.md w3c/payment-request#248, by @rvm4.
-
Update Respec config. w3c/payment-request#246, by @adrianba.
-
Add note preferring GitHub issues over e-mail. w3c/payment-request#245, by @adrianba.
-
-
32 pull requests merged.
-
Update editor list w3c/payment-request#288.
-
Describe risk of exposing available payment methods w3c/payment-request#284.
-
Fix shippingType to avoid TypeError w3c/payment-request#285.
-
Added clarification about target of details w3c/payment-request#282.
-
Remove must in complete() w3c/payment-request#280.
-
Fixed typos w3c/payment-request#281.
-
Add informative reference to CLDR w3c/payment-request#277.
-
Make text active voice, present tense w3c/payment-request#272.
-
Fixed a typo w3c/payment-request#276.
-
Reducing the gap to Apple's API w3c/payment-request#270.
-
Remove issue markers for issues postponed past v1. w3c/payment-request#269.
-
Add allowpaymentrequest attribute for iframe support w3c/payment-request#268.
-
Add support for currency system. w3c/payment-request#267.
-
Remove explanation using "parties" w3c/payment-request#266.
-
Update the issues links to exclude postponed issues that we don't pla… w3c/payment-request#264.
-
PR #259 and #262 updated the references w3c/payment-request#263.
-
Remove the dependency on PAYMENT-ARCH. w3c/payment-request#262.
-
Make UAs throw for invalid monetary amounts w3c/payment-request#256.
-
Remove restriction that payment method identifier only appear once w3c/payment-request#261.
-
Updated WebIDL and Secure Contexts references w3c/payment-request#259.
-
Remove careOf field and add note to recipient field. w3c/payment-request#258.
-
Fix typo in PaymentItem definition w3c/payment-request#255.
-
Add error message that can be provided as part of updateWith w3c/payment-request#257.
-
Tidied up text in notes. w3c/payment-request#254.
-
Implementations may choose to implement a timeouts w3c/payment-request#253.
-
Make response serializable. w3c/payment-request#252.
-
Ignore shipping options if there are duplicate IDs. w3c/payment-request#249.
-
Decorate all interfaces with [SecureContext] w3c/payment-request#251.
-
ISO4217 is informative. w3c/payment-request#250.
-
Create failure-handling.md w3c/payment-request#248.
-
Add note preferring GitHub issues over e-mail. w3c/payment-request#245.
-
Update Respec config. w3c/payment-request#246.
-
-
2 pull requests closed.
-
"Incognito mode" notes w3c/payment-request#238.
-
API flow w3c/payment-request#177.
-
-
6 pull requests received 12 new comments.
-
Add allowpaymentrequest attribute for iframe support w3c/payment-request#268 (3 comments by @adamroach, @halindrome)
-
Make UAs throw for invalid monetary amounts w3c/payment-request#256 (3 comments by @adrianba, @sideshowbarker)
-
w3c/payment-method-id
-
1 issue opened.
-
Schema.org PaymentMethod as namespace for short strings w3c/payment-method-id#13, by @adrianhopebailie.
-
-
1 issue closed.
-
Why URLs? w3c/payment-method-id#9.
-
-
1 issue reopened.
-
Identifier equivalence does not handle failure w3c/payment-method-id#8, by @zkoch.
-
-
3 issues received 20 new comments.
-
Why URLs? w3c/payment-method-id#9 (8 comments by @adrianhopebailie, @annevk, @halindrome, @tabatkins, @zkoch)
-
Identifier equivalence does not handle failure w3c/payment-method-id#8 (8 comments by @annevk, @halindrome, @webpayments-specs, @zkoch)
-
Schema.org PaymentMethod as namespace for short strings w3c/payment-method-id#13 (4 comments by @adrianba, @adrianhopebailie, @ianbjacobs)
-
-
2 pull requests opened.
-
Update editor list w3c/payment-method-id#15, by @rvm4.
-
Add github links w3c/payment-method-id#14, by @halindrome.
-
-
2 pull requests merged.
-
Add github links w3c/payment-method-id#14.
-
Update editor list w3c/payment-method-id#15.
-
w3c/web-based-payment-handler
-
12 issues opened.
-
Users MUST be able to prevent the display of unregistered payment apps w3c/web-based-payment-handler#59, by @halindrome.
-
Section 6 steps 1-5 seem to avoid selecting a payment option / payment method w3c/web-based-payment-handler#56, by @halindrome.
-
Links to terms and common terminology w3c/web-based-payment-handler#50, by @halindrome.
-
Pictures would help! w3c/web-based-payment-handler#49, by @halindrome.
-
Payment app identifier to manifest filename mapping w3c/web-based-payment-handler#48, by @rsolomakhin.
-
Pass along a Transaction ID w3c/web-based-payment-handler#47, by @halindrome.
-
Versioning w3c/web-based-payment-handler#45, by @mattsaxon.
-
What is matching and display behavior for various scenarios of recommended apps, enabled apps, non-enabled apps, etc.? w3c/web-based-payment-handler#38, by @ianbjacobs.
-
How can a Browser-based Payment App cancel the payment flow? w3c/web-based-payment-handler#37, by @ianbjacobs.
-
How is registration information updated? w3c/web-based-payment-handler#36, by @ianbjacobs.
-
Payment apps and methods, are they the same? w3c/web-based-payment-handler#35, by @rsolomakhin.
-
Thoughts on the current spec w3c/web-based-payment-handler#34, by @rsolomakhin.
-
-
10 issues closed.
-
Payment apps and methods, are they the same? w3c/web-based-payment-handler#35.
-
How is registration information updated? w3c/web-based-payment-handler#36.
-
The relationship between payment apps and service workers w3c/web-based-payment-handler#33.
-
What is the process for rendering the payment app UI w3c/web-based-payment-handler#4.
-
“Security Error” on different origins w3c/web-based-payment-handler#9.
-
Thoughts on the current spec w3c/web-based-payment-handler#34.
-
Extending invocation of payment apps with other techniques than HTTP w3c/web-based-payment-handler#10.
-
Should the browser pass user data it has collected (email etc) to the payment app? w3c/web-based-payment-handler#13.
-
Require secure contexts for web-based payment apps w3c/web-based-payment-handler#24.
-
Should we distinguish the identifier for a payment app from the identifier for the app server that processes payments? w3c/web-based-payment-handler#20.
-
-
19 issues received 96 new comments.
-
The relationship between payment apps and service workers w3c/web-based-payment-handler#33 (29 comments by @adrianhopebailie, @dlongley, @ianbjacobs, @jakearchibald, @marcoscaceres, @rsolomakhin, @sideshowbarker, @zkoch)
-
Payment apps and methods, are they the same? w3c/web-based-payment-handler#35 (23 comments by @adrianhopebailie, @ianbjacobs, @jakearchibald, @rsolomakhin)
-
Thoughts on the current spec w3c/web-based-payment-handler#34 (13 comments by @adrianhopebailie, @ianbjacobs, @rsolomakhin)
-
Users MUST be able to prevent the display of unregistered payment apps w3c/web-based-payment-handler#59 (5 comments by @burdges, @halindrome, @ianbjacobs, @rsolomakhin)
-
Section 6 steps 1-5 seem to avoid selecting a payment option / payment method w3c/web-based-payment-handler#56 (5 comments by @halindrome, @ianbjacobs, @rsolomakhin)
-
Pass along a Transaction ID w3c/web-based-payment-handler#47 (5 comments by @adrianhopebailie, @halindrome, @ianbjacobs, @rsolomakhin)
-
Payment app identifier to manifest filename mapping w3c/web-based-payment-handler#48 (2 comments by @adrianhopebailie, @maxpassion)
-
How is registration information updated? w3c/web-based-payment-handler#36 (2 comments by @ianbjacobs)
-
How can a Browser-based Payment App cancel the payment flow? w3c/web-based-payment-handler#37 (1 comment by @adamroach)
-
What is the process for rendering the payment app UI w3c/web-based-payment-handler#4 (1 comment by @ianbjacobs)
-
Extending invocation of payment apps with other techniques than HTTP w3c/web-based-payment-handler#10 (1 comment by @ianbjacobs)
-
Should the browser pass user data it has collected (email etc) to the payment app? w3c/web-based-payment-handler#13 (1 comment by @ianbjacobs)
-
What is matching and display behavior for various scenarios of recommended apps, enabled apps, non-enabled apps, etc.? w3c/web-based-payment-handler#38 (1 comment by @ianbjacobs)
-
Require secure contexts for web-based payment apps w3c/web-based-payment-handler#24 (1 comment by @ianbjacobs)
-
Should we distinguish the identifier for a payment app from the identifier for the app server that processes payments? w3c/web-based-payment-handler#20 (1 comment by @ianbjacobs)
-
Should we allow payment providers to issue queries about their installed payment apps (match on origin) w3c/web-based-payment-handler#6 (1 comment by @ianbjacobs)
-
Should payment instrument details be included at registration? w3c/web-based-payment-handler#12 (1 comment by @ianbjacobs)
-
-
17 pull requests opened.
-
Editorial tweaks after Rouslan edits w3c/web-based-payment-handler#62, by @ianbjacobs.
-
Fixed duplicate wording w3c/web-based-payment-handler#61, by @halindrome.
-
Remove duplicate item w3c/web-based-payment-handler#60, by @halindrome.
-
add parens for clause w3c/web-based-payment-handler#58, by @halindrome.
-
change 'promise' to 'Promise' w3c/web-based-payment-handler#57, by @halindrome.
-
Cleanup wording w3c/web-based-payment-handler#55, by @halindrome.
-
Fix run-on sentence w3c/web-based-payment-handler#54, by @halindrome.
-
Fixed grammar w3c/web-based-payment-handler#53, by @halindrome.
-
Cleaned up text w3c/web-based-payment-handler#52, by @halindrome.
-
Use 'user agent' all the time w3c/web-based-payment-handler#51, by @halindrome.
-
Native payment app support and others changes. w3c/web-based-payment-handler#46, by @rsolomakhin.
-
Added optionId field to PaymentAppRequestData dictionary w3c/web-based-payment-handler#44, by @adamroach.
-
Removed <a> until I figure out how to get rid of entry from imported glossary w3c/web-based-payment-handler#43, by @ianbjacobs.
-
Editorial fixes w3c/web-based-payment-handler#42, by @ianbjacobs.
-
Proposed text for service-worker-based implementation of payment apps w3c/web-based-payment-handler#41, by @adamroach.
-
Implications from non registration (via AHB) w3c/web-based-payment-handler#40, by @ianbjacobs.
-
Numerous changes based on Rouslan review and issue migration w3c/web-based-payment-handler#39, by @ianbjacobs.
-
-
15 pull requests merged.
-
add parens for clause w3c/web-based-payment-handler#58.
-
change 'promise' to 'Promise' w3c/web-based-payment-handler#57.
-
Cleanup wording w3c/web-based-payment-handler#55.
-
Fix run-on sentence w3c/web-based-payment-handler#54.
-
Fixed grammar w3c/web-based-payment-handler#53.
-
Use 'user agent' all the time w3c/web-based-payment-handler#51.
-
Native payment app support and others changes. w3c/web-based-payment-handler#46.
-
Fixed duplicate wording w3c/web-based-payment-handler#61.
-
Remove duplicate item w3c/web-based-payment-handler#60.
-
Added optionId field to PaymentAppRequestData dictionary w3c/web-based-payment-handler#44.
-
Removed <a> until I figure out how to get rid of entry from imported glossary w3c/web-based-payment-handler#43.
-
Editorial fixes w3c/web-based-payment-handler#42.
-
Proposed text for service-worker-based implementation of payment apps w3c/web-based-payment-handler#41.
-
Implications from non registration (via AHB) w3c/web-based-payment-handler#40.
-
Numerous changes based on Rouslan review and issue migration w3c/web-based-payment-handler#39.
-
-
2 pull requests received 9 new comments.
-
Numerous changes based on Rouslan review and issue migration w3c/web-based-payment-handler#39 (8 comments by @adrianhopebailie, @ianbjacobs)
-
Implications from non registration (via AHB) w3c/web-based-payment-handler#40 (1 comment by @adrianhopebailie)
-
w3c/webpayments
-
2 issues opened.
-
propose to add encoding attribute to data set w3c/webpayments#181, by @mountielee.
-
Propose a payment method specification that includes an example of field level security w3c/webpayments#179, by @ianbjacobs.
-
-
4 issues closed.
-
Registration: App supports method but user has no instrument for that method w3c/webpayments#110.
-
How can a Web Based Payment App cancel the payment flow? w3c/webpayments#128.
-
Registration: Should we support payee knowing user has payee-controlled payment app? w3c/webpayments#112.
-
Registration: How is registration information updated? w3c/webpayments#111.
-
-
5 issues received 19 new comments.
-
propose to add encoding attribute to data set w3c/webpayments#181 (15 comments by @adrianba, @ianbjacobs, @mountielee, @rsolomakhin, @webpayments)
-
Registration: App supports method but user has no instrument for that method w3c/webpayments#110 (1 comment by @ianbjacobs)
-
How can a Web Based Payment App cancel the payment flow? w3c/webpayments#128 (1 comment by @ianbjacobs)
-
Registration: Should we support payee knowing user has payee-controlled payment app? w3c/webpayments#112 (1 comment by @ianbjacobs)
-
Registration: How is registration information updated? w3c/webpayments#111 (1 comment by @ianbjacobs)
-
-
8 pull requests opened.
-
Added 360Pay Payment Method link w3c/webpayments#182, by @cncuckoo.
-
Create tokenized_cards.html w3c/webpayments#180, by @rvm4.
-
Respec data update w3c/webpayments#178, by @ianbjacobs.
-
small bug fixes w3c/webpayments#177, by @ianbjacobs.
-
Add payment method best practice proposal w3c/webpayments#176, by @ianbjacobs.
-
Overhaul w3c/webpayments#175, by @ianbjacobs.
-
Payment apps moved to its own repo w3c/webpayments#174, by @ianbjacobs.
-
delete utils w3c/webpayments#173, by @ianbjacobs.
-
-
8 pull requests merged.
-
Added 360Pay Payment Method link w3c/webpayments#182.
-
Create tokenized_cards.html w3c/webpayments#180.
-
Respec data update w3c/webpayments#178.
-
small bug fixes w3c/webpayments#177.
-
Add payment method best practice proposal w3c/webpayments#176.
-
Overhaul w3c/webpayments#175.
-
Payment apps moved to its own repo w3c/webpayments#174.
-
delete utils w3c/webpayments#173.
-
-
1 pull request received 1 new comment.
Participants
-
2 organizations joined.
-
LG Electronics joined.
-
INCA Internet Co.,Ltd. joined.
-
GitHub
w3c/web-based-payment-handler
-
12 issues opened.
-
The relationship between payment apps and service workers w3c/web-based-payment-handler#33, by @tommythorsen.
-
Should origin information (about the payment request) be shared with the payment app? w3c/web-based-payment-handler#27, by @ianbjacobs.
-
Communication between JS PaymentApps and the User Agent w3c/web-based-payment-handler#26, by @tommythorsen.
-
Require secure contexts for web-based payment apps w3c/web-based-payment-handler#24, by @adamroach.
-
Analyse security properties of payment app execution environment w3c/web-based-payment-handler#23, by @adamroach.
-
Should we distinguish the identifier for a payment app from the identifier for the app server that processes payments? w3c/web-based-payment-handler#20, by @ianbjacobs.
-
How can we optimize user experience when there is only one match? w3c/web-based-payment-handler#14, by @adrianhopebailie.
-
Should the browser pass user data it has collected (email etc) to the payment app? w3c/web-based-payment-handler#13, by @adrianhopebailie.
-
Should payment instrument details be included at registration? w3c/web-based-payment-handler#12, by @adrianhopebailie.
-
What should be the user experience when an app is recommended for two methods? w3c/web-based-payment-handler#11, by @adrianhopebailie.
-
Extending invocation of payment apps with other techniques than HTTP w3c/web-based-payment-handler#10, by @adrianhopebailie.
-
“Security Error” on different origins w3c/web-based-payment-handler#9, by @adrianhopebailie.
-
-
5 issues closed.
-
Should origin information (about the payment request) be shared with the payment app? w3c/web-based-payment-handler#27.
-
Communication between JS PaymentApps and the User Agent w3c/web-based-payment-handler#26.
-
Is the concept of payment app registration necessary? w3c/web-based-payment-handler#8.
-
Should merchants be able to limit matching to trusted apps? w3c/web-based-payment-handler#1.
-
What should be the user experience when an app is recommended for two methods? w3c/web-based-payment-handler#11.
-
-
10 issues received 47 new comments.
-
The relationship between payment apps and service workers w3c/web-based-payment-handler#33 (21 comments by @adamroach, @adrianhopebailie, @dlongley, @domenic, @jakearchibald, @sideshowbarker, @tommythorsen)
-
Should origin information (about the payment request) be shared with the payment app? w3c/web-based-payment-handler#27 (10 comments by @burdges, @dlongley, @halindrome, @ianbjacobs, @rsolomakhin)
-
Extending invocation of payment apps with other techniques than HTTP w3c/web-based-payment-handler#10 (5 comments by @adrianhopebailie, @sideshowbarker, @tommythorsen)
-
Communication between JS PaymentApps and the User Agent w3c/web-based-payment-handler#26 (3 comments by @adamroach, @tommythorsen)
-
Require secure contexts for web-based payment apps w3c/web-based-payment-handler#24 (2 comments by @adamroach, @ianbjacobs)
-
What should be the user experience when an app is recommended for two methods? w3c/web-based-payment-handler#11 (2 comments by @ianbjacobs, @tommythorsen)
-
Is the concept of payment app registration necessary? w3c/web-based-payment-handler#8 (1 comment by @ianbjacobs)
-
Should merchants be able to limit matching to trusted apps? w3c/web-based-payment-handler#1 (1 comment by @ianbjacobs)
-
How can we optimize user experience when there is only one match? w3c/web-based-payment-handler#14 (1 comment by @ianbjacobs)
-
Should the browser pass user data it has collected (email etc) to the payment app? w3c/web-based-payment-handler#13 (1 comment by @ianbjacobs)
-
-
13 pull requests opened.
-
Two origin-related additions w3c/web-based-payment-handler#32, by @ianbjacobs.
-
Add "incognito mode" text w3c/web-based-payment-handler#31, by @ianbjacobs.
-
Note on usability/security tension around registration w3c/web-based-payment-handler#30, by @ianbjacobs.
-
Add issue 127 mention w3c/web-based-payment-handler#29, by @ianbjacobs.
-
Updates from Tommy's feedback w3c/web-based-payment-handler#28, by @adamroach.
-
High-level proposal for general shape of JS API w3c/web-based-payment-handler#25, by @adamroach.
-
Remove accepted payment app concept w3c/web-based-payment-handler#22, by @ianbjacobs.
-
Design considerations for payment app registration: recommended apps, user consent, and optional registration w3c/web-based-payment-handler#21, by @jnormore.
-
Addition of new design considerations w3c/web-based-payment-handler#19, by @ianbjacobs.
-
Case sensitive doc type (ED) w3c/web-based-payment-handler#18, by @ianbjacobs.
-
Remove async perhaps to help with rendering w3c/web-based-payment-handler#17, by @ianbjacobs.
-
Fixes w3c/web-based-payment-handler#16, by @ianbjacobs.
-
Markup fixes w3c/web-based-payment-handler#15, by @ianbjacobs.
-
-
13 pull requests merged.
-
Two origin-related additions w3c/web-based-payment-handler#32.
-
Add "incognito mode" text w3c/web-based-payment-handler#31.
-
Note on usability/security tension around registration w3c/web-based-payment-handler#30.
-
Add issue 127 mention w3c/web-based-payment-handler#29.
-
Updates from Tommy's feedback w3c/web-based-payment-handler#28.
-
High-level proposal for general shape of JS API w3c/web-based-payment-handler#25.
-
Remove accepted payment app concept w3c/web-based-payment-handler#22.
-
Design considerations for payment app registration: recommended apps, user consent, and optional registration w3c/web-based-payment-handler#21.
-
Addition of new design considerations w3c/web-based-payment-handler#19.
-
Case sensitive doc type (ED) w3c/web-based-payment-handler#18.
-
Remove async perhaps to help with rendering w3c/web-based-payment-handler#17.
-
Fixes w3c/web-based-payment-handler#16.
-
Markup fixes w3c/web-based-payment-handler#15.
-
-
6 pull requests received 19 new comments.
-
Addition of new design considerations w3c/web-based-payment-handler#19 (12 comments by @adrianhopebailie, @halindrome)
-
Design considerations for payment app registration: recommended apps, user consent, and optional registration w3c/web-based-payment-handler#21 (3 comments by @ianbjacobs, @jnormore)
-
Note on usability/security tension around registration w3c/web-based-payment-handler#30 (1 comment by @adrianhopebailie)
-
Remove accepted payment app concept w3c/web-based-payment-handler#22 (1 comment by @adrianhopebailie)
-
w3c/payment-request
-
16 issues opened.
-
Specify UA requirements if “id” field of PaymentShippingOption is not unique w3c/payment-request#243, by @sideshowbarker.
-
Make ISO4217 an informative reference rather than normative w3c/payment-request#242, by @sideshowbarker.
-
Annotate all interfaces with SecureContext w3c/payment-request#241, by @annevk.
-
Cannot use 2119 terms in notes w3c/payment-request#240, by @annevk.
-
Clear pointer to GitHub at the top w3c/payment-request#239, by @annevk.
-
If a card payment fails, should we support exclusion of that card instrument from matching? w3c/payment-request#237, by @ianbjacobs.
-
Unambiguously specify UA requirements for instances that are not valid w3c/payment-request#235, by @sideshowbarker.
-
U w3c/payment-request#234, by @sideshowbarker.
-
Add security text regarding payment apps and phishing w3c/payment-request#233, by @adamroach.
-
Clarify that HTTPS is required to use the API w3c/payment-request#232, by @adamroach.
-
Expand Security Considerations Section w3c/payment-request#231, by @adamroach.
-
Add Guidance Text for Incognito Mode w3c/payment-request#230, by @adamroach.
-
Add Guidance Text for User Consent w3c/payment-request#229, by @adamroach.
-
Expand Privacy Considerations Section w3c/payment-request#228, by @adamroach.
-
Normative References w3c/payment-request#227, by @halindrome.
-
Should the API support field validation? w3c/payment-request#225, by @andrewagain.
-
-
2 issues closed.
-
Clear pointer to GitHub at the top w3c/payment-request#239.
-
U w3c/payment-request#234.
-
-
8 issues received 19 new comments.
-
Clarify that HTTPS is required to use the API w3c/payment-request#232 (6 comments by @annevk, @halindrome, @sideshowbarker, @webpayments-specs)
-
Cannot use 2119 terms in notes w3c/payment-request#240 (3 comments by @annevk, @halindrome, @marcoscaceres)
-
If a card payment fails, should we support exclusion of that card instrument from matching? w3c/payment-request#237 (2 comments by @arthurchow, @halindrome)
-
Should the Payment Request API only be available in a top-level browsing context? w3c/payment-request#2 (2 comments by @adamroach, @sideshowbarker)
-
Supporting push payment methods w3c/payment-request#224 (2 comments by @adrianhopebailie, @ianbjacobs)
-
Should the messages support field-level encryption? w3c/payment-request#55 (1 comment by @ianbjacobs)
-
-
3 pull requests opened.
-
"Incognito mode" notes w3c/payment-request#238, by @ianbjacobs.
-
Change “MUST…to be valid” to just “are required” w3c/payment-request#236, by @sideshowbarker.
-
Add links into Github w3c/payment-request#226, by @halindrome.
-
-
2 pull requests merged.
-
Change “MUST…to be valid” to just “are required” w3c/payment-request#236.
-
Add links into Github w3c/payment-request#226.
-
-
3 pull requests received 6 new comments.
-
Change “MUST…to be valid” to just “are required” w3c/payment-request#236 (2 comments by @adrianhopebailie, @halindrome)
-
an event to providing standards for push payment methods w3c/payment-request#223 (1 comment by @dlongley)
w3c/webpayments
-
2 issues opened.
-
Overview document figure 5 w3c/webpayments#171, by @rvm4.
-
Pull filters out of payment method data w3c/webpayments#170, by @adrianhopebailie.
-
-
10 issues closed.
-
Pull filters out of payment method data w3c/webpayments#170.
-
Letting the payment app decide between HTTP and Javascript communication w3c/webpayments#130.
-
[Payment apps] How can we optimize user experience when there is only one match? w3c/webpayments#169.
-
PROPOSAL: A new document structure for this API w3c/webpayments#134.
-
Should the browser pass user data it has collected (email etc) to the payment app? w3c/webpayments#137.
-
[Payment apps] Should payment instrument details be included at registration? w3c/webpayments#142.
-
[Payment apps] How should third-party payment apps be displayed by the browser? w3c/webpayments#143.
-
[Payment Apps] Extending invocation of payment apps with other techniques than HTTP w3c/webpayments#156.
-
[Payment Apps] “Security Error” on different origins w3c/webpayments#157.
-
-
11 issues received 30 new comments.
-
Overview document figure 5 w3c/webpayments#171 (12 comments by @dlongley, @halindrome, @rsolomakhin, @rvm4)
-
Letting the payment app decide between HTTP and Javascript communication w3c/webpayments#130 (8 comments by @adrianhopebailie, @dlongley, @msporny, @webpayments)
-
Pull filters out of payment method data w3c/webpayments#170 (2 comments by @adrianhopebailie, @msporny)
-
[Payment apps] How can we optimize user experience when there is only one match? w3c/webpayments#169 (1 comment by @adrianhopebailie)
-
PROPOSAL: A new document structure for this API w3c/webpayments#134 (1 comment by @adrianhopebailie)
-
Should the browser pass user data it has collected (email etc) to the payment app? w3c/webpayments#137 (1 comment by @adrianhopebailie)
-
[Payment apps] Should payment instrument details be included at registration? w3c/webpayments#142 (1 comment by @adrianhopebailie)
-
[Payment apps] How should third-party payment apps be displayed by the browser? w3c/webpayments#143 (1 comment by @adrianhopebailie)
-
[Payment apps] What should be the user experience when an app is recommended for two methods? w3c/webpayments#155 (1 comment by @adrianhopebailie)
-
[Payment Apps] Extending invocation of payment apps with other techniques than HTTP w3c/webpayments#156 (1 comment by @adrianhopebailie)
-
[Payment Apps] “Security Error” on different origins w3c/webpayments#157 (1 comment by @adrianhopebailie)
-
-
1 pull request opened.
-
Fix typo: `fishing` => `phishing`. w3c/webpayments#172, by @dlongley.
-
-
1 pull request merged.
-
Fix typo: `fishing` => `phishing`. w3c/webpayments#172.
-
w3c/payment-method-id
-
5 issues opened.
-
Resolve whether browsers need to police payment app claims of supported methods w3c/payment-method-id#11, by @adamroach.
-
Identifier equivalence does not handle failure w3c/payment-method-id#8, by @annevk.
-
Add Security Considerations and Privacy Considerations sections w3c/payment-method-id#7, by @adamroach.
-
4 issues received 63 new comments.
-
Why URLs? w3c/payment-method-id#9 (39 comments by @adamroach, @adrianhopebailie, @annevk, @dlongley, @ianbjacobs, @msporny, @tabatkins, @zkoch)
-
Resolve whether browsers need to police payment app claims of supported methods w3c/payment-method-id#11 (14 comments by @adamroach, @adrianhopebailie, @dlongley, @zkoch)
-
Should a payment method identifier that is a URL bind that payment method to a single payment app or origin? w3c/payment-method-id#12 (5 comments by @adrianhopebailie, @rsolomakhin, @zkoch)
-
Add Security Considerations and Privacy Considerations sections w3c/payment-method-id#7 (5 comments by @adamroach, @adrianhopebailie, @annevk, @sideshowbarker)
-
-
1 pull request opened.
-
update pmi spec with apen and proprietary payment method identifiers w3c/payment-method-id#10, by @rvm4.
-
TR publications
-
2 documents published.
-
Payment Method Identifiers published as a Working Draft. History of Payment Method Identifiers
-
Payment Request API published as a Working Draft. History of Payment Request API
-
Participants
-
1 participant left.
-
Paddy Ramanathan (W3C Invited Experts) left.
-
-
1 organization left.
-
Visa left.
-
GitHub
w3c/webpayments
-
15 issues opened.
-
[Payment apps] How can we optimize user experience when there is only one match? w3c/webpayments#169, by @ianbjacobs.
-
[Payment app] Should merchants be able to limit matching to trusted apps? w3c/webpayments#168, by @ianbjacobs.
-
How should the group update documents in 'TR' space? w3c/webpayments#167, by @halindrome.
-
[Payment Apps] What portion of the PaymentRequest is sent to the payment app? w3c/webpayments#166, by @LaurentCastillo.
-
[Payment App] How is Native App integration code supplied? w3c/webpayments#164, by @cyberphone.
-
[Payment Apps] What is the process for rendering the payment app UI w3c/webpayments#162, by @adrianhopebailie.
-
[Payment Apps] Split out enabled and supported methods w3c/webpayments#158, by @adrianhopebailie.
-
[Payment Apps] “Security Error” on different origins w3c/webpayments#157, by @LaurentCastillo.
-
[Payment Apps] Extending invocation of payment apps with other techniques than HTTP w3c/webpayments#156, by @LaurentCastillo.
-
-
9 issues closed.
-
[Payment Apps] Split out enabled and supported methods w3c/webpayments#158.
-
[Payment Apps] What is the process for rendering the payment app UI w3c/webpayments#162.
-
[Payment App] How is Native App integration code supplied? w3c/webpayments#164.
-
[Payment Apps] What portion of the PaymentRequest is sent to the payment app? w3c/webpayments#166.
-
[Payment app] Should merchants be able to limit matching to trusted apps? w3c/webpayments#168.
-
-
1 issue reopened.
-
[Payment Apps] Extending invocation of payment apps with other techniques than HTTP w3c/webpayments#156, by @adrianhopebailie.
-
-
15 issues received 59 new comments.
-
[Payment Apps] Extending invocation of payment apps with other techniques than HTTP w3c/webpayments#156 (11 comments by @adrianhopebailie, @cyberphone, @ianbjacobs)
-
How should the group update documents in 'TR' space? w3c/webpayments#167 (7 comments by @adrianhopebailie, @halindrome, @ianbjacobs, @msporny, @webpayments)
-
[Payment App] How is Native App integration code supplied? w3c/webpayments#164 (4 comments by @adrianhopebailie, @cyberphone)
-
[Payment App] Should the payment app registration be for Browsers only or also for other types of User Agents w3c/webpayments#165 (3 comments by @adrianhopebailie, @cyberphone)
-
[Payment Apps] Split out enabled and supported methods w3c/webpayments#158 (2 comments by @adrianhopebailie, @ianbjacobs)
-
[Payment Apps] What portion of the PaymentRequest is sent to the payment app? w3c/webpayments#166 (2 comments by @adrianhopebailie, @webpayments)
-
[Payment Apps] Should we allow payment providers to issue queries about their installed payment apps (match on origin) w3c/webpayments#160 (1 comment by @adrianhopebailie)
-
[Payment Apps] Display may be subject to user and local policy (consider UA making security decisions etc) w3c/webpayments#161 (1 comment by @adrianhopebailie)
-
[Payment Apps] What is the process for rendering the payment app UI w3c/webpayments#162 (1 comment by @adrianhopebailie)
-
[Payment App] PROPOSAL: Payment Apps are javascript code that use event listeners to get the PaymentRequest w3c/webpayments#163 (1 comment by @adrianhopebailie)
-
[Payment app] Should merchants be able to limit matching to trusted apps? w3c/webpayments#168 (1 comment by @adrianhopebailie)
-
Letting the payment app decide between HTTP and Javascript communication w3c/webpayments#130 (1 comment by @adamroach)
-
[Payment apps] Should payment instrument details be included at registration? w3c/webpayments#142 (1 comment by @adrianhopebailie)
-
4 pull requests opened.
-
Minor fix to register also w3c/webpayments#154, by @adrianhopebailie.
-
Add reference to origin and fix a mistake in the registration API w3c/webpayments#153, by @adrianhopebailie.
-
Editorial walk-through w3c/webpayments#152, by @ianbjacobs.
-
Replace empty section on development payment app good practices w3c/webpayments#151, by @ianbjacobs.
-
-
5 pull requests merged.
-
Minor fix to register also w3c/webpayments#154.
-
Add reference to origin and fix a mistake in the registration API w3c/webpayments#153.
-
Editorial walk-through w3c/webpayments#152.
-
Replace empty section on development payment app good practices w3c/webpayments#151.
-
Fix payment options references + proposal on recommended apps w3c/webpayments#150.
-
-
1 pull request received 1 new comment.
w3c/payment-request
-
1 issue opened.
-
Supporting push payment methods w3c/payment-request#224, by @rvm4.
-
-
1 issue reopened.
-
Currency Types and Rendering w3c/payment-request#185, by @ianbjacobs.
-
-
2 issues received 11 new comments.
-
Supporting push payment methods w3c/payment-request#224 (9 comments by @adrianhopebailie, @mattsaxon, @rvm4, @webpayments-specs)
-
-
2 pull requests opened.
-
an event to providing standards for push payment methods w3c/payment-request#223, by @rvm4.
-
Removing notes for closed issues. w3c/payment-request#222, by @adrianba.
-
-
2 pull requests merged.
-
Removing notes for closed issues. w3c/payment-request#222.
-
Fix a minor typo in PaymentRequest constructor description. w3c/payment-request#221.
-
-
1 pull request received 7 new comments.
-
an event to providing standards for push payment methods w3c/payment-request#223 (7 comments by @adrianhopebailie, @ianbjacobs, @rvm4)
-
w3c/web-based-payment-handler
-
8 issues opened.
-
Is the concept of payment app registration necessary? w3c/web-based-payment-handler#8, by @jnormore.
-
Split out enabled and supported methods w3c/web-based-payment-handler#7, by @adrianhopebailie.
-
Should we allow payment providers to issue queries about their installed payment apps (match on origin) w3c/web-based-payment-handler#6, by @adrianhopebailie.
-
Display may be subject to user and local policy (consider UA making security decisions etc) w3c/web-based-payment-handler#5, by @adrianhopebailie.
-
What is the process for rendering the payment app UI w3c/web-based-payment-handler#4, by @adrianhopebailie.
-
PROPOSAL: Payment Apps are javascript code that use event listeners to get the PaymentRequest w3c/web-based-payment-handler#3, by @adrianhopebailie.
-
What portion of the PaymentRequest is sent to the payment app? w3c/web-based-payment-handler#2, by @adrianhopebailie.
-
Should merchants be able to limit matching to trusted apps? w3c/web-based-payment-handler#1, by @adrianhopebailie.
-
-
2 issues closed.
-
What portion of the PaymentRequest is sent to the payment app? w3c/web-based-payment-handler#2.
-
PROPOSAL: Payment Apps are javascript code that use event listeners to get the PaymentRequest w3c/web-based-payment-handler#3.
-
-
3 issues received 24 new comments.
-
Is the concept of payment app registration necessary? w3c/web-based-payment-handler#8 (21 comments by @adrianhopebailie, @halindrome, @ianbjacobs, @jnormore, @msporny, @sideshowbarker, @tommythorsen, @webpayments-specs)
-
What portion of the PaymentRequest is sent to the payment app? w3c/web-based-payment-handler#2 (2 comments by @ianbjacobs, @webpayments-specs)
-
PROPOSAL: Payment Apps are javascript code that use event listeners to get the PaymentRequest w3c/web-based-payment-handler#3 (1 comment by @adrianhopebailie)
-
w3c/payment-method-id
-
1 pull request opened.
-
slight rewording w3c/payment-method-id#6, by @dret.
-
-
1 pull request merged.
-
Update references and issue markers w3c/payment-method-id#4.
-
Participants
-
1 organization joined.
-
American Express Company joined.
-
GitHub
w3c/webpayments
-
4 issues opened.
-
[Payment apps] How should third-party payment apps be displayed by the browser? w3c/webpayments#143, by @ianbjacobs.
-
[Payment apps] Should payment instrument details be included at registration? w3c/webpayments#142, by @ianbjacobs.
-
What happens if there’s a failure before the payment response promise resolves? w3c/webpayments#141, by @maheshkk.
-
Should the browser pass user data it has collected (email etc) to the payment app? w3c/webpayments#137, by @adrianhopebailie.
-
-
7 issues received 32 new comments.
-
Terminology across all Web Payments documents should be aligned w3c/webpayments#135 (10 comments by @adrianhopebailie, @dezell, @msporny, @tommythorsen)
-
What happens if there’s a failure before the payment response promise resolves? w3c/webpayments#141 (7 comments by @adrianhopebailie, @ianbjacobs, @nickjshearer, @rsolomakhin)
-
Registration: How is registration information updated? w3c/webpayments#111 (5 comments by @adrianhopebailie, @ianbjacobs, @rsolomakhin)
-
[Payment apps] How should third-party payment apps be displayed by the browser? w3c/webpayments#143 (5 comments by @adrianhopebailie, @rsolomakhin, @tnguyen14)
-
Registration: Should we support payee knowing user has payee-controlled payment app? w3c/webpayments#112 (2 comments by @msporny)
-
[Payment apps] Should payment instrument details be included at registration? w3c/webpayments#142 (1 comment by @adrianhopebailie)
-
-
11 pull requests opened.
-
Fix payment options references + proposal on recommended apps w3c/webpayments#150, by @LaurentCastillo.
-
Include the IG terminology document w3c/webpayments#149, by @tommythorsen.
-
Api shape and payment options w3c/webpayments#148, by @adrianhopebailie.
-
Update conformance w3c/webpayments#147, by @adrianhopebailie.
-
Adding issues to payment app specification w3c/webpayments#146, by @LaurentCastillo.
-
Moved notes and issues into markers to distinguish from spec text w3c/webpayments#145, by @adrianhopebailie.
-
Use notes and issues more consistently w3c/webpayments#144, by @ianbjacobs.
-
More info about UX around app recommendation and selection; network failures w3c/webpayments#140, by @ianbjacobs.
-
Editorial changes for more context w3c/webpayments#139, by @ianbjacobs.
-
Gh pages w3c/webpayments#138, by @ianbjacobs.
-
Some edits on @ianbjacobs refactoring w3c/webpayments#136, by @adrianhopebailie.
-
-
11 pull requests merged.
-
Include the IG terminology document w3c/webpayments#149.
-
Api shape and payment options w3c/webpayments#148.
-
Update conformance w3c/webpayments#147.
-
Adding issues to payment app specification w3c/webpayments#146.
-
Moved notes and issues into markers to distinguish from spec text w3c/webpayments#145.
-
Use notes and issues more consistently w3c/webpayments#144.
-
More info about UX around app recommendation and selection; network failures w3c/webpayments#140.
-
Editorial changes for more context w3c/webpayments#139.
-
Gh pages w3c/webpayments#138.
-
Some edits on @ianbjacobs refactoring w3c/webpayments#136.
-
Clarify the concepts of enabled vs. supported w3c/webpayments#132.
-
-
1 pull request closed.
-
Choosing between javascript and http communication. w3c/webpayments#131.
-
-
7 pull requests received 11 new comments.
-
More info about UX around app recommendation and selection; network failures w3c/webpayments#140 (3 comments by @adrianhopebailie, @andrewpaliga, @ianbjacobs)
-
Fix payment options references + proposal on recommended apps w3c/webpayments#150 (1 comment by @webpayments)
-
Choosing between javascript and http communication. w3c/webpayments#131 (1 comment by @adrianhopebailie)
w3c/payment-request
-
3 issues opened.
-
Update references to "Payment Transaction Message Specification" w3c/payment-request#218, by @adrianhopebailie.
-
What about billing address w3c/payment-request#216, by @hwclass.
-
Should PaymentResponse include totalAmount and if so must it be one of the supplied totals w3c/payment-request#215, by @adrianba.
-
-
28 issues closed.
-
Should PaymentResponse include totalAmount and if so must it be one of the supplied totals w3c/payment-request#215.
-
How are web-based payment apps supported? w3c/payment-request#39.
-
Specifying Mandatory Data w3c/payment-request#97.
-
What is the extensibility mechanism for the payment request and response messages? w3c/payment-request#146.
-
Add section on Extensibility w3c/payment-request#44.
-
Write-up initial proposal for payment app registration spec w3c/payment-request#12.
-
Should the browser pass user data it has collected (email etc) to the payment app? w3c/payment-request#194.
-
Combine API parameters into a single request object + options w3c/payment-request#15.
-
How will the spec address versioning / feature detection? w3c/payment-request#33.
-
Any plan to allow this API to be called by non-merchants? w3c/payment-request#35.
-
Merge Payment Request Architecture with Capabilities Document w3c/payment-request#42.
-
Should Payment Method Identifiers and Messages be expressed using a Linked Data Vocabulary? w3c/payment-request#45.
-
Should the payment API be more conversational or less conversational? w3c/payment-request#51.
-
Add section on internationalization w3c/payment-request#53.
-
What component does the payment method intersection? w3c/payment-request#103.
-
Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? w3c/payment-request#109.
-
Should show() be renamed? w3c/payment-request#127.
-
Dynamic Currency Conversion (DCC) Support w3c/payment-request#178.
-
Update "user accepts the payment request algorithm" to include interaction with payment app w3c/payment-request#192.
-
What about billing address w3c/payment-request#216.
-
Update promise rejection w3c/payment-request#187.
-
Should it be possible to vary amounts depending on payment method w3c/payment-request#4.
-
Spec prohibits currency validation but doesn't define what it is w3c/payment-request#175.
-
Should we support a delegated state for PaymentRequest? w3c/payment-request#7.
-
Terms and conditions next to "Pay" button w3c/payment-request#195.
-
-
32 issues received 111 new comments.
-
Currency Types and Rendering w3c/payment-request#185 (18 comments by @adamroach, @adrianhopebailie, @ianbjacobs, @msporny, @rsolomakhin)
-
How will the spec address versioning / feature detection? w3c/payment-request#33 (16 comments by @adamroach, @adrianba, @adrianhopebailie, @ianbjacobs, @msporny, @rsolomakhin)
-
Should the Payment Request API only be available in a top-level browsing context? w3c/payment-request#2 (8 comments by @adamroach, @adrianhopebailie, @dlongley, @sideshowbarker, @webpayments-specs, @zkoch)
-
How are web-based payment apps supported? w3c/payment-request#39 (7 comments by @adrianhopebailie, @ianbjacobs, @msporny)
-
Should PaymentResponse include totalAmount and if so must it be one of the supplied totals w3c/payment-request#215 (7 comments by @adrianhopebailie, @dlongley, @ianbjacobs, @msporny)
-
Any plan to allow this API to be called by non-merchants? w3c/payment-request#35 (5 comments by @adrianhopebailie, @dlongley, @msporny)
-
How are payment requests and responses passed between the browser and third-party native wallets? w3c/payment-request#50 (5 comments by @adrianhopebailie, @cyberphone, @ianbjacobs, @msporny)
-
Specifying Mandatory Data w3c/payment-request#97 (4 comments by @adrianhopebailie, @ianbjacobs, @msporny)
-
Should payment app registration be included in the conformance criteria of the browser API spec? w3c/payment-request#8 (4 comments by @adrianhopebailie, @tnguyen14)
-
Update promise rejection w3c/payment-request#187 (4 comments by @adamroach, @adrianba, @adrianhopebailie)
-
Merge Payment Request Architecture with Capabilities Document w3c/payment-request#42 (3 comments by @adrianhopebailie, @ianbjacobs, @msporny)
-
Add section on internationalization w3c/payment-request#53 (3 comments by @adrianhopebailie, @ianbjacobs, @msporny)
-
Combine API parameters into a single request object + options w3c/payment-request#15 (2 comments by @adrianhopebailie, @msporny)
-
Is it neccessary to distinguish the origin of data provided in the payment response, and how would we do it? w3c/payment-request#173 (2 comments by @adrianhopebailie, @msporny)
-
Update "user accepts the payment request algorithm" to include interaction with payment app w3c/payment-request#192 (2 comments by @adrianba, @adrianhopebailie)
-
Propose a payment method specification that includes an example of field level security w3c/payment-request#141 (1 comment by @rsolomakhin)
-
Should it be possible to provide "total" amounts in more than one currency w3c/payment-request#3 (1 comment by @adrianba)
-
What is the extensibility mechanism for the payment request and response messages? w3c/payment-request#146 (1 comment by @adrianhopebailie)
-
Write-up initial proposal for payment app registration spec w3c/payment-request#12 (1 comment by @adrianhopebailie)
-
Should the browser pass user data it has collected (email etc) to the payment app? w3c/payment-request#194 (1 comment by @adrianhopebailie)
-
Should the payment API be more conversational or less conversational? w3c/payment-request#51 (1 comment by @adrianhopebailie)
-
What component does the payment method intersection? w3c/payment-request#103 (1 comment by @adrianhopebailie)
-
Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? w3c/payment-request#109 (1 comment by @adrianhopebailie)
-
Should it be possible to vary amounts depending on payment method w3c/payment-request#4 (1 comment by @adrianba)
-
Should we support a delegated state for PaymentRequest? w3c/payment-request#7 (1 comment by @adrianba)
-
-
11 pull requests opened.
-
Fix a minor typo in PaymentRequest constructor description. w3c/payment-request#221, by @romandev.
-
Fix two minor typos. w3c/payment-request#220, by @romandev.
-
Remove totalAmount per telcon resolution. w3c/payment-request#219, by @adrianba.
-
Add shippingOption to response w3c/payment-request#217, by @adrianba.
-
Removing notes for closed issues. w3c/payment-request#214, by @adrianba.
-
Remove unnecessary clause about validation. w3c/payment-request#213, by @adrianba.
-
Simple editorial fixes. w3c/payment-request#212, by @adrianba.
-
Support different amounts per payment method. w3c/payment-request#211, by @adrianba.
-
Remove special case handling for single shipping option. w3c/payment-request#210, by @adrianba.
-
Proposal to abort if updateWith promise is rejected w3c/payment-request#209, by @adrianba.
-
Rename remaining types so that all begin Payment* w3c/payment-request#208, by @adrianba.
-
-
8 pull requests merged.
-
Fix two minor typos. w3c/payment-request#220.
-
Remove totalAmount per telcon resolution. w3c/payment-request#219.
-
Add shippingOption to response w3c/payment-request#217.
-
Remove unnecessary clause about validation. w3c/payment-request#213.
-
Removing notes for closed issues. w3c/payment-request#214.
-
Simple editorial fixes. w3c/payment-request#212.
-
Rename remaining types so that all begin Payment* w3c/payment-request#208.
-
Move PMI and Card specs out of repo w3c/payment-request#207.
-
-
3 pull requests closed.
-
Proposal to abort if updateWith promise is rejected w3c/payment-request#209.
-
Remove special case handling for single shipping option. w3c/payment-request#210.
-
Support different amounts per payment method. w3c/payment-request#211.
-
-
8 pull requests received 23 new comments.
-
Support different amounts per payment method. w3c/payment-request#211 (8 comments by @adrianba, @dlongley, @ianbjacobs, @rsolomakhin)
-
Proposal to abort if updateWith promise is rejected w3c/payment-request#209 (4 comments by @adamroach, @adrianba, @adrianhopebailie, @rsolomakhin)
-
Remove special case handling for single shipping option. w3c/payment-request#210 (4 comments by @adrianba, @adrianhopebailie, @ianbjacobs, @rsolomakhin)
-
Remove unnecessary clause about validation. w3c/payment-request#213 (2 comments by @adrianhopebailie, @ianbjacobs)
-
Rename remaining types so that all begin Payment* w3c/payment-request#208 (2 comments by @adrianhopebailie, @webpayments-specs)
-
w3c/payment-method-id
-
1 issue opened.
-
PROPOSAL: PMI identifies payment method specification, use meta-data for additional granularity w3c/payment-method-id#5, by @adrianhopebailie.
-
-
1 issue closed.
-
PROPOSAL: Use query string parameters for PMI matching w3c/payment-method-id#2.
-
-
3 issues received 30 new comments.
-
PROPOSAL: PMI identifies payment method specification, use meta-data for additional granularity w3c/payment-method-id#5 (25 comments by @adrianhopebailie, @dlongley, @ianbjacobs, @msporny, @rsolomakhin)
-
Should we define nesting/grouping semantics for payment method identifier matching? w3c/payment-method-id#1 (4 comments by @ianbjacobs, @rsolomakhin)
-
PROPOSAL: Use query string parameters for PMI matching w3c/payment-method-id#2 (1 comment by @adrianhopebailie)
-
Participants
-
2 organizations joined.
-
Gemalto SA joined.
-
Center for Democracy and Technology joined.
-
GitHub
w3c/payment-request
-
14 issues opened.
-
PROPOSAL: Payment Method Identifiers taking advantage of URL characteristics w3c/payment-request#205, by @adrianhopebailie.
-
Should the amount be in decimal or cents? w3c/payment-request#204, by @pazguille.
-
Why another API? w3c/payment-request#203, by @tjconcept.
-
Concern on Payment Method Identifier requirement w3c/payment-request#200, by @maoyanhua.
-
Storing card information w3c/payment-request#199, by @adamroach.
-
Terms and conditions next to "Pay" button w3c/payment-request#195, by @rsolomakhin.
-
Should the browser pass user data it has collected (email etc) to the payment app? w3c/payment-request#194, by @mattsaxon.
-
Update "user accepts the payment request algorithm" to include interaction with payment app w3c/payment-request#192, by @adrianhopebailie.
-
ShippingAddress versus Address w3c/payment-request#189, by @adamroach.
-
Time validity of updateWith() w3c/payment-request#188, by @adamroach.
-
Update promise rejection w3c/payment-request#187, by @adamroach.
-
shippingAddress and "c/o" field w3c/payment-request#186, by @adamroach.
-
Currency Types and Rendering w3c/payment-request#185, by @adamroach.
-
Dynamic Currency Conversion (DCC) Support w3c/payment-request#178, by @rlovetx.
-
-
29 issues closed.
-
PROPOSAL: Payment Method Identifiers taking advantage of URL characteristics w3c/payment-request#205.
-
Should well-known identifiers be used for ubiquitous payment methods w3c/payment-request#10.
-
Should we define nesting/grouping semantics for payment method identifier matching? w3c/payment-request#30.
-
General Comment on Registry Design w3c/payment-request#148.
-
Registry Access/Handling Registry Change w3c/payment-request#151.
-
Terminology across all Web Payments documents should be aligned w3c/payment-request#43.
-
PROPOSAL: A new document structure for this API w3c/payment-request#138.
-
Storing card information w3c/payment-request#199.
-
Should payment method specifications contain WebIDL? w3c/payment-request#132.
-
[basic] Reference trademarks w3c/payment-request#94.
-
Specification to include Flow Diagram w3c/payment-request#32.
-
Should the API handle pre-auth, recurring payments, and similar scenarios w3c/payment-request#19.
-
Concern on Payment Method Identifier requirement w3c/payment-request#200.
-
Why another API? w3c/payment-request#203.
-
Should the amount be in decimal or cents? w3c/payment-request#204.
-
Use navigator.payments singleton, factory method, or PaymentRequest constructor w3c/payment-request#16.
-
ShippingAddress versus Address w3c/payment-request#189.
-
shippingAddress and "c/o" field w3c/payment-request#186.
-
Should the browser API support the concept of "messages"? w3c/payment-request#154.
-
Identifiers or Locators w3c/payment-request#150.
-
Consider revising the design of complete() w3c/payment-request#122.
-
What is the format for payment method identifiers for distributed extensibility w3c/payment-request#11.
-
Time validity of updateWith() w3c/payment-request#188.
-
Should the merchant be able to request your email and recipient phone number w3c/payment-request#1.
-
What semantics is needed for payment method specific data? w3c/payment-request#143.
-
BasicCardResponse: cardholderName should be optional. w3c/payment-request#134.
-
Spec should use [SecureContext] once that is defined in Web IDL w3c/payment-request#22.
-
Support for negative amounts w3c/payment-request#119.
-
45 issues received 240 new comments.
-
Currency Types and Rendering w3c/payment-request#185 (45 comments by @adamroach, @adrianhopebailie, @davidlehn, @dlongley, @ianbjacobs, @msporny, @rsolomakhin, @tommythorsen)
-
Use navigator.payments singleton, factory method, or PaymentRequest constructor w3c/payment-request#16 (15 comments by @adrianba, @adrianhopebailie, @dlongley, @msporny, @rsolomakhin)
-
Spec prohibits currency validation but doesn't define what it is w3c/payment-request#175 (14 comments by @adamroach, @adrianba, @adrianhopebailie, @halindrome, @ianbjacobs, @kirkalx, @rsolomakhin)
-
PROPOSAL: Payment Method Identifiers taking advantage of URL characteristics w3c/payment-request#205 (12 comments by @adamroach, @adrianhopebailie, @ianbjacobs, @msporny, @rsolomakhin, @sideshowbarker)
-
Should it be possible to vary amounts depending on payment method w3c/payment-request#4 (11 comments by @adamroach, @adrianhopebailie, @jnormore, @msporny, @rsolomakhin, @tommythorsen, @webpayments-specs)
-
Should well-known identifiers be used for ubiquitous payment methods w3c/payment-request#10 (10 comments by @adrianhopebailie, @dret, @msporny, @rsolomakhin, @sideshowbarker)
-
Should we define nesting/grouping semantics for payment method identifier matching? w3c/payment-request#30 (10 comments by @adamroach, @adrianhopebailie, @dlongley, @ianbjacobs, @maoyanhua, @msporny)
-
Dynamic Currency Conversion (DCC) Support w3c/payment-request#178 (10 comments by @adrianhopebailie, @dlongley, @fredMeignien, @ianbjacobs, @rlovetx, @rsolomakhin)
-
Why another API? w3c/payment-request#203 (10 comments by @adamroach, @adrianhopebailie, @burdges, @dlongley, @ianbjacobs, @tjconcept)
-
ShippingAddress versus Address w3c/payment-request#189 (9 comments by @adamroach, @adrianba, @halindrome, @rsolomakhin, @tommythorsen)
-
Update "user accepts the payment request algorithm" to include interaction with payment app w3c/payment-request#192 (8 comments by @adamroach, @adrianba, @adrianhopebailie, @burdges, @dlongley, @ianbjacobs)
-
Add type to PaymentItem w3c/payment-request#163 (8 comments by @adrianhopebailie, @halindrome, @ianbjacobs, @nickjshearer, @rvm4)
-
Storing card information w3c/payment-request#199 (7 comments by @adamroach, @adrianhopebailie, @mattsaxon, @nickjshearer, @rsolomakhin)
-
Update promise rejection w3c/payment-request#187 (6 comments by @adamroach, @adrianba, @adrianhopebailie)
-
Registry Access/Handling Registry Change w3c/payment-request#151 (5 comments by @adrianhopebailie, @dret, @ianbjacobs)
-
Concern on Payment Method Identifier requirement w3c/payment-request#200 (5 comments by @adrianhopebailie, @ianbjacobs, @maoyanhua)
-
Terms and conditions next to "Pay" button w3c/payment-request#195 (5 comments by @adrianhopebailie, @nickjshearer, @rsolomakhin)
-
Should API support billing address capture (for tax computation)? w3c/payment-request#27 (4 comments by @adrianhopebailie, @dlongley, @ianbjacobs)
-
Should the amount be in decimal or cents? w3c/payment-request#204 (4 comments by @adamroach, @adrianhopebailie, @dlongley, @rsolomakhin)
-
What is the format for payment method identifiers for distributed extensibility w3c/payment-request#11 (4 comments by @adrianba, @dlongley, @ianbjacobs, @msporny)
-
Should the browser pass user data it has collected (email etc) to the payment app? w3c/payment-request#194 (3 comments by @burdges, @ianbjacobs, @rsolomakhin)
-
Time validity of updateWith() w3c/payment-request#188 (3 comments by @adamroach, @adrianba, @adrianhopebailie)
-
Should it be possible to provide "total" amounts in more than one currency w3c/payment-request#3 (3 comments by @adrianhopebailie, @rlovetx)
-
Should a payment method identifier (URL) resolve to a machine readable resource that describes it? w3c/payment-request#46 (2 comments by @adrianhopebailie, @dlongley)
-
Should the browser API support the concept of "messages"? w3c/payment-request#154 (2 comments by @adrianhopebailie, @ianbjacobs)
-
Should the payment mediator pass all payment method data to the payment app or just relevant data? w3c/payment-request#157 (2 comments by @adrianhopebailie)
-
What semantics is needed for payment method specific data? w3c/payment-request#143 (2 comments by @ianbjacobs)
-
Consider revising the design of complete() w3c/payment-request#122 (2 comments by @adamroach, @dlongley)
-
Terminology across all Web Payments documents should be aligned w3c/payment-request#43 (1 comment by @adrianhopebailie)
-
PROPOSAL: A new document structure for this API w3c/payment-request#138 (1 comment by @adrianhopebailie)
-
Should payment method specifications contain WebIDL? w3c/payment-request#132 (1 comment by @adrianhopebailie)
-
Is it neccessary to distinguish the origin of data provided in the payment response, and how would we do it? w3c/payment-request#173 (1 comment by @rsolomakhin)
-
What happens when currency of offer differs from currency of selected payment instrument? w3c/payment-request#29 (1 comment by @rsolomakhin)
-
Should the API handle pre-auth, recurring payments, and similar scenarios w3c/payment-request#19 (1 comment by @adrianhopebailie)
-
Should Payment Method Identifiers and Messages be expressed using a Linked Data Vocabulary? w3c/payment-request#45 (1 comment by @ianbjacobs)
-
What component does the payment method intersection? w3c/payment-request#103 (1 comment by @ianbjacobs)
-
Should the Payment Request API only be available in a top-level browsing context? w3c/payment-request#2 (1 comment by @adrianhopebailie)
-
BasicCardResponse: cardholderName should be optional. w3c/payment-request#134 (1 comment by @adrianba)
-
-
16 pull requests opened.
-
Move PMI and Card specs out of repo w3c/payment-request#207, by @adrianhopebailie.
-
Fix bug in updateWith algorithm that resets shippingOption w3c/payment-request#206, by @adrianba.
-
Add missing curly bracket w3c/payment-request#202, by @derekjohnson.
-
Removing erroneous <svg> clip boundaries w3c/payment-request#201, by @adamroach.
-
Address alignment w3c/payment-request#198, by @adamroach.
-
Care of w3c/payment-request#197, by @adamroach.
-
adding careOf field w3c/payment-request#196, by @adamroach.
-
Rename the address type since it will likely be used for other purposes. w3c/payment-request#193, by @adrianba.
-
Explain how to treat unrecognised complete values w3c/payment-request#191, by @adrianba.
-
Remove delegated state and make abort() return a promise w3c/payment-request#190, by @adrianba.
-
setup CI for automatic publications with echidna w3c/payment-request#184, by @deniak.
-
Update to method identifiers spec to use absolute URLs w3c/payment-request#183, by @adrianba.
-
Reject acceptPromise on abort() w3c/payment-request#182, by @adrianba.
-
Clarified value to use to resove [[acceptPromise]] w3c/payment-request#181, by @adamroach.
-
Fix two minor typos w3c/payment-request#180, by @adamroach.
-
Add support for ShippingOption.selected. w3c/payment-request#179, by @adrianba.
-
-
5 pull requests merged.
-
Fix bug in updateWith algorithm that resets shippingOption w3c/payment-request#206.
-
Add missing curly bracket w3c/payment-request#202.
-
Clarified value to use to resove [[acceptPromise]] w3c/payment-request#181.
-
Fix two minor typos w3c/payment-request#180.
-
Losen requirements around Credit Card required fields w3c/payment-request#176.
-
-
15 pull requests closed.
-
Removing erroneous <svg> clip boundaries w3c/payment-request#201.
-
Care of w3c/payment-request#197.
-
Address alignment w3c/payment-request#198.
-
Add support for ShippingOption.selected. w3c/payment-request#179.
-
Remove delegated state and make abort() return a promise w3c/payment-request#190.
-
Rename the address type since it will likely be used for other purposes. w3c/payment-request#193.
-
adding careOf field w3c/payment-request#196.
-
Explain how to treat unrecognised complete values w3c/payment-request#191.
-
Update to method identifiers spec to use absolute URLs w3c/payment-request#183.
-
Reject acceptPromise on abort() w3c/payment-request#182.
-
Change the way we request user data w3c/payment-request#65.
-
Adding support for phone and email w3c/payment-request#174.
-
setup CI for automatic publications with echidna w3c/payment-request#184.
-
Updated to use [SecureContext] extended attribute. w3c/payment-request#172.
-
Remove issue #119 note and assert that total should be non-negative w3c/payment-request#168.
-
-
20 pull requests received 81 new comments.
-
API flow w3c/payment-request#177 (14 comments by @adrianba, @adrianhopebailie, @fredMeignien, @ianbjacobs, @mattsaxon)
-
Add support for ShippingOption.selected. w3c/payment-request#179 (11 comments by @adamroach, @adrianba, @adrianhopebailie, @msporny, @rvm4)
-
Updated to use [SecureContext] extended attribute. w3c/payment-request#172 (8 comments by @adrianba, @adrianhopebailie, @davidlehn, @msporny, @zkoch)
-
Remove delegated state and make abort() return a promise w3c/payment-request#190 (7 comments by @adrianba, @adrianhopebailie)
-
Adding support for phone and email w3c/payment-request#174 (6 comments by @adrianba, @ianbjacobs, @mattsaxon, @rvm4, @zkoch)
-
Losen requirements around Credit Card required fields w3c/payment-request#176 (6 comments by @adrianba, @adrianhopebailie, @halindrome, @mattsaxon, @zkoch)
-
Update to method identifiers spec to use absolute URLs w3c/payment-request#183 (4 comments by @adrianba, @dlongley, @ianbjacobs)
-
Reject acceptPromise on abort() w3c/payment-request#182 (4 comments by @adamroach, @adrianba, @adrianhopebailie, @zkoch)
-
Fix #129 w3c/payment-request#153 (4 comments by @adrianhopebailie, @hober, @mattsaxon, @nickjshearer)
-
setup CI for automatic publications with echidna w3c/payment-request#184 (3 comments by @adrianhopebailie, @deniak, @ianbjacobs)
-
Rename the address type since it will likely be used for other purposes. w3c/payment-request#193 (1 comment by @adrianba)
-
Clarified value to use to resove [[acceptPromise]] w3c/payment-request#181 (1 comment by @adrianhopebailie)
-
Remove issue #119 note and assert that total should be non-negative w3c/payment-request#168 (1 comment by @adrianba)
-
w3c/webpayments
-
4 issues opened.
-
Terminology across all Web Payments documents should be aligned w3c/webpayments#135, by @adrianhopebailie.
-
PROPOSAL: A new document structure for this API w3c/webpayments#134, by @adrianhopebailie.
-
Should payment method specifications contain WebIDL? w3c/webpayments#133, by @adrianhopebailie.
-
Letting the payment app decide between HTTP and Javascript communication w3c/webpayments#130, by @tommythorsen.
-
-
1 issue closed.
-
Update reference labels to match other docs w3c/webpayments#117.
-
-
7 issues received 40 new comments.
-
Letting the payment app decide between HTTP and Javascript communication w3c/webpayments#130 (23 comments by @adamroach, @adrianhopebailie, @cyberphone, @ianbjacobs, @jnormore, @tommythorsen)
-
Registration: App supports method but user has no instrument for that method w3c/webpayments#110 (6 comments by @adrianhopebailie, @ianbjacobs, @tommythorsen)
-
Terminology across all Web Payments documents should be aligned w3c/webpayments#135 (5 comments by @adrianhopebailie, @ianbjacobs, @msporny)
-
Should payment method specifications contain WebIDL? w3c/webpayments#133 (3 comments by @adrianhopebailie, @AxelNennker)
-
How can a Web Based Payment App cancel the payment flow? w3c/webpayments#128 (1 comment by @jnormore)
-
-
3 pull requests opened.
-
Clarify the concepts of enabled vs. supported w3c/webpayments#132, by @tommythorsen.
-
Choosing between javascript and http communication. w3c/webpayments#131, by @tommythorsen.
-
Payment Apps w3c/webpayments#129, by @adrianhopebailie.
-
-
1 pull request merged.
-
Payment Apps w3c/webpayments#129.
-
-
4 pull requests received 20 new comments.
-
Clarify the concepts of enabled vs. supported w3c/webpayments#132 (9 comments by @adrianhopebailie, @fredMeignien, @ianbjacobs, @jnormore, @tommythorsen, @webpayments)
-
Payment Apps w3c/webpayments#129 (7 comments by @adamroach, @adrianhopebailie, @ianbjacobs, @jnormore, @tommythorsen)
-
Choosing between javascript and http communication. w3c/webpayments#131 (3 comments by @dlongley, @ianbjacobs, @tommythorsen)
-
w3c/payment-method-id
-
3 issues opened.
-
Should a payment method identifier (URL) resolve to a machine readable resource that describes it? w3c/payment-method-id#3, by @adrianhopebailie.
-
PROPOSAL: Use query string parameters for PMI matching w3c/payment-method-id#2, by @adrianhopebailie.
-
Should we define nesting/grouping semantics for payment method identifier matching? w3c/payment-method-id#1, by @adrianhopebailie.
-
-
1 issue received 1 new comment.
-
Should a payment method identifier (URL) resolve to a machine readable resource that describes it? w3c/payment-method-id#3 (1 comment by @adrianhopebailie)
-
-
1 pull request opened.
-
Update references and issue markers w3c/payment-method-id#4, by @adrianhopebailie.
-
w3c/webpayments-flows
-
1 pull request opened.
-
Simplified Flow w3c/webpayments-flows#11, by @mattsaxon.
-
-
1 pull request merged.
-
Simplified Flow w3c/webpayments-flows#11.
-
TR publications
-
3 documents published.
-
Basic Card Payment published as a First Public Working Draft. History of Basic Card Payment
-
Payment Method Identifiers published as a First Public Working Draft. History of Payment Method Identifiers
-
Payment Request API published as a First Public Working Draft. History of Payment Request API
-
Participants
-
3 organizations joined.
-
Blockstream joined.
-
Tencent joined.
-
Spec-Ops joined.
-
GitHub
w3c/payment-request
-
28 issues opened.
-
Spec prohibits currency validation but doesn't define what it is w3c/payment-request#175, by @adrianba.
-
Examples need updating with recent PRs w3c/payment-request#164, by @adrianba.
-
Add type to PaymentItem w3c/payment-request#163, by @rvm4.
-
Should the payment mediator pass all payment method data to the payment app or just relevant data? w3c/payment-request#157, by @adrianhopebailie.
-
Payment app discovery w3c/payment-request#155, by @andrewpaliga.
-
Should the browser API support the concept of "messages"? w3c/payment-request#154, by @adrianhopebailie.
-
Registry Access/Handling Registry Change w3c/payment-request#151, by @dret.
-
Identifiers or Locators w3c/payment-request#150, by @dret.
-
Do we need payment method identifier aliases? w3c/payment-request#149, by @dret.
-
General Comment on Registry Design w3c/payment-request#148, by @dret.
-
What is the extensibility mechanism for the payment request and response messages? w3c/payment-request#146, by @adrianhopebailie.
-
Support for gift cards and discount codes w3c/payment-request#145, by @andrewpaliga.
-
What semantics is needed for payment method specific data? w3c/payment-request#143, by @ianbjacobs.
-
Propose a payment method specification that includes an example of field level security w3c/payment-request#141, by @adrianhopebailie.
-
PROPOSAL: A new document structure for this API w3c/payment-request#138, by @adrianhopebailie.
-
BasicCardResponse: cardholderName should be optional. w3c/payment-request#134, by @Torlus.
-
Should payment method specifications contain WebIDL? w3c/payment-request#132, by @adrianhopebailie.
-
complete does not talk to the Payment App w3c/payment-request#129, by @AxelNennker.
-
Add explicit note that shippingOptions is only required if requesting shipping w3c/payment-request#128, by @adrianhopebailie.
-
Should show() be renamed? w3c/payment-request#127, by @adrianhopebailie.
-
How can short payment method identifiers be successful w3c/payment-request#123, by @rvm4.
-
Consider revising the design of complete() w3c/payment-request#122, by @adrianhopebailie.
-
Update Introduction to describe actors better w3c/payment-request#121, by @adrianhopebailie.
-
Support for negative amounts w3c/payment-request#119, by @adrianhopebailie.
-
Review and respond to Andrew Betts’ TAG review of the spec w3c/payment-request#118, by @sideshowbarker.
-
How do the payer and payee agree on the payment obligation as part of the flow? w3c/payment-request#113, by @adrianhopebailie.
-
Should the list of transaction types be extensible? w3c/payment-request#112, by @adrianhopebailie.
-
-
26 issues closed.
-
[api] Section 11 PaymentResponse seems to be missing shippingAddress w3c/payment-request#75.
-
Add explicit note that shippingOptions is only required if requesting shipping w3c/payment-request#128.
-
Do we need payment method identifier aliases? w3c/payment-request#149.
-
complete does not talk to the Payment App w3c/payment-request#129.
-
Should list of accepted payment methods be strings or objects? w3c/payment-request#48.
-
Examples need updating with recent PRs w3c/payment-request#164.
-
complete() should take a string argument not boolean w3c/payment-request#17.
-
Constructor should not include "total" in list of items w3c/payment-request#18.
-
How are payment apps shared between different browser brands? w3c/payment-request#38.
-
Should the list of transaction types be extensible? w3c/payment-request#112.
-
Handling non-decimal currencies w3c/payment-request#14.
-
Write-up proposal for shipping address fields w3c/payment-request#6.
-
Issue Prioritisation Explainer w3c/payment-request#105.
-
Different card schemes have different mandatory field requirements w3c/payment-request#9.
-
Should the payee be able to inspect the status of a payment? w3c/payment-request#28.
-
How do organizations layer additional information in the core payment messages? w3c/payment-request#40.
-
Should a payment request be just data, or a programmable object? w3c/payment-request#47.
-
Should the payment request contain line item details? w3c/payment-request#49.
-
Should the messages support field-level encryption? w3c/payment-request#55.
-
[architecture] Reference names should have hyphens w3c/payment-request#63.
-
[api] Change e.g. to e.g., w3c/payment-request#66.
-
Review and respond to Andrew Betts’ TAG review of the spec w3c/payment-request#118.
-
[architecture] SotD should indicate it is intended to be a Note w3c/payment-request#58.
-
Basic Card Payment Spec will become a Note not a Rec w3c/payment-request#100.
-
How can short payment method identifiers be successful w3c/payment-request#123.
-
-
1 issue reopened.
-
BasicCardResponse: cardholderName should be optional. w3c/payment-request#134, by @mattsaxon.
-
-
66 issues received 395 new comments.
-
Identifiers or Locators w3c/payment-request#150 (36 comments by @adrianhopebailie, @dlongley, @dret, @halindrome, @ianbjacobs, @kirkalx)
-
PROPOSAL: A new document structure for this API w3c/payment-request#138 (27 comments by @adrianhopebailie, @dlongley, @dret, @ianbjacobs, @mattsaxon, @mountainhippo, @msporny)
-
Should the merchant be able to request your email and recipient phone number w3c/payment-request#1 (21 comments by @adrianhopebailie, @burdges, @djackso3, @dlongley, @ianbjacobs, @kirkalx, @mattsaxon, @msporny, @triblondon)
-
Payment app discovery w3c/payment-request#155 (20 comments by @adrianhopebailie, @andrewpaliga, @halindrome, @ianbjacobs, @kirkalx, @nickjshearer, @rsolomakhin)
-
Support for negative amounts w3c/payment-request#119 (16 comments by @adrianhopebailie, @corwinAmbre, @halindrome, @kirkalx, @lyverovski, @nickjshearer, @rvm4, @sideshowbarker, @webpayments-specs)
-
Constructor should not include "total" in list of items w3c/payment-request#18 (13 comments by @adrianhopebailie, @halindrome, @ianbjacobs, @kirkalx, @msporny, @nickjshearer)
-
How do the payer and payee agree on the payment obligation as part of the flow? w3c/payment-request#113 (13 comments by @adrianba, @adrianhopebailie, @corwinAmbre, @halindrome, @mattsaxon, @sideshowbarker, @triblondon)
-
Should the browser API support the concept of "messages"? w3c/payment-request#154 (12 comments by @adrianhopebailie, @burdges, @dlongley, @halindrome, @ianbjacobs, @msporny)
-
What semantics is needed for payment method specific data? w3c/payment-request#143 (11 comments by @adrianhopebailie, @dlongley, @ianbjacobs, @mattsaxon)
-
Should payment method specifications contain WebIDL? w3c/payment-request#132 (11 comments by @adrianhopebailie, @AxelNennker, @dezell, @dlongley, @halindrome, @msporny, @sideshowbarker)
-
What is the format for payment method identifiers for distributed extensibility w3c/payment-request#11 (10 comments by @dlongley, @halindrome, @ianbjacobs, @msporny, @rvm4, @sideshowbarker)
-
Write-up proposal for shipping address fields w3c/payment-request#6 (9 comments by @adrianba, @adrianhopebailie, @nickjshearer, @rsolomakhin)
-
Combine API parameters into a single request object + options w3c/payment-request#15 (8 comments by @adrianba, @adrianhopebailie, @halindrome, @msporny)
-
Should payment app registration be included in the conformance criteria of the browser API spec? w3c/payment-request#8 (8 comments by @adrianba, @adrianhopebailie, @dlongley, @ianbjacobs, @msporny)
-
What is the extensibility mechanism for the payment request and response messages? w3c/payment-request#146 (8 comments by @adrianhopebailie, @AxelNennker, @dlongley, @halindrome, @msporny)
-
Specification to include Flow Diagram w3c/payment-request#32 (8 comments by @adrianhopebailie, @mattsaxon, @msporny)
-
Use navigator.payments singleton, factory method, or PaymentRequest constructor w3c/payment-request#16 (8 comments by @adrianhopebailie, @msporny, @sideshowbarker, @triblondon)
-
Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app? w3c/payment-request#56 (8 comments by @adrianhopebailie, @mattsaxon, @rsolomakhin, @sideshowbarker)
-
Add type to PaymentItem w3c/payment-request#163 (7 comments by @adrianba, @adrianhopebailie, @halindrome, @rvm4, @sideshowbarker)
-
complete() should take a string argument not boolean w3c/payment-request#17 (7 comments by @adrianba, @adrianhopebailie, @dlongley, @jnormore, @mattsaxon)
-
Support for gift cards and discount codes w3c/payment-request#145 (7 comments by @adrianhopebailie, @andrewpaliga, @halindrome, @ianbjacobs)
-
Should the payment request contain line item details? w3c/payment-request#49 (7 comments by @adrianba, @adrianhopebailie, @corwinAmbre, @halindrome)
-
Should a payment request be just data, or a programmable object? w3c/payment-request#47 (6 comments by @adrianba, @adrianhopebailie)
-
Should show() be renamed? w3c/payment-request#127 (6 comments by @adrianhopebailie, @dlongley, @ianbjacobs, @msporny, @sideshowbarker, @zkoch)
-
BasicCardResponse: cardholderName should be optional. w3c/payment-request#134 (5 comments by @adrianhopebailie, @mattsaxon)
-
Do we need payment method identifier aliases? w3c/payment-request#149 (5 comments by @adrianba, @adrianhopebailie, @dret)
-
General Comment on Registry Design w3c/payment-request#148 (5 comments by @dret, @halindrome, @ianbjacobs)
-
Should the API handle pre-auth, recurring payments, and similar scenarios w3c/payment-request#19 (5 comments by @adrianhopebailie, @burdges, @mattsaxon, @triblondon)
-
Should API support billing address capture (for tax computation)? w3c/payment-request#27 (5 comments by @adrianhopebailie, @burdges, @djackso3, @halindrome)
-
Should it be possible to vary amounts depending on payment method w3c/payment-request#4 (5 comments by @adrianhopebailie, @djackso3, @mattsaxon)
-
Should the payment mediator pass all payment method data to the payment app or just relevant data? w3c/payment-request#157 (4 comments by @dlongley, @ianbjacobs)
-
How are web-based payment apps supported? w3c/payment-request#39 (4 comments by @adrianhopebailie, @dlongley, @msporny, @wayneca)
-
Propose a payment method specification that includes an example of field level security w3c/payment-request#141 (4 comments by @corwinAmbre, @halindrome, @lyverovski)
-
Should the messages support field-level encryption? w3c/payment-request#55 (4 comments by @adrianba, @adrianhopebailie, @burdges)
-
Should Payment Method Identifiers and Messages be expressed using a Linked Data Vocabulary? w3c/payment-request#45 (4 comments by @adrianba, @adrianhopebailie, @dlongley, @ianbjacobs)
-
Should the web page be able to provide status information before calling complete() w3c/payment-request#5 (4 comments by @adrianhopebailie, @ianbjacobs)
-
Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? w3c/payment-request#109 (4 comments by @adrianhopebailie, @burdges)
-
Should well-known identifiers be used for ubiquitous payment methods w3c/payment-request#10 (3 comments by @adrianhopebailie, @rvm4)
-
Spec prohibits currency validation but doesn't define what it is w3c/payment-request#175 (3 comments by @adrianba, @nickjshearer, @sideshowbarker)
-
[api] Section 11 PaymentResponse seems to be missing shippingAddress w3c/payment-request#75 (3 comments by @adrianba, @adrianhopebailie, @rvm4)
-
How do organizations layer additional information in the core payment messages? w3c/payment-request#40 (3 comments by @adrianhopebailie, @sideshowbarker)
-
Should a payment method identifier (URL) resolve to a machine readable resource that describes it? w3c/payment-request#46 (3 comments by @adrianhopebailie, @kirkalx)
-
How can short payment method identifiers be successful w3c/payment-request#123 (3 comments by @halindrome, @rvm4)
-
Add section on internationalization w3c/payment-request#53 (2 comments by @adrianba, @sideshowbarker)
-
Write-up initial proposal for payment app registration spec w3c/payment-request#12 (2 comments by @adrianhopebailie, @ianbjacobs)
-
How are payment apps shared between different browser brands? w3c/payment-request#38 (2 comments by @burdges, @ianbjacobs)
-
Any plan to allow this API to be called by non-merchants? w3c/payment-request#35 (2 comments by @adrianhopebailie, @dlongley)
-
Should the payment API be more conversational or less conversational? w3c/payment-request#51 (2 comments by @adrianba, @adrianhopebailie)
-
Should the Payment Request API only be available in a top-level browsing context? w3c/payment-request#2 (2 comments by @adrianhopebailie)
-
Is it neccessary to distinguish the origin of data provided in the payment response, and how would we do it? w3c/payment-request#173 (1 comment by @tommythorsen)
-
Should the list of transaction types be extensible? w3c/payment-request#112 (1 comment by @adrianhopebailie)
-
Different card schemes have different mandatory field requirements w3c/payment-request#9 (1 comment by @adrianhopebailie)
-
How are payment requests and responses passed between the browser and third-party native wallets? w3c/payment-request#50 (1 comment by @adrianhopebailie)
-
What component does the payment method intersection? w3c/payment-request#103 (1 comment by @adrianhopebailie)
-
How will the spec address versioning / feature detection? w3c/payment-request#33 (1 comment by @adrianba)
-
Should the payee be able to inspect the status of a payment? w3c/payment-request#28 (1 comment by @adrianba)
-
Should list of accepted payment methods be strings or objects? w3c/payment-request#48 (1 comment by @adrianhopebailie)
-
Should it be possible to provide "total" amounts in more than one currency w3c/payment-request#3 (1 comment by @adrianhopebailie)
-
Review and respond to Andrew Betts’ TAG review of the spec w3c/payment-request#118 (1 comment by @adrianhopebailie)
-
Can the merchant influence order of presentation of payment apps to the user w3c/payment-request#23 (1 comment by @adrianhopebailie)
-
-
37 pull requests opened.
-
API flow w3c/payment-request#177, by @mattsaxon.
-
Losen requirements around Credit Card required fields w3c/payment-request#176, by @mattsaxon.
-
Adding support for phone and email w3c/payment-request#174, by @adrianba.
-
Updated to use [SecureContext] extended attribute. w3c/payment-request#172, by @adrianba.
-
Add explicit note that shippingOptions is only required if requesting… w3c/payment-request#171, by @adrianba.
-
Update security and privacy considerations sections w3c/payment-request#170, by @adrianba.
-
Fix old reference to items and use total/displayItems w3c/payment-request#169, by @adrianba.
-
Remove issue #119 note and assert that total should be non-negative w3c/payment-request#168, by @adrianba.
-
Add previous publication metadata. w3c/payment-request#167, by @adrianba.
-
Updated examples to reflect changes in recent PRs w3c/payment-request#166, by @adrianba.
-
Remove issue #48 label. w3c/payment-request#165, by @adrianba.
-
Refactor the supportedMethods and payment specific data w3c/payment-request#162, by @adrianba.
-
Update complete() method to take a string and clarify its purpose w3c/payment-request#161, by @adrianba.
-
Remove id attribute from PaymentItem w3c/payment-request#160, by @adrianba.
-
Remove issue #14 note w3c/payment-request#159, by @adrianba.
-
Separate total from line items. w3c/payment-request#158, by @adrianba.
-
Fix #129 w3c/payment-request#153, by @adrianhopebailie.
-
fixing typo w3c/payment-request#152, by @dret.
-
Specify shipping address fields based on OASIS xAL. w3c/payment-request#147, by @rsolomakhin.
-
Removing references to closed issues #47 and #56. w3c/payment-request#144, by @adrianba.
-
Remove issue 55 note and add security considerations section. w3c/payment-request#142, by @adrianba.
-
Proposed text for issue 23. w3c/payment-request#140, by @adrianba.
-
provide shipping address in PaymentResponse w3c/payment-request#139, by @rvm4.
-
codemod user agent to payment mediator in payment request w3c/payment-request#137, by @rvm4.
-
provide partial shipping address in PaymentRequest and full shipping … w3c/payment-request#136, by @rvm4.
-
provide partial shipping address in PaymentRequest and full shipping … w3c/payment-request#135, by @rvm4.
-
Merged PaymentRequest params and tweaked to address some issues w3c/payment-request#133, by @adrianhopebailie.
-
Flows issue 32 w3c/payment-request#131, by @mattsaxon.
-
fields in abort() Update paymentrequest.html w3c/payment-request#130, by @AxelNennker.
-
Change e.g. to e.g., w3c/payment-request#126, by @adrianba.
-
Reference names should have hyphens w3c/payment-request#125, by @adrianba.
-
grammatical updates to the payment method identifier spec w3c/payment-request#124, by @rvm4.
-
Proposal to add negative value support w3c/payment-request#120, by @adrianhopebailie.
-
Replace non-RFC-2119 “may”s in normative text w3c/payment-request#117, by @sideshowbarker.
-
De-duplicate markup for “user agents” def w3c/payment-request#116, by @sideshowbarker.
-
Make other Payments-drafts refs be absolute URLs w3c/payment-request#115, by @sideshowbarker.
-
Specification of required fields w3c/payment-request#114, by @mattsaxon.
-
-
11 pull requests merged.
-
Add explicit note that shippingOptions is only required if requesting… w3c/payment-request#171.
-
Fix old reference to items and use total/displayItems w3c/payment-request#169.
-
Add previous publication metadata. w3c/payment-request#167.
-
Remove issue #14 note w3c/payment-request#159.
-
Remove id attribute from PaymentItem w3c/payment-request#160.
-
Proposed text for issue 23. w3c/payment-request#140.
-
Remove issue 55 note and add security considerations section. w3c/payment-request#142.
-
Removing references to closed issues #47 and #56. w3c/payment-request#144.
-
fixing typo w3c/payment-request#152.
-
Change e.g. to e.g., w3c/payment-request#126.
-
Make other Payments-drafts refs be absolute URLs w3c/payment-request#115.
-
-
37 pull requests closed.
-
Update security and privacy considerations sections w3c/payment-request#170.
-
provide shipping address in PaymentResponse w3c/payment-request#139.
-
Migrate PaymentRequest text from arch to payment request spec. w3c/payment-request#110.
-
Remove issue #48 label. w3c/payment-request#165.
-
Updated examples to reflect changes in recent PRs w3c/payment-request#166.
-
Merged PaymentRequest params and tweaked to address some issues w3c/payment-request#133.
-
Fix #129 w3c/payment-request#153.
-
Refactor the supportedMethods and payment specific data w3c/payment-request#162.
-
Separate total from line items. w3c/payment-request#158.
-
Update complete() method to take a string and clarify its purpose w3c/payment-request#161.
-
Specification of required fields w3c/payment-request#114.
-
grammatical updates to the payment method identifier spec w3c/payment-request#124.
-
Specify shipping address fields based on OASIS xAL. w3c/payment-request#147.
-
Flows issue 32 w3c/payment-request#131.
-
fields in abort() Update paymentrequest.html w3c/payment-request#130.
-
codemod user agent to payment mediator in payment request w3c/payment-request#137.
-
Add reference to issue #45. w3c/payment-request#79.
-
Add reference to issue #49. w3c/payment-request#83.
-
provide partial shipping address in PaymentRequest and full shipping … w3c/payment-request#136.
-
Reference names should have hyphens w3c/payment-request#125.
-
provide partial shipping address in PaymentRequest and full shipping … w3c/payment-request#135.
-
Add PaymentItem type to deal with transaction types w3c/payment-request#111.
-
Replace non-RFC-2119 “may”s in normative text w3c/payment-request#117.
-
De-duplicate markup for “user agents” def w3c/payment-request#116.
-
Proposal to add negative value support w3c/payment-request#120.
-
Currency amount w3c/payment-request#101.
-
Add option 1b to payment method identifier spec. w3c/payment-request#108.
-
Resubmitting because the document moved w3c/payment-request#106.
-
Issue marker requesting security considerations section w3c/payment-request#98.
-
Alternative issue marker for issue#38 w3c/payment-request#96.
-
Add a reference to issue #55. w3c/payment-request#87.
-
Add a reference to issue #51. w3c/payment-request#85.
-
Add a reference to issue #50. w3c/payment-request#84.
-
Add reference to issue #48. w3c/payment-request#82.
-
Add reference to issue #47. w3c/payment-request#81.
-
Add a reference to issue #39 w3c/payment-request#77.
-
Some friendly editorial changes w3c/payment-request#64.
-
-
49 pull requests received 224 new comments.
-
Merged PaymentRequest params and tweaked to address some issues w3c/payment-request#133 (27 comments by @adrianba, @adrianhopebailie, @dlongley, @halindrome, @msporny, @zkoch)
-
Change the way we request user data w3c/payment-request#65 (26 comments by @adrianba, @adrianhopebailie, @andrewpaliga, @dlongley, @ianbjacobs, @jnormore, @kirkalx, @nickjshearer, @rsolomakhin, @webpayments-specs)
-
Currency amount w3c/payment-request#101 (16 comments by @adrianba, @adrianhopebailie, @dlongley, @kirkalx)
-
Flows issue 32 w3c/payment-request#131 (15 comments by @adrianba, @adrianhopebailie, @AxelNennker, @ianbjacobs, @mattsaxon)
-
Add PaymentItem type to deal with transaction types w3c/payment-request#111 (14 comments by @adrianhopebailie, @davidillsley, @halindrome, @mattsaxon, @triblondon)
-
Fix #129 w3c/payment-request#153 (13 comments by @adrianba, @adrianhopebailie, @dlongley, @hober, @mattsaxon, @zkoch)
-
Update complete() method to take a string and clarify its purpose w3c/payment-request#161 (12 comments by @adrianba, @adrianhopebailie, @dlongley, @halindrome, @jnormore, @msporny)
-
provide shipping address in PaymentResponse w3c/payment-request#139 (10 comments by @adrianba, @adrianhopebailie, @burdges, @halindrome, @rvm4, @zkoch)
-
fields in abort() Update paymentrequest.html w3c/payment-request#130 (10 comments by @adrianba, @adrianhopebailie, @AxelNennker)
-
grammatical updates to the payment method identifier spec w3c/payment-request#124 (9 comments by @adrianba, @adrianhopebailie, @halindrome, @rvm4, @sideshowbarker)
-
Migrate PaymentRequest text from arch to payment request spec. w3c/payment-request#110 (7 comments by @adrianba, @adrianhopebailie, @ianbjacobs, @msporny, @sideshowbarker)
-
Update security and privacy considerations sections w3c/payment-request#170 (6 comments by @adrianba, @adrianhopebailie, @ianbjacobs)
-
Remove issue #119 note and assert that total should be non-negative w3c/payment-request#168 (5 comments by @adrianba, @adrianhopebailie, @halindrome, @nickjshearer)
-
Specification of required fields w3c/payment-request#114 (4 comments by @adrianhopebailie, @burdges, @mattsaxon)
-
codemod user agent to payment mediator in payment request w3c/payment-request#137 (4 comments by @adrianba, @adrianhopebailie, @ianbjacobs)
-
Add option 1b to payment method identifier spec. w3c/payment-request#108 (3 comments by @adrianba, @ianbjacobs, @kirkalx)
-
Fix old reference to items and use total/displayItems w3c/payment-request#169 (2 comments by @adrianhopebailie)
-
Refactor the supportedMethods and payment specific data w3c/payment-request#162 (2 comments by @adrianba, @msporny)
-
Remove id attribute from PaymentItem w3c/payment-request#160 (2 comments by @adrianhopebailie, @rvm4)
-
provide partial shipping address in PaymentRequest and full shipping … w3c/payment-request#136 (2 comments by @kirkalx, @rvm4)
-
Reference names should have hyphens w3c/payment-request#125 (2 comments by @adrianhopebailie, @zkoch)
-
Proposal to add negative value support w3c/payment-request#120 (2 comments by @adrianba, @adrianhopebailie)
-
Updated to use [SecureContext] extended attribute. w3c/payment-request#172 (1 comment by @adrianhopebailie)
-
Specify shipping address fields based on OASIS xAL. w3c/payment-request#147 (1 comment by @adrianba)
-
Remove issue 55 note and add security considerations section. w3c/payment-request#142 (1 comment by @adrianhopebailie)
-
Removing references to closed issues #47 and #56. w3c/payment-request#144 (1 comment by @adrianhopebailie)
-
provide partial shipping address in PaymentRequest and full shipping … w3c/payment-request#135 (1 comment by @rvm4)
-
Issue marker requesting security considerations section w3c/payment-request#98 (1 comment by @adrianba)
-
w3c/webpayments
-
4 issues opened.
-
How can a Web Based Payment App cancel the payment flow? w3c/webpayments#128, by @tommythorsen.
-
Payment Methods vs Payment Instruments w3c/webpayments#124, by @tommythorsen.
-
Update reference labels to match other docs w3c/webpayments#117, by @adrianhopebailie.
-
Create an FAQ w3c/webpayments#114, by @sideshowbarker.
-
-
13 issues closed.
-
Payment Methods vs Payment Instruments w3c/webpayments#124.
-
Create an FAQ w3c/webpayments#114.
-
Review: UPI - a method and standard that went BETA in India w3c/webpayments#100.
-
ACTION: Refactor flows to use common terminology and entry/exit points w3c/webpayments#49.
-
Confusion over payment flow w3c/webpayments#10.
-
Document relationship diagrams? w3c/webpayments#24.
-
How do we prevent keyboard hooking during payment? w3c/webpayments#90.
-
Should we be publishing a specification for an HTTP API? w3c/webpayments#17.
-
What is the appropriate conversational pattern for the API? w3c/webpayments#55.
-
ACTION: Summarize arguments for/against shipping address capture w3c/webpayments#72.
-
-
1 issue reopened.
-
Synonym Mapping from Web Environment Terminology to ISO 20022 Terminonogy w3c/webpayments#95, by @mattsaxon.
-
-
15 issues received 54 new comments.
-
How can a Web Based Payment App cancel the payment flow? w3c/webpayments#128 (12 comments by @adrianhopebailie, @dlongley, @ianbjacobs, @msporny, @tommythorsen)
-
How do we transition users and merchants from the current system to using the new API and apps? w3c/webpayments#94 (11 comments by @adrianhopebailie, @corwinAmbre, @ianbjacobs, @mattsaxon)
-
Registration: App supports method but user has no instrument for that method w3c/webpayments#110 (11 comments by @adrianhopebailie, @burdges, @corwinAmbre, @dlongley, @halindrome, @ianbjacobs)
-
Payment Methods vs Payment Instruments w3c/webpayments#124 (5 comments by @adrianhopebailie, @ianbjacobs, @tommythorsen)
-
Synonym Mapping from Web Environment Terminology to ISO 20022 Terminonogy w3c/webpayments#95 (2 comments by @adrianhopebailie, @mattsaxon)
-
ACTION: Refactor flows to use common terminology and entry/exit points w3c/webpayments#49 (2 comments by @adrianhopebailie)
-
Review: UPI - a method and standard that went BETA in India w3c/webpayments#100 (1 comment by @adrianhopebailie)
-
Should we be publishing a specification for an HTTP API? w3c/webpayments#17 (1 comment by @adrianhopebailie)
-
PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object w3c/webpayments#77 (1 comment by @adrianhopebailie)
-
Should the Web Payments API cater for the invoicing part of the full web purchase flow ? w3c/webpayments#60 (1 comment by @adrianhopebailie)
-
Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? w3c/webpayments#76 (1 comment by @adrianhopebailie)
-
ACTION: Summarize arguments for/against shipping address capture w3c/webpayments#72 (1 comment by @ianbjacobs)
-
-
11 pull requests opened.
-
Fix section indents on Arch proposal w3c/webpayments#127, by @adrianhopebailie.
-
Minor HTML typo on Arch proposal w3c/webpayments#126, by @adrianhopebailie.
-
New Architecture Proposal w3c/webpayments#125, by @adrianhopebailie.
-
Proposals should be marked as unofficial w3c/webpayments#123, by @marcoscaceres.
-
Proposals should be marked as unofficial w3c/webpayments#122, by @marcoscaceres.
-
Proposals should be marked as unofficial w3c/webpayments#121, by @marcoscaceres.
-
Apply review comments by Ian Jacobs to HTTP API. w3c/webpayments#120, by @msporny.
-
Add Web Payments Core Messages spec to proposals. w3c/webpayments#119, by @msporny.
-
Gh pages w3c/webpayments#118, by @adrianhopebailie.
-
Proposal for a Payment Apps spec w3c/webpayments#116, by @adrianhopebailie.
-
Add Web Payments CG HTTP API specification to list of proposals. w3c/webpayments#115, by @msporny.
-
-
11 pull requests merged.
-
Fix section indents on Arch proposal w3c/webpayments#127.
-
Minor HTML typo on Arch proposal w3c/webpayments#126.
-
Add Web Payments Core Messages spec to proposals. w3c/webpayments#119.
-
Apply review comments by Ian Jacobs to HTTP API. w3c/webpayments#120.
-
New Architecture Proposal w3c/webpayments#125.
-
Proposals should be marked as unofficial w3c/webpayments#122.
-
Proposals should be marked as unofficial w3c/webpayments#123.
-
Proposals should be marked as unofficial w3c/webpayments#121.
-
Gh pages w3c/webpayments#118.
-
Proposal for a Payment Apps spec w3c/webpayments#116.
-
Add Web Payments CG HTTP API specification to list of proposals. w3c/webpayments#115.
-
-
4 pull requests received 11 new comments.
-
New Architecture Proposal w3c/webpayments#125 (7 comments by @adrianhopebailie, @ianbjacobs, @msporny)
-
Add Web Payments Core Messages spec to proposals. w3c/webpayments#119 (2 comments by @adrianhopebailie, @msporny)
-
w3c/webpayments-flows
-
3 pull requests opened.
-
Updated Selection of Payment Instrument to App/Instrument w3c/webpayments-flows#10, by @mattsaxon.
-
Gh pages w3c/webpayments-flows#9, by @mattsaxon.
-
Minor updates for consistency w3c/webpayments-flows#8, by @mattsaxon.
-
-
3 pull requests merged.
-
Updated Selection of Payment Instrument to App/Instrument w3c/webpayments-flows#10.
-
Gh pages w3c/webpayments-flows#9.
-
Minor updates for consistency w3c/webpayments-flows#8.
-
Participants
-
1 participant joined.
-
Michael[tm] Smith (sideshowbarker) (W3C) joined.
-
-
1 participant left.
-
Shawn McCarthy (W3C Invited Experts) left.
-
-
5 organizations joined.
-
Electronics and Telecommunications Research Institute (ETRI) joined.
-
Intel Corporation joined.
-
Meta joined.
-
Shopify joined.
-
Samsung Electronics Co., Ltd. joined.
-
GitHub
w3c/payment-request
-
60 issues opened.
-
Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? w3c/payment-request#109, by @adrianhopebailie.
-
Issue Prioritisation Explainer w3c/payment-request#105, by @mattsaxon.
-
Payment Instrument clarification w3c/payment-request#104, by @mattsaxon.
-
What component does the payment method intersection? w3c/payment-request#103, by @mattsaxon.
-
Basic Card Payment Spec will become a Note not a Rec w3c/payment-request#100, by @ianbjacobs.
-
Specifying Mandatory Data w3c/payment-request#97, by @mattsaxon.
-
[basic] Reference trademarks w3c/payment-request#94, by @halindrome.
-
[api] Section 11 PaymentResponse seems to be missing shippingAddress w3c/payment-request#75, by @halindrome.
-
[api] Change e.g. to e.g., w3c/payment-request#66, by @halindrome.
-
[architecture] Reference names should have hyphens w3c/payment-request#63, by @halindrome.
-
[architecture] Use "user agent", not "browser" w3c/payment-request#59, by @halindrome.
-
[architecture] SotD should indicate it is intended to be a Note w3c/payment-request#58, by @halindrome.
-
Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app? w3c/payment-request#56, by @msporny.
-
Should the messages support field-level encryption? w3c/payment-request#55, by @msporny.
-
Should the payment request support multiple pricing options? w3c/payment-request#54, by @msporny.
-
Add section on internationalization w3c/payment-request#53, by @msporny.
-
How does the API support enrollment (aka subscription, future payment) use cases? w3c/payment-request#52, by @msporny.
-
Should the payment API be more conversational or less conversational? w3c/payment-request#51, by @msporny.
-
How are payment requests and responses passed between the browser and third-party native wallets? w3c/payment-request#50, by @msporny.
-
Should the payment request contain line item details? w3c/payment-request#49, by @msporny.
-
Should list of accepted payment methods be strings or objects? w3c/payment-request#48, by @msporny.
-
Should a payment request be just data, or a programmable object? w3c/payment-request#47, by @msporny.
-
Should a payment method identifier (URL) resolve to a machine readable resource that describes it? w3c/payment-request#46, by @msporny.
-
Should Payment Method Identifiers and Messages be expressed using a Linked Data Vocabulary? w3c/payment-request#45, by @msporny.
-
Add section on Extensibility w3c/payment-request#44, by @msporny.
-
Terminology across all Web Payments documents should be aligned w3c/payment-request#43, by @msporny.
-
Merge Payment Request Architecture with Capabilities Document w3c/payment-request#42, by @msporny.
-
How do organizations layer additional information in the core payment messages? w3c/payment-request#40, by @msporny.
-
How are web-based payment apps supported? w3c/payment-request#39, by @msporny.
-
How are payment apps shared between different browser brands? w3c/payment-request#38, by @msporny.
-
Any plan to allow this API to be called by non-merchants? w3c/payment-request#35, by @dlongley.
-
How will the spec address versioning / feature detection? w3c/payment-request#33, by @ianbjacobs.
-
Specification to include Flow Diagram w3c/payment-request#32, by @mattsaxon.
-
API Data Integrity w3c/payment-request#31, by @mattsaxon.
-
Should we define nesting/grouping semantics for payment method identifier matching? w3c/payment-request#30, by @ianbjacobs.
-
What happens when currency of offer differs from currency of selected payment instrument? w3c/payment-request#29, by @ianbjacobs.
-
Should the payee be able to inspect the status of a payment? w3c/payment-request#28, by @ianbjacobs.
-
Should API support billing address capture (for tax computation)? w3c/payment-request#27, by @ianbjacobs.
-
Can the merchant influence order of presentation of payment apps to the user w3c/payment-request#23, by @adrianba.
-
Spec should use [SecureContext] once that is defined in Web IDL w3c/payment-request#22, by @adrianba.
-
Ensure references are up-to-date w3c/payment-request#20, by @adrianba.
-
Should the API handle pre-auth, recurring payments, and similar scenarios w3c/payment-request#19, by @adrianba.
-
Constructor should not include "total" in list of items w3c/payment-request#18, by @adrianba.
-
complete() should take a string argument not boolean w3c/payment-request#17, by @adrianba.
-
Use navigator.payments singleton, factory method, or PaymentRequest constructor w3c/payment-request#16, by @adrianba.
-
Combine API parameters into a single request object + options w3c/payment-request#15, by @adrianba.
-
Handling non-decimal currencies w3c/payment-request#14, by @adrianba.
-
Write-up initial proposal for payment app registration spec w3c/payment-request#12, by @adrianba.
-
What is the format for payment method identifiers for distributed extensibility w3c/payment-request#11, by @adrianba.
-
Should well-known identifiers be used for ubiquitous payment methods w3c/payment-request#10, by @adrianba.
-
Different card schemes have different mandatory field requirements w3c/payment-request#9, by @adrianba.
-
Should payment app registration be included in the conformance criteria of the browser API spec? w3c/payment-request#8, by @adrianba.
-
Should we support a delegated state for PaymentRequest? w3c/payment-request#7, by @adrianba.
-
Write-up proposal for shipping address fields w3c/payment-request#6, by @adrianba.
-
Should the web page be able to provide status information before calling complete() w3c/payment-request#5, by @adrianba.
-
Should it be possible to vary amounts depending on payment method w3c/payment-request#4, by @adrianba.
-
Should it be possible to provide "total" amounts in more than one currency w3c/payment-request#3, by @adrianba.
-
Should the Payment Request API only be available in a top-level browsing context? w3c/payment-request#2, by @adrianba.
-
Should the merchant be able to request your email and recipient phone number w3c/payment-request#1, by @adrianba.
-
-
4 issues closed.
-
[architecture] Use "user agent", not "browser" w3c/payment-request#59.
-
Should the payment request support multiple pricing options? w3c/payment-request#54.
-
How does the API support enrollment (aka subscription, future payment) use cases? w3c/payment-request#52.
-
-
37 issues received 258 new comments.
-
Write-up proposal for shipping address fields w3c/payment-request#6 (44 comments by @adrianba, @adrianhopebailie, @alexdown, @dlongley, @halindrome, @mountielee, @rsolomakhin)
-
Different card schemes have different mandatory field requirements w3c/payment-request#9 (26 comments by @adrianba, @adrianhopebailie, @dezell, @dlongley, @halindrome, @mattsaxon, @nickjshearer, @rsolomakhin, @zkoch)
-
Should it be possible to vary amounts depending on payment method w3c/payment-request#4 (16 comments by @adrianhopebailie, @burdges, @davidillsley, @dlongley, @halindrome, @mattsaxon, @nickjshearer, @rsolomakhin)
-
Merge Payment Request Architecture with Capabilities Document w3c/payment-request#42 (16 comments by @dlongley, @halindrome, @ianbjacobs, @msporny)
-
complete() should take a string argument not boolean w3c/payment-request#17 (13 comments by @adrianhopebailie, @burdges, @jnormore, @mattsaxon, @zkoch)
-
How do organizations layer additional information in the core payment messages? w3c/payment-request#40 (13 comments by @adrianba, @adrianhopebailie, @dlongley, @halindrome, @ianbjacobs, @msporny)
-
How are payment requests and responses passed between the browser and third-party native wallets? w3c/payment-request#50 (11 comments by @adrianba, @burdges, @cyberphone, @msporny, @rsolomakhin)
-
Should it be possible to provide "total" amounts in more than one currency w3c/payment-request#3 (11 comments by @adrianhopebailie, @davidillsley, @mattsaxon, @mattsaxonwp, @mountainhippo, @mountielee, @msporny, @rsolomakhin)
-
Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app? w3c/payment-request#56 (10 comments by @adrianhopebailie, @davidillsley, @halindrome, @ianbjacobs, @mattsaxonwp, @mountainhippo, @rsolomakhin)
-
Should we define nesting/grouping semantics for payment method identifier matching? w3c/payment-request#30 (8 comments by @ianbjacobs, @mattsaxon, @webpayments-specs, @zkoch)
-
Specifying Mandatory Data w3c/payment-request#97 (7 comments by @adrianhopebailie, @dlongley, @mattsaxon, @rsolomakhin, @webpayments-specs, @zkoch)
-
Spec should use [SecureContext] once that is defined in Web IDL w3c/payment-request#22 (7 comments by @adrianba, @haavardmolland, @halindrome, @msporny, @wseltzer)
-
[api] Section 11 PaymentResponse seems to be missing shippingAddress w3c/payment-request#75 (7 comments by @dlongley, @halindrome, @rsolomakhin, @zkoch)
-
Should the payment request contain line item details? w3c/payment-request#49 (6 comments by @adrianba, @adrianhopebailie, @halindrome, @msporny)
-
How are payment apps shared between different browser brands? w3c/payment-request#38 (6 comments by @adrianhopebailie, @ianbjacobs, @mattsaxon)
-
Should the API handle pre-auth, recurring payments, and similar scenarios w3c/payment-request#19 (6 comments by @burdges, @ianbjacobs, @mattsaxon, @msporny, @mwatson2)
-
Should the messages support field-level encryption? w3c/payment-request#55 (4 comments by @adrianhopebailie, @burdges, @ianbjacobs, @mattsaxon)
-
Terminology across all Web Payments documents should be aligned w3c/payment-request#43 (4 comments by @adrianhopebailie, @ianbjacobs, @msporny)
-
Should Payment Method Identifiers and Messages be expressed using a Linked Data Vocabulary? w3c/payment-request#45 (4 comments by @adrianba, @ianbjacobs, @msporny)
-
API Data Integrity w3c/payment-request#31 (4 comments by @burdges, @cyberphone, @mattsaxon, @webpayments-specs)
-
Should a payment method identifier (URL) resolve to a machine readable resource that describes it? w3c/payment-request#46 (3 comments by @adrianhopebailie, @kirkalx)
-
Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? w3c/payment-request#109 (3 comments by @adrianhopebailie, @burdges)
-
How are web-based payment apps supported? w3c/payment-request#39 (3 comments by @adrianhopebailie, @burdges)
-
Add section on Extensibility w3c/payment-request#44 (3 comments by @adrianba, @halindrome, @msporny)
-
[architecture] Use "user agent", not "browser" w3c/payment-request#59 (3 comments by @halindrome, @msporny)
-
Should the payment request support multiple pricing options? w3c/payment-request#54 (3 comments by @adrianhopebailie, @ianbjacobs, @msporny)
-
Write-up initial proposal for payment app registration spec w3c/payment-request#12 (3 comments by @ianbjacobs, @msporny)
-
Any plan to allow this API to be called by non-merchants? w3c/payment-request#35 (2 comments by @dlongley, @webpayments-specs)
-
Should the merchant be able to request your email and recipient phone number w3c/payment-request#1 (2 comments by @adrianba, @mattsaxon)
-
What happens when currency of offer differs from currency of selected payment instrument? w3c/payment-request#29 (1 comment by @adrianhopebailie)
-
What component does the payment method intersection? w3c/payment-request#103 (1 comment by @ianbjacobs)
-
How does the API support enrollment (aka subscription, future payment) use cases? w3c/payment-request#52 (1 comment by @ianbjacobs)
-
What is the format for payment method identifiers for distributed extensibility w3c/payment-request#11 (1 comment by @msporny)
-
How do we ensure that the payment request from the merchant is not tampered with before it gets to the payment app? w3c/payment-request#41 (1 comment by @msporny)
-
Should the Payment Request API only be available in a top-level browsing context? w3c/payment-request#2 (1 comment by @mattsaxon)
-
-
51 pull requests opened.
-
Add PaymentItem type to deal with transaction types w3c/payment-request#111, by @adrianhopebailie.
-
Migrate PaymentRequest text from arch to payment request spec. w3c/payment-request#110, by @msporny.
-
Add option 1b to payment method identifier spec. w3c/payment-request#108, by @msporny.
-
add rvm4 as editor on the other 3 specs w3c/payment-request#107, by @rvm4.
-
Resubmitting because the document moved w3c/payment-request#106, by @halindrome.
-
mark rvm4 as a new editor of the spec w3c/payment-request#102, by @rvm4.
-
Currency amount w3c/payment-request#101, by @adrianhopebailie.
-
Rvm4 editor w3c/payment-request#99, by @rvm4.
-
Issue marker requesting security considerations section w3c/payment-request#98, by @adrianhopebailie.
-
Alternative issue marker for issue#38 w3c/payment-request#96, by @mountainhippo.
-
Card Sub-Brands w3c/payment-request#95, by @mattsaxon.
-
Wrong document names and British English w3c/payment-request#93, by @halindrome.
-
Removed references to "browser" w3c/payment-request#92, by @adrianba.
-
Add UnionPay, Correct typo on Diners w3c/payment-request#91, by @mattsaxon.
-
Gh pages w3c/payment-request#90, by @mattsaxon.
-
Add reference to issue #56. w3c/payment-request#89, by @msporny.
-
Add a reference to issue #56. w3c/payment-request#88, by @msporny.
-
Add a reference to issue #55. w3c/payment-request#87, by @msporny.
-
Add a reference to issue #53. w3c/payment-request#86, by @msporny.
-
Add a reference to issue #51. w3c/payment-request#85, by @msporny.
-
Add a reference to issue #50. w3c/payment-request#84, by @msporny.
-
Add reference to issue #49. w3c/payment-request#83, by @msporny.
-
Add reference to issue #48. w3c/payment-request#82, by @msporny.
-
Add reference to issue #47. w3c/payment-request#81, by @msporny.
-
Add reference to issue #46. w3c/payment-request#80, by @msporny.
-
Add reference to issue #45. w3c/payment-request#79, by @msporny.
-
Add reference to issue #44. w3c/payment-request#78, by @msporny.
-
Add a reference to issue #39 w3c/payment-request#77, by @msporny.
-
Fix typo w3c/payment-request#76, by @halindrome.
-
Remove note and add description for diagram w3c/payment-request#74, by @halindrome.
-
Add a reference to issue #38 w3c/payment-request#73, by @msporny.
-
Add a reference to issue #40. w3c/payment-request#72, by @msporny.
-
"Shown" is not inclusive enough w3c/payment-request#71, by @halindrome.
-
Make activation language more permissive w3c/payment-request#70, by @halindrome.
-
Document titles were wrong w3c/payment-request#69, by @halindrome.
-
User Agent should not be hyphenated w3c/payment-request#68, by @halindrome.
-
Remove duplicate conformance language w3c/payment-request#67, by @halindrome.
-
Change the way we request user data w3c/payment-request#65, by @zkoch.
-
Some friendly editorial changes w3c/payment-request#64, by @halindrome.
-
Minor mod to paymentrequest.html w3c/payment-request#62, by @mountainhippo.
-
Add issue #43 to payment request spec. w3c/payment-request#61, by @msporny.
-
Remove trailing whitespace. w3c/payment-request#60, by @msporny.
-
Added respec defines to improve github links w3c/payment-request#57, by @halindrome.
-
Editorial and some clarifications w3c/payment-request#37, by @adrianhopebailie.
-
Gh pages w3c/payment-request#36, by @ianbjacobs.
-
Suggest two alternative payment method identifier proposals w3c/payment-request#34, by @adrianba.
-
Fix link to issues list for the method identifier spec w3c/payment-request#26, by @adrianba.
-
Redefinition of BasicCardResponse to address Issue 9 w3c/payment-request#25, by @mattsaxon.
-
Added more inline issue links w3c/payment-request#24, by @adrianba.
-
Added new issue markers to the specs w3c/payment-request#21, by @adrianba.
-
Importing PaymentRequest specifications from the WICG w3c/payment-request#13, by @adrianba.
-
-
12 pull requests merged.
-
add rvm4 as editor on the other 3 specs w3c/payment-request#107.
-
mark rvm4 as a new editor of the spec w3c/payment-request#102.
-
Add reference to issue #56. w3c/payment-request#89.
-
"Shown" is not inclusive enough w3c/payment-request#71.
-
Removed references to "browser" w3c/payment-request#92.
-
Add UnionPay, Correct typo on Diners w3c/payment-request#91.
-
Remove trailing whitespace. w3c/payment-request#60.
-
Fix typo w3c/payment-request#76.
-
Suggest two alternative payment method identifier proposals w3c/payment-request#34.
-
Minor mod to paymentrequest.html w3c/payment-request#62.
-
Fix link to issues list for the method identifier spec w3c/payment-request#26.
-
Added new issue markers to the specs w3c/payment-request#21.
-
-
22 pull requests closed.
-
Add a reference to issue #38 w3c/payment-request#73.
-
Rvm4 editor w3c/payment-request#99.
-
Add issue #43 to payment request spec. w3c/payment-request#61.
-
Add reference to issue #44. w3c/payment-request#78.
-
Add a reference to issue #40. w3c/payment-request#72.
-
Card Sub-Brands w3c/payment-request#95.
-
Add a reference to issue #53. w3c/payment-request#86.
-
Remove note and add description for diagram w3c/payment-request#74.
-
Make activation language more permissive w3c/payment-request#70.
-
Document titles were wrong w3c/payment-request#69.
-
Wrong document names and British English w3c/payment-request#93.
-
User Agent should not be hyphenated w3c/payment-request#68.
-
Remove duplicate conformance language w3c/payment-request#67.
-
Added respec defines to improve github links w3c/payment-request#57.
-
Add reference to issue #46. w3c/payment-request#80.
-
Gh pages w3c/payment-request#90.
-
Add a reference to issue #56. w3c/payment-request#88.
-
Redefinition of BasicCardResponse to address Issue 9 w3c/payment-request#25.
-
Editorial and some clarifications w3c/payment-request#37.
-
Gh pages w3c/payment-request#36.
-
Added more inline issue links w3c/payment-request#24.
-
Importing PaymentRequest specifications from the WICG w3c/payment-request#13.
-
-
3 pull requests reopened.
-
Redefinition of BasicCardResponse to address Issue 9 w3c/payment-request#25, by @mattsaxon.
-
Redefinition of BasicCardResponse to address Issue 9 w3c/payment-request#25, by @mattsaxon.
-
Redefinition of BasicCardResponse to address Issue 9 w3c/payment-request#25, by @mattsaxon.
-
-
38 pull requests received 140 new comments.
-
Suggest two alternative payment method identifier proposals w3c/payment-request#34 (22 comments by @adrianba, @dlongley, @ianbjacobs, @mattsaxon, @zkoch)
-
Redefinition of BasicCardResponse to address Issue 9 w3c/payment-request#25 (14 comments by @adrianba, @adrianhopebailie, @burdges, @mattsaxon, @zkoch)
-
Change the way we request user data w3c/payment-request#65 (11 comments by @adrianhopebailie, @burdges, @ianbjacobs, @mattsaxon, @msporny, @webpayments-specs, @zkoch)
-
Currency amount w3c/payment-request#101 (10 comments by @adrianhopebailie, @halindrome, @kirkalx, @mattsaxon, @zkoch)
-
Some friendly editorial changes w3c/payment-request#64 (9 comments by @adrianhopebailie, @halindrome, @msporny, @zkoch)
-
Add a reference to issue #38 w3c/payment-request#73 (7 comments by @adrianhopebailie, @mattsaxon, @mountainhippo, @msporny, @zkoch)
-
Add PaymentItem type to deal with transaction types w3c/payment-request#111 (6 comments by @halindrome, @mattsaxon, @zkoch)
-
Card Sub-Brands w3c/payment-request#95 (6 comments by @adrianba, @ianbjacobs, @mattsaxon, @mattsaxonwp, @rsolomakhin)
-
Add a reference to issue #40. w3c/payment-request#72 (5 comments by @adrianba, @adrianhopebailie, @mountainhippo, @msporny)
-
Migrate PaymentRequest text from arch to payment request spec. w3c/payment-request#110 (4 comments by @ianbjacobs, @mattsaxon, @msporny)
-
Added respec defines to improve github links w3c/payment-request#57 (4 comments by @adrianba, @adrianhopebailie, @halindrome, @zkoch)
-
Add a reference to issue #39 w3c/payment-request#77 (3 comments by @adrianhopebailie, @msporny, @zkoch)
-
Add issue #43 to payment request spec. w3c/payment-request#61 (2 comments by @adrianba, @adrianhopebailie)
-
Make activation language more permissive w3c/payment-request#70 (2 comments by @adrianba, @adrianhopebailie)
-
User Agent should not be hyphenated w3c/payment-request#68 (2 comments by @adrianba, @adrianhopebailie)
-
Add option 1b to payment method identifier spec. w3c/payment-request#108 (1 comment by @adrianhopebailie)
-
Importing PaymentRequest specifications from the WICG w3c/payment-request#13 (1 comment by @adrianba)
-
w3c/webpayments
-
3 issues opened.
-
Registration: Should we support payee knowing user has payee-controlled payment app? w3c/webpayments#112, by @ianbjacobs.
-
Registration: How is registration information updated? w3c/webpayments#111, by @ianbjacobs.
-
Registration: App supports method but user has no instrument for that method w3c/webpayments#110, by @ianbjacobs.
-
-
25 issues closed.
-
Should the payment request support multiple pricing options? w3c/webpayments#79.
-
Multilingual Support for human-readable labels w3c/webpayments#84.
-
What are the WPWG February 2016 face-to-face prioritized issues w3c/webpayments#89.
-
How can the API support enrollment (future payment) use cases? w3c/webpayments#65.
-
How are third-party native wallets integrated? w3c/webpayments#42.
-
Should the payment request contain line item details? w3c/webpayments#38.
-
Should list of accepted payment methods be strings or objects? w3c/webpayments#37.
-
Should a payment request be just data, or a programmable object? w3c/webpayments#36.
-
Is tracking payment request state necessary? w3c/webpayments#35.
-
Should we expose status change events in the browser API? w3c/webpayments#41.
-
Should a Payment Request API have shipping address APIs? w3c/webpayments#39.
-
Payment Method Identifier Registry should have oversight / formal structure w3c/webpayments#25.
-
Payment Request Architecture glossary should include IG glossary w3c/webpayments#23.
-
Merge Payment Request Architecture with Capabilities Document w3c/webpayments#22.
-
How do organizations layer additional information in the core messages? w3c/webpayments#18.
-
How are cloud-based payment apps supported? w3c/webpayments#16.
-
How are payment apps shared between different browser brands? w3c/webpayments#15.
-
How are payment apps registered? w3c/webpayments#14.
-
-
33 issues received 61 new comments.
-
Registration: Should we support payee knowing user has payee-controlled payment app? w3c/webpayments#112 (13 comments by @adrianhopebailie, @burdges, @halindrome, @ianbjacobs, @mattsaxon)
-
How are third-party native wallets integrated? w3c/webpayments#42 (10 comments by @adrianba, @cyberphone, @mattsaxon, @msporny, @webpayments)
-
Registration: How is registration information updated? w3c/webpayments#111 (3 comments by @adrianhopebailie, @webpayments)
-
Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? w3c/webpayments#76 (2 comments by @mattsaxon, @webpayments)
-
Should the payment request support multiple pricing options? w3c/webpayments#79 (2 comments by @adrianhopebailie, @msporny)
-
Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app? w3c/webpayments#66 (2 comments by @adrianhopebailie, @msporny)
-
Registration: App supports method but user has no instrument for that method w3c/webpayments#110 (2 comments by @adrianhopebailie, @mattsaxon)
-
Synonym Mapping from Web Environment Terminology to ISO 20022 Terminonogy w3c/webpayments#95 (2 comments by @dprophet, @mattsaxon)
-
ACTION: Summarize arguments for/against shipping address capture w3c/webpayments#72 (1 comment by @ianbjacobs)
-
How do we protect certain data in the messages from certain parties in the flow as the use case requires? w3c/webpayments#78 (1 comment by @msporny)
-
How can the API support enrollment (future payment) use cases? w3c/webpayments#65 (1 comment by @msporny)
-
What is the appropriate conversational pattern for the API? w3c/webpayments#55 (1 comment by @msporny)
-
Should list of accepted payment methods be strings or objects? w3c/webpayments#37 (1 comment by @msporny)
-
Should a payment request be just data, or a programmable object? w3c/webpayments#36 (1 comment by @msporny)
-
What are the WPWG February 2016 face-to-face prioritized issues w3c/webpayments#89 (1 comment by @msporny)
-
Should a payment method identifier (URL) resolve to a machine readable resource that describes the payment method? w3c/webpayments#30 (1 comment by @msporny)
-
Should Payment Method Identifiers and Messages be expressed using a Linked Data Vocabulary? w3c/webpayments#29 (1 comment by @msporny)
-
Should we expose status change events in the browser API? w3c/webpayments#41 (1 comment by @msporny)
-
How should the message schemas for the payment request and response be defined? What is the extensibility story for the messages? w3c/webpayments#27 (1 comment by @msporny)
-
Should we have separate specifications for payment and registration of payment apps? w3c/webpayments#26 (1 comment by @msporny)
-
Payment Method Identifier Registry should have oversight / formal structure w3c/webpayments#25 (1 comment by @msporny)
-
Payment Request Architecture glossary should include IG glossary w3c/webpayments#23 (1 comment by @msporny)
-
Merge Payment Request Architecture with Capabilities Document w3c/webpayments#22 (1 comment by @msporny)
-
Should we be concerned about the use of the Browser API in a non-HTTPS environment? w3c/webpayments#20 (1 comment by @msporny)
-
How do we ensure that the payment request from the merchant is not tampered with before it gets to the payment app? w3c/webpayments#19 (1 comment by @msporny)
-
How do organizations layer additional information in the core messages? w3c/webpayments#18 (1 comment by @msporny)
-
How are payment apps shared between different browser brands? w3c/webpayments#15 (1 comment by @msporny)
-
-
2 pull requests opened.
-
Adding registration proposal w3c/webpayments#113, by @zkoch.
-
Gh pages w3c/webpayments#109, by @mattsaxon.
-
-
3 pull requests merged.
-
Adding registration proposal w3c/webpayments#113.
-
Gh pages w3c/webpayments#109.
-
Taler flows w3c/webpayments#106.
-
-
1 pull request received 1 new comment.
w3c/webpayments-flows
-
5 pull requests opened.
-
Gh pages w3c/webpayments-flows#7, by @mattsaxon.
-
Added Target Flow for SEPA Credit Transfer w3c/webpayments-flows#6, by @mattsaxon.
-
Minor Revisions w3c/webpayments-flows#5, by @mattsaxon.
-
Added Elipsis w3c/webpayments-flows#4, by @mattsaxon.
-
Amended include location for new repo w3c/webpayments-flows#3, by @mattsaxon.
-
-
5 pull requests merged.
-
Gh pages w3c/webpayments-flows#7.
-
Added Target Flow for SEPA Credit Transfer w3c/webpayments-flows#6.
-
Minor Revisions w3c/webpayments-flows#5.
-
Added Elipsis w3c/webpayments-flows#4.
-
Amended include location for new repo w3c/webpayments-flows#3.
-
Participants
-
5 organizations joined.
-
Deutsche Telekom AG joined.
-
Lyra Network joined.
-
Oracle Corporation joined.
-
Yandex joined.
-
Camara Interbancaria de Pagamentos (CIP) joined.
-
GitHub
w3c/webpayments-flows
-
2 issues opened.
-
Test issue notification 2 w3c/webpayments-flows#2, by @webpayments-flows.
-
Test issue notification w3c/webpayments-flows#1, by @webpayments-flows.
-
-
2 issues closed.
-
Test issue notification 2 w3c/webpayments-flows#2.
-
Test issue notification w3c/webpayments-flows#1.
-
-
1 issue received 2 new comments.
w3c/webpayments
-
12 issues opened.
-
Review: UPI - a method and standard that went BETA in India w3c/webpayments#100, by @madhushekar23.
-
Synonym Mapping from Web Environment Terminology to ISO 20022 Terminonogy w3c/webpayments#95, by @dprophet.
-
ISO20022 terminology adoption w3c/webpayments#93, by @mattsaxon.
-
Flow terminology w3c/webpayments#92, by @mattsaxon.
-
How do we prevent keyboard hooking during payment? w3c/webpayments#90, by @oldoldb.
-
What are the WPWG February 2016 face-to-face prioritized issues w3c/webpayments#89, by @msporny.
-
Multilingual Support for human-readable labels w3c/webpayments#84, by @ianbjacobs.
-
Should the payment request support multiple pricing options? w3c/webpayments#79, by @adrianhopebailie.
-
-
7 issues closed.
-
Flow terminology w3c/webpayments#92.
-
What gets registered - apps, wallets, or payment instruments? w3c/webpayments#28.
-
Terminology for payer/payee, user/merchant, debtor/creditor w3c/webpayments#59.
-
Expression of monetary amounts w3c/webpayments#40.
-
PROPOSAL: Use strings to represent currency and amount per ISO20022 w3c/webpayments#57.
-
-
2 issues reopened.
-
ISO20022 terminology adoption w3c/webpayments#93, by @mattsaxon.
-
PROPOSAL: Use strings to represent currency and amount per ISO20022 w3c/webpayments#57, by @vkuntz.
-
-
34 issues received 249 new comments.
-
What are the WPWG February 2016 face-to-face prioritized issues w3c/webpayments#89 (25 comments by @adrianhopebailie, @dlongley, @ianbjacobs, @mattsaxon, @mountainhippo, @msporny, @nickjshearer, @rsolomakhin, @zkoch)
-
What is the appropriate conversational pattern for the API? w3c/webpayments#55 (25 comments by @adrianba, @adrianhopebailie, @dlongley, @jakearchibald, @msporny, @rsolomakhin, @zkoch)
-
ACTION: Summarize arguments for/against shipping address capture w3c/webpayments#72 (17 comments by @adrianba, @adrianhopebailie, @dlongley, @fredMeignien, @ianbjacobs, @nickjshearer, @rsolomakhin, @vkuntz, @zkoch)
-
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. w3c/webpayments#64 (14 comments by @adrianba, @adrianhopebailie, @msporny, @rsolomakhin, @zkoch)
-
PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object w3c/webpayments#77 (14 comments by @adrianba, @adrianhopebailie, @alexdown, @dlongley, @mattsaxon, @msporny, @rsolomakhin, @webpayments)
-
How are third-party native wallets integrated? w3c/webpayments#42 (12 comments by @adrianba, @adrianhopebailie, @haavardmolland, @mattsaxon, @rsolomakhin, @webpayments)
-
Should the payment request support multiple pricing options? w3c/webpayments#79 (11 comments by @adrianba, @adrianhopebailie, @alexdown, @dlongley, @halindrome, @msporny, @rsolomakhin, @webpayments)
-
How can the API support enrollment (future payment) use cases? w3c/webpayments#65 (10 comments by @adrianhopebailie, @dezell, @dlongley, @fredMeignien, @mattsaxon, @rsolomakhin, @webpayments, @zkoch)
-
Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? w3c/webpayments#76 (9 comments by @adrianba, @adrianhopebailie, @dprophet, @halindrome, @msporny, @rsolomakhin, @webpayments, @zkoch)
-
Should the Web Payments API cater for the invoicing part of the full web purchase flow ? w3c/webpayments#60 (7 comments by @adrianhopebailie, @ianbjacobs, @mattsaxon, @msporny, @rsolomakhin, @vkuntz)
-
How do we prevent keyboard hooking during payment? w3c/webpayments#90 (7 comments by @adrianhopebailie, @ianbjacobs, @oldoldb, @rsolomakhin)
-
How do we protect certain data in the messages from certain parties in the flow as the use case requires? w3c/webpayments#78 (6 comments by @adrianba, @adrianhopebailie, @haavardmolland, @halindrome, @ianbjacobs, @rsolomakhin)
-
Synonym Mapping from Web Environment Terminology to ISO 20022 Terminonogy w3c/webpayments#95 (5 comments by @dprophet, @fredMeignien, @mattsaxon)
-
ISO20022 terminology adoption w3c/webpayments#93 (5 comments by @dprophet, @fredMeignien, @mattsaxon)
-
How are cloud-based payment apps supported? w3c/webpayments#16 (5 comments by @adrianhopebailie, @dlongley, @ianbjacobs)
-
Should we expose status change events in the browser API? w3c/webpayments#41 (4 comments by @adrianhopebailie, @dlongley, @jakearchibald, @zkoch)
-
PROPOSAL: Include an extensibility section in the browser API spec with an ISSUE marker indicating WIP. w3c/webpayments#83 (4 comments by @adrianhopebailie, @ianbjacobs, @msporny)
-
Multilingual Support for human-readable labels w3c/webpayments#84 (3 comments by @ianbjacobs, @nickjshearer, @rsolomakhin)
-
How do we transition users and merchants from the current system to using the new API and apps? w3c/webpayments#94 (3 comments by @dlongley, @rsolomakhin)
-
How are payment apps shared between different browser brands? w3c/webpayments#15 (3 comments by @adrianhopebailie, @dlongley)
-
Review: UPI - a method and standard that went BETA in India w3c/webpayments#100 (2 comments by @ianbjacobs, @madhushekar23)
-
Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app? w3c/webpayments#66 (2 comments by @rsolomakhin, @webpayments)
-
PROPOSAL: Use strings to represent currency and amount per ISO20022 w3c/webpayments#57 (2 comments by @adrianhopebailie, @vkuntz)
-
Should a Payment Request API have shipping address APIs? w3c/webpayments#39 (1 comment by @dlongley)
-
Should a payment method identifier (URL) resolve to a machine readable resource that describes the payment method? w3c/webpayments#30 (1 comment by @adrianhopebailie)
-
Should we have separate specifications for payment and registration of payment apps? w3c/webpayments#26 (1 comment by @adrianhopebailie)
-
What gets registered - apps, wallets, or payment instruments? w3c/webpayments#28 (1 comment by @adrianhopebailie)
-
Terminology for payer/payee, user/merchant, debtor/creditor w3c/webpayments#59 (1 comment by @adrianhopebailie)
-
19 pull requests opened.
-
Gh pages w3c/webpayments#108, by @mattsaxon.
-
Gh pages w3c/webpayments#107, by @mattsaxon.
-
Taler flows w3c/webpayments#106, by @burdges.
-
Gh pages w3c/webpayments#105, by @mattsaxon.
-
Minor Changes w3c/webpayments#104, by @mattsaxon.
-
Removed Spaces From File Name w3c/webpayments#102, by @mattsaxon.
-
Gh pages w3c/webpayments#101, by @mattsaxon.
-
PISP under PSD2_SCT flows_Shopper PISP w3c/webpayments#99, by @fredMeignien.
-
Added Credit Transfer clarifications w3c/webpayments#98, by @mattsaxon.
-
PISP under PSD2_SCT flows_Merchant PISP.pml w3c/webpayments#97, by @fredMeignien.
-
Minor fixes/annoatations w3c/webpayments#96, by @mattsaxon.
-
Fix typos w3c/webpayments#91, by @prayagverma.
-
Consolidate updated from Freed into single file w3c/webpayments#88, by @mattsaxon.
-
Consolidate updated from Freed into single file w3c/webpayments#87, by @mattsaxon.
-
Consolidate updated from Freed into single file w3c/webpayments#86, by @mattsaxon.
-
Changes based on discussion with Ian Jacobs w3c/webpayments#85, by @mattsaxon.
-
PSD2 about Payment Initiation 4 Feb 2016 w3c/webpayments#82, by @fredMeignien.
-
Updated card participants for ISO20022 w3c/webpayments#81, by @mattsaxon.
-
-
19 pull requests merged.
-
Gh pages w3c/webpayments#108.
-
Gh pages w3c/webpayments#107.
-
Gh pages w3c/webpayments#105.
-
Minor Changes w3c/webpayments#104.
-
Removed Spaces From File Name w3c/webpayments#102.
-
Gh pages w3c/webpayments#101.
-
PISP under PSD2_SCT flows_Shopper PISP w3c/webpayments#99.
-
Added Credit Transfer clarifications w3c/webpayments#98.
-
PISP under PSD2_SCT flows_Merchant PISP.pml w3c/webpayments#97.
-
Minor fixes/annoatations w3c/webpayments#96.
-
Fix typos w3c/webpayments#91.
-
Consolidate updated from Freed into single file w3c/webpayments#88.
-
Consolidate updated from Freed into single file w3c/webpayments#87.
-
Consolidate updated from Freed into single file w3c/webpayments#86.
-
Changes based on discussion with Ian Jacobs w3c/webpayments#85.
-
PSD2 about Payment Initiation 4 Feb 2016 w3c/webpayments#82.
-
Updated card participants for ISO20022 w3c/webpayments#81.
-
Some amendmends w3c/webpayments#75.
-
-
3 pull requests received 6 new comments.
-
Returned Skin to default, moved target flows out of directory structure, removed partial flows for SEPA Credit Transfer w3c/webpayments#80 (2 comments by @halindrome, @mattsaxon)
Participants
-
2 participants joined.
-
Paddy Ramanathan (W3C Invited Experts) joined.
-
Shawn McCarthy (W3C Invited Experts) joined.
-
-
5 organizations joined.
-
GS1 joined.
-
Federal Reserve Bank of Minneapolis joined.
-
Apple Inc. joined.
-
Visa joined.
-
NIC.br - Brazilian Network Information Center joined.
-
GitHub
w3c/webpayments
-
17 issues opened.
-
ACTION: Summarize arguments for/against shipping address capture w3c/webpayments#72, by @adrianhopebailie.
-
How can the API support enrollment (future payment) use cases? w3c/webpayments#65, by @adrianhopebailie.
-
Security and Privacy Self-Review w3c/webpayments#61, by @ianbjacobs.
-
Should the Web Payments API cater for the invoicing part of the full web purchase flow ? w3c/webpayments#60, by @vkuntz.
-
Terminology for payer/payee, user/merchant, debtor/creditor w3c/webpayments#59, by @adrianhopebailie.
-
PROPOSAL: Hold WG meetings every week until further notice. w3c/webpayments#58, by @adrianhopebailie.
-
PROPOSAL: Use strings to represent currency and amount per ISO20022 w3c/webpayments#57, by @adrianhopebailie.
-
What is the appropriate conversational pattern for the API? w3c/webpayments#55, by @adrianhopebailie.
-
Capture proposed work changes in wiki w3c/webpayments#50, by @adrianhopebailie.
-
ACTION: Refactor flows to use common terminology and entry/exit points w3c/webpayments#49, by @adrianhopebailie.
-
6 issues closed.
-
PROPOSAL: Hold WG meetings every week until further notice. w3c/webpayments#58.
-
Capture proposed work changes in wiki w3c/webpayments#50.
-
17 issues received 99 new comments.
-
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. w3c/webpayments#64 (17 comments by @adrianhopebailie, @bifurcation, @dlongley, @msporny, @zkoch)
-
PROPOSAL: The Web Payments browser API should not support the collection of shipping information through API calls w3c/webpayments#63 (16 comments by @adrianhopebailie, @bifurcation, @dlongley, @ianbjacobs, @mikewest, @msporny, @nickjshearer, @webpayments, @zkoch)
-
PROPOSAL: Adopt ISO20022 terminology for payer and payee and use synonyms as appropriate w3c/webpayments#62 (11 comments by @adrianhopebailie, @fredMeignien, @ianbjacobs, @kketels, @mattsaxon, @msporny)
-
Terminology for payer/payee, user/merchant, debtor/creditor w3c/webpayments#59 (11 comments by @adrianhopebailie, @bifurcation, @dlongley, @ianbjacobs, @LaurentCastillo, @mattsaxon, @mountainhippo, @msporny, @vkuntz, @webpayments)
-
PROPOSAL: Postpone release of an HTTP API FPWD until the messaging schemas have stabilized. w3c/webpayments#73 (9 comments by @adrianhopebailie, @dlongley, @ianbjacobs, @msporny)
-
Should a Payment Request API have shipping address APIs? w3c/webpayments#39 (8 comments by @adrianhopebailie, @ianbjacobs, @msporny)
-
PROPOSAL: Use strings to represent currency and amount per ISO20022 w3c/webpayments#57 (4 comments by @adrianhopebailie, @bifurcation)
-
Should the Web Payments API cater for the invoicing part of the full web purchase flow ? w3c/webpayments#60 (4 comments by @adrianhopebailie, @ianbjacobs, @msporny)
-
Should we be publishing a specification for an HTTP API? w3c/webpayments#17 (3 comments by @adrianhopebailie, @bifurcation, @ianbjacobs)
-
Should a payment request be just data, or a programmable object? w3c/webpayments#36 (3 comments by @adrianhopebailie, @msporny)
-
Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app? w3c/webpayments#66 (2 comments by @adrianhopebailie, @webpayments)
-
PROPOSAL: Hold WG meetings every week until further notice. w3c/webpayments#58 (2 comments by @adrianhopebailie, @msporny)
-
ACTION: Summarize arguments for/against shipping address capture w3c/webpayments#72 (1 comment by @webpayments)
-
Should the payment request contain line item details? w3c/webpayments#38 (1 comment by @adrianhopebailie)
-
Should list of accepted payment methods be strings or objects? w3c/webpayments#37 (1 comment by @kevingordonwp)
-
-
15 pull requests opened.
-
Some amendmends w3c/webpayments#75, by @alexdown.
-
SEPA SDD one-off e-mandate Version 01 28 2016 w3c/webpayments#74, by @fredMeignien.
-
Updated skins for taskforce reviewed flows w3c/webpayments#71, by @mattsaxon.
-
Moved skin from realtime payments into include file w3c/webpayments#70, by @mattsaxon.
-
Added Skin file, participant name changes to ISO20022 w3c/webpayments#69, by @mattsaxon.
-
Updated 3DS flow with extra detail w3c/webpayments#68, by @mattsaxon.
-
Adding ISO 20022 definitions highlights for W3C Web Payments WG w3c/webpayments#56, by @LaurentCastillo.
-
Patch 1 w3c/webpayments#54, by @mountielee.
-
Separated PayPal flow into standard and PSP intermediated following discussions with Dave w3c/webpayments#53, by @mattsaxon.
-
Updated PayPal with annotation based on Dave's feedback w3c/webpayments#52, by @mattsaxon.
-
Updated Authentication to read Authorisation w3c/webpayments#51, by @mattsaxon.
-
Updated PayPal to correct redirect and add notifications w3c/webpayments#48, by @mattsaxon.
-
Added Cross Border, minor revisions to RealTime payment w3c/webpayments#47, by @mattsaxon.
-
Gh pages w3c/webpayments#46, by @mattsaxon.
-
Update Apple Pay flow and add Bank Mobile Wallet w3c/webpayments#45, by @LaurentCastillo.
-
-
14 pull requests merged.
-
SEPA SDD one-off e-mandate Version 01 28 2016 w3c/webpayments#74.
-
Updated skins for taskforce reviewed flows w3c/webpayments#71.
-
Moved skin from realtime payments into include file w3c/webpayments#70.
-
Added Skin file, participant name changes to ISO20022 w3c/webpayments#69.
-
Updated 3DS flow with extra detail w3c/webpayments#68.
-
Adding ISO 20022 definitions highlights for W3C Web Payments WG w3c/webpayments#56.
-
Patch 1 w3c/webpayments#54.
-
Updated PayPal with annotation based on Dave's feedback w3c/webpayments#52.
-
Updated Authentication to read Authorisation w3c/webpayments#51.
-
Update Apple Pay flow and add Bank Mobile Wallet w3c/webpayments#45.
-
Updated PayPal to correct redirect and add notifications w3c/webpayments#48.
-
Added Cross Border, minor revisions to RealTime payment w3c/webpayments#47.
-
Gh pages w3c/webpayments#46.
-
-
1 pull request reopened.
-
SEPA SDD one-off e-mandate Version 01 28 2016 w3c/webpayments#74, by @fredMeignien.
-
-
3 pull requests received 7 new comments.
-
Moved skin from realtime payments into include file w3c/webpayments#70 (2 comments by @mattsaxon, @webpayments)