Re: [w3c/payment-request] Allow custom data for the active payment method to be provided to `PaymentResponse.prototype.complete` (Issue #981)

Random observations:

1. If passing the `PaymentMethodData` to the payment sheet via `.complete()` is critical for this use case, then we should do the overload (i.e., no backwards compat, force a promise rejection). 
2. If 1 is not critical, then extending the method signature with a second argument is the way to go. Having said that, it maybe safer to just do the second argument, then developers can use the same code path for new and old implementations (in theory)... second arg is just ignored in old implementations, assuming then everything works as expected. 
3. What about passing a sequence? Every `PaymentResponse` has an associated `.methodName` attribute, which is the one the user chose to perform the payment (e.g., https://apple.com/pay). Thus, using a `sequence<PaymentMethodData>` might be somewhat redundant, as the data being passed can only ever apply to whatever `paymentResponse.methodName` is. 

So, with the above... I tend to land at @dcrousso second suggestion: 
 
``` 
partial interface PaymentResponse {
  [NewObject] Promise<undefined> complete(optional PaymentComplete result = "unknown", optional object paymentMethodData);
}
```

However, I'm worried about it being an unstructured object, so how about:

```
dictionary PaymentCompleteDetails {
  object data;
}

partial interface PaymentResponse {
  [NewObject] Promise<undefined> complete(optional PaymentComplete result = "unknown", optional PaymentCompleteDetails = {});
}
```


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/981#issuecomment-1016081451
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/payment-request/issues/981/1016081451@github.com>