Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Ambiguous conformance requirement in constructor #354

Closed
marcoscaceres opened this issue Nov 30, 2016 · 0 comments · Fixed by #382
Closed

Ambiguous conformance requirement in constructor #354

marcoscaceres opened this issue Nov 30, 2016 · 0 comments · Fixed by #382

Comments

@marcoscaceres
Copy link
Member

The following seems to be an authoring requirement:

The methodData supplied to the PaymentRequest constructor SHOULD be in the order of preference of the caller.

The following assertion seems to be out of place in the algorithm:

Implementations MAY show payment methods in this order if possible but should prioritize the preference of the user when presenting payment methods.

The above should be placed somewhere closer to when they payment request is actually shown.
domenic added a commit to domenic/browser-payment-api that referenced this issue Dec 14, 2016
@domenic
Straighten out the payment method data flow
77e3f54 
This fixes w3c#338 and helps with w3c#307 by stating more explicitly how the data member of PaymentMethodDetails is serialized to a string, stored, and later passed to the appropriate payment app.

Along the way, this fixes w3c#354.

This does not completely fix w3c#307, as the problematic JSON-serializable concept is still used for PaymentDetailsModifier (and is still not used by any part of the processing model; that's w3c#346).
@domenic domenic mentioned this issue Dec 14, 2016
Merged
domenic added a commit to domenic/browser-payment-api that referenced this issue Jan 10, 2017
@domenic
Straighten out the payment method data flow
930187d 
This fixes w3c#338 and helps with w3c#307 by stating more explicitly how the data member of PaymentMethodDetails is serialized to a string, stored, and later passed to the appropriate payment app.

Along the way, this fixes w3c#354.

This does not completely fix w3c#307, as the problematic JSON-serializable concept is still used for PaymentDetailsModifier (and is still not used by any part of the processing model; that's w3c#346).
domenic added a commit to domenic/browser-payment-api that referenced this issue Jan 10, 2017
@domenic
Straighten out the payment method data flow
b5b64a0 
This fixes w3c#338 and helps with w3c#307 by stating more explicitly how the data member of PaymentMethodDetails is serialized to a string, stored, and later passed to the appropriate payment app.

Along the way, this fixes w3c#354.

This does not completely fix w3c#307, as the problematic JSON-serializable concept is still used for PaymentDetailsModifier (and is still not used by any part of the processing model; that's w3c#346).
zkoch pushed a commit that referenced this issue Jan 11, 2017
@domenic @zkoch
Straighten out the payment method data flow (#382)
7527c12 
This fixes #338 and helps with #307 by stating more explicitly how the data member of PaymentMethodDetails is serialized to a string, stored, and later passed to the appropriate payment app.

Along the way, this fixes #354.

This does not completely fix #307, as the problematic JSON-serializable concept is still used for PaymentDetailsModifier (and is still not used by any part of the processing model; that's #346).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Straighten out the payment method data flow domenic/browser-payment-api
1 participant
@marcoscaceres