[w3c/payment-request] Extensibility of PaymentResponse.complete(result) (#817)

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`](https://www.w3.org/TR/payment-request/#dom-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](https://www.w3.org/TR/payment-request/#dom-paymentresponse) interface such that `PaymentResponse.complete(response)` is defined as:

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

where `object` is the [object](https://heycam.github.io/webidl/#idl-object) type (as used in the definition of [`PaymentMethodData.data`](https://www.w3.org/TR/payment-request/#paymentmethoddata-dictionary)).

  2. Change the definition of the [complete()](https://www.w3.org/TR/payment-request/#complete-method) 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`](https://www.w3.org/TR/payment-request/#dom-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)`



-- 
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/payment-request/issues/817