[w3c/browser-payment-api] Straighten out the payment method data flow (#382)

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).

---

This is on top of #374 and should be merged only after that is.

If this looks correct, then to clarify how the basic card spec actually interacts with the main spec, we'll edit the basic card spec to say:

- Payment apps for basic card must determine if they support the requested payment method by first performing steps equivalent to parsing the supplied data using JSON.parse, then converting the resulting object to a BasicCardRequest dictionary, and inspecting the results.
- Payment apps for basic card must supply a result object back to the payment request flow in the form of a BasicCardResponse dictionary.

This will then solve https://github.com/w3c/webpayments-methods-card/issues/20.
You can view, comment on, or merge this pull request online at:

  https://github.com/w3c/browser-payment-api/pull/382

-- Commit Summary --

  * Various fixes to the PaymentRequest constructor
  * Straighten out the payment method data flow

-- File Changes --

    M index.html (432)

-- Patch Links --

https://github.com/w3c/browser-payment-api/pull/382.patch
https://github.com/w3c/browser-payment-api/pull/382.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/pull/382