Behavior when method-specific data is invalid

[rsolomakhin]

If someone writes this:

new PaymentRequest(
    [{supportedMethods: ["basic-card"], data: {supportedNetworks: 0}}],
    shoppingCart);

Should the constructor throw, because supportedNetworks must be a list according to this spec? The alternative is to pass this information to the payment app as-is and let it decide what to do with it. If we pass to the app, it would be great to clearly define the expected behavior for invalid method-specific data.

[zkoch]

Seems like throwing is the right call to me. We should probably clearly define that behavior. @adrianba thoughts?

[rsolomakhin]

@marcoscaceres opinion would also be good to hear.

[marcoscaceres]

Should the constructor throw, because supportedNetworks must be a list according to this spec?

Yeah, it will throw. The IDL binding layer will cause it to throw automagically with a TypeError.

[marcoscaceres]

Wait, sorry, I misread the code (though the second supportedNetworks was a new entry).

[marcoscaceres]

Got confused, because PaymentRequest() defines PaymentMethodData.data to be an object 😳

Looking at the right spec now: Yes, it will throw... but PaymentRequest() will obviously need to be updated to support this type.

[rsolomakhin]

I propose we update the basic-card spec like with this phrasing:

If supportedMethods contains "basic-card" and data is not in correct format, then user agent MAY throw TypeError.

For PaymentRequest spec:

If data format does not match the specification of its supportedMethods, then user agent MAY throw TypeError.

I'm using MAY instead of MUST because throwing works only for built-in payment methods, where user agent knows the format beforehand. Today that's "basic-card" and "https://android.com/pay" for Chrome, for example. However, when we have payment apps like "https://samsung.com/pay" or "https://alipay.com", then the user agent will not know the right format of data, so it cannot throw in constructor. It can, however, reject the show() promise in that case.

[zkoch]

@adrianba thoughts?

[rsolomakhin]

Ping...

[rsolomakhin]

@domenic: Did we come to a conclusion of whether invalid "basic-card" method data should throw in PaymentRequest constructor?

[domenic]

I believe the conclusion was that it should not. The data needs to be serialized and sent to the payment app, which then is responsible for validating and processing it.

[rsolomakhin]

Excellent, thank you.