Re: [w3c/browser-payment-api] The "data" member of PaymentMethodData doesn't seem to actually be used for anything (#338)

> See, for example, the relevant section in the basic card specification.

This link appears broken. Assuming it is meant to go to https://w3c.github.io/webpayments-methods-card/#basiccardrequest, @bzbarsky's point still stands. Nothing in the spec actually uses that dictionary. In https://github.com/w3c/browser-payment-api/pull/381 we're adding validation that the data is in the correct format, but we're still never using the data. So as far as I can tell it is conformant to implement the specification by completely ignoring the data member, e.g. by accepting debit cards when the site specifies it only accepts credit cards.

To fix this, probably what is necessary is to insert a step into https://w3c.github.io/browser-payment-api/#user-accepts-the-payment-request-algorithm which passes data to some algorithm defined in each payment method specification, and then the payment method specification for basic-card can say something like "use supportedMethods and supportedTypes to determine an appropriate response by prompting the user." That algorithm will also probably be what creates the appropriate payment response details vaguely alluded to in step 7:

> Set the details attribute value of response to a JSON-serializable object containing the payment method specific message that will be used by the merchant to process the transaction. The format of this response will be defined for each payment method. 

(Currently basic card definitely does not define a format for that response. It defines a BasicCardResponse dictionary, but never says that an instance of that dictionary should be created and used in the algorithm, and never says how to populate the values.)

-- 
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/issues/338#issuecomment-267142342

Received on Wednesday, 14 December 2016 20:10:33 UTC