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

The "data" member of PaymentDetailsModifier doesn't seem to be used for anything #346

Closed
bzbarsky opened this issue Nov 30, 2016 · 7 comments · Fixed by #404
Closed

The "data" member of PaymentDetailsModifier doesn't seem to be used for anything #346

bzbarsky opened this issue Nov 30, 2016 · 7 comments · Fixed by #404

Comments

@bzbarsky
Copy link

There's no processing model defined for it that I can tell.
@nickjshearer
Copy link

Isn't it simply intended to be passed back to the payment instrument?

@ianbjacobs
Copy link
Collaborator

@nickjshearer wrote:

"Isn't it simply intended to be passed back to the payment instrument?"

Yes, except I would say "to the payment app" that handles that payment method. The payment app could be the browser or a third party payment app.

Ian

@bzbarsky
Copy link
Author

bzbarsky commented Dec 5, 2016

You can't pass an object to a third-party payment app. See also #307

@rsolomakhin
Copy link
Collaborator

We can run JSON.stringify(data) and pass the result to the third-party payment app.

@bzbarsky
Copy link
Author

bzbarsky commented Dec 5, 2016

OK, that's fine. The spec then needs to:

  1. Define exactly when JSON.stringify runs, because it can have observably side-effects. Again, see The myth of JSON-serializable object #307

  2. Define that the resulting string is passed somewhere, wherever that is.

@bzbarsky bzbarsky mentioned this issue Dec 6, 2016
Closed
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).
@domenic
Copy link
Collaborator

domenic commented Jan 14, 2017

Can someone (@rsolomakhin?) help me understand exactly in which steps the data is passed to the payment app? For example, we determined that the methodData (parsed into [[parsedMethodData]]) is passed to the payment app in canMakePayment and in show. Is the idea that the payment apps should receive not only the method data, but also the payment details modifier data, at both of those points?

@rsolomakhin
Copy link
Collaborator

Both .canMakePayment() and .show() should be sending the method-specific data to the payment app, because that can include some important filtering information. For example, data for "basic-card" payment method includes supportedNetworks. If merchant specifies supportedNetworks: ["jcb"], but the only installed payment app is not aware of JCB, then .canMakePayment() should resolve with false and .show() should reject with NotSupportedError.

As for modifiers, that should be used for altering the price, which is important when completing a transaction, not when determining whether a transaction can procede. Therefore, modifiers should be sent to the payment app with .show(), but not in .canMakePayment().

domenic added a commit to domenic/browser-payment-api that referenced this issue Jan 20, 2017
@domenic
State how payment details modifier data is serialized and used
27d0eba 
This closes w3c#346, by making it clear that the data is serialized and stored in the PaymentRequest for further usage by show(), and closes w3c#307, by finally stating all the points at which JSON-serialization happens explicitly.
@domenic domenic mentioned this issue Jan 20, 2017
Merged
marcoscaceres pushed a commit that referenced this issue Jan 25, 2017
@domenic
State how payment details modifier data is serialized and used (#404)
9e5aeff 
* Editorial: rename "parsedMethodData" to "serializedMethodData"

We actually store the serialized form, not the parsed form; this is more accurate.

* State how payment details modifier data is serialized and used

This closes #346, by making it clear that the data is serialized and stored in the PaymentRequest for further usage by show(), and closes #307, by finally stating all the points at which JSON-serialization happens explicitly.

* Fixed [[\serializedModifierData]] nit
@marcoscaceres marcoscaceres mentioned this issue Jan 29, 2019
Closed
7 tasks
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.

State how payment details modifier data is serialized and used domenic/browser-payment-api
5 participants
@nickjshearer @domenic @rsolomakhin @bzbarsky @ianbjacobs