Extensibility of PaymentResponse.complete(result)

In his analysis of SRC, @mountainhippo identified the need to have a post-authorization step where the merchant/website notifies the payment handler of the result of the payment.

I believe that this is roughly why we have PaymentResult.complete(result) driven by a similar requirement from Apple Pay (@aestes can confirm).

My question is, how extensible can we make the result argument so we can support other payment methods with this requirement?

result is currently defined as being an optional PaymentComplete enum but I think it would be better if it was more generic.

The ideal would be if payment method specs could define a format for this (JSON serializable object) in the same way they do for their custom payment request and response data.

This would allow an SRC payment method spec to define the exact format of result when a website calls PaymentResponse.complete(result) after a payment.

Concretely this would mean:

1. Change the definition of the PaymentResponse interface such that PaymentResponse.complete(response) is defined as:

  [NewObject]
  Promise<void> complete(optional object result);

where object is the object type (as used in the definition of PaymentMethodData.data).

2. Change the definition of the complete() method to include a definition of result argument. Something like the following, copied from PaymentMethodData.data:

An object that provides optional information that might be needed by the supported payment methods. If supplied, it will be JSON-serialized.

3. Move the definition of the PaymentComplete enum out of the PR API spec and into payment method specs that use it as is (E.g. Apple Pay).

The effect is that any payment method specification can then define 3 custom data formats:

1. request data, passed in by the website as PaymentMethodData.data
2. response data, received by the website as PaymentResponse.data
3. complete data, passed in as result by the website when calling PaymentResponse.complete(result)