Re: [w3c/webpayments-payment-apps-api] Use PaymentRequest and PaymentResponse (#99)

Based on the Payment Apps TF call yesterday I believe there to be two issues under discussion here and we should separate them:

1. Should collection of non-payment data (shipping address, email, etc) be done directly through the API
2. Should the interfaces/dictionaries defined for PaymentRequest be re-used when passing data to payment apps

Regarding issue 1, as @adamroach points out, this was debated at length within the WG right at the beginning of our work. 

See: https://github.com/w3c/webpayments/issues/72
Wiki summarizing arguments: https://github.com/w3c/webpayments/wiki/Issue-Summary#gathering-shipping-address-data
Minutes of our Feb 2016 F2F: https://www.w3.org/2016/02/23-wpwg-minutes#item10

The resolution of the WG was to integrate collection of this data into the API.

@marcoscaceres , as an editor of the PR spec I think your best course of action if you think this should change is engage your fellow editors directly and come back to the group with a proposal that the editors all agree on.

---------------------------

Regarding 2, it is difficult to see how the current `PaymentRequest` interface could be re-used in the payment apps specification. It exposes a number of methods that should not be exposed to payment apps and does not publicly expose critical members such as the PaymentMethodData objects passed into it's constructor.

The same goes for the `PaymentResponse`, the majority of members would be set by the browser, not by the payment app.

```webidl
//From https://w3c.github.io/browser-payment-api/#paymentrequest-interface
[Constructor(sequence<PaymentMethodData> methodData, PaymentDetails details, optional PaymentOptions options),
 SecureContext]
interface PaymentRequest : EventTarget {
    Promise<PaymentResponse> show();
    Promise<void>            abort();
    Promise<boolean>         canMakePayment();

    readonly attribute DOMString?           paymentRequestID;
    readonly attribute PaymentAddress?      shippingAddress;
    readonly attribute DOMString?           shippingOption;
    readonly attribute PaymentShippingType? shippingType;

             attribute EventHandler         onshippingaddresschange;

             attribute EventHandler         onshippingoptionchange;
};

[SecureContext]
interface PaymentResponse {
    serializer = {attribute};

    readonly attribute DOMString       paymentRequestID;
    readonly attribute DOMString       methodName;
    readonly attribute object          details;
    readonly attribute PaymentAddress? shippingAddress;
    readonly attribute DOMString?      shippingOption;
    readonly attribute DOMString?      payerName;
    readonly attribute DOMString?      payerEmail;
    readonly attribute DOMString?      payerPhone;

    Promise<void> complete(optional PaymentComplete result = "unknown");
};
```

The current API shape is partly a result of the resolution the group took to capture shipping data and partly a result of discussion around making the API more compose-able.

There were strong advocates for a more compose-able API that separated the PaymentRequest from other, non-payment, stuff.

See: https://github.com/w3c/webpayments/issues/39
Also the proposal from @dlongley for a checkout API that could call the payment API:
https://github.com/w3c/webpayments/wiki/Checkout-API

The strongest proponents for the current structure were @zkoch and @adrianba who at the time were the editors of the PR spec.

@marcoscaceres , again, if you want to change the shape of the API then I suggest discussing this with your fellow editors first. I don't think it is useful for the group to debate this any further while the editors and implementors are not in agreement. 

For example, taking inspiration from @dlongley 's proposal, if there was a `CheckoutRequest` that wrapped a `PaymentRequest` where the `CheckoutRequest` was the interface exposing non-payment related members then it seems conceivable that the `PaymentRequest` could be exposed directly to the payment apps.

I suggest we close this issue and allow the editors of Payment Request to decide how they wish to proceed with that spec and on that basis we can decide if there is a need to make changes to the Payment Apps spec.

-- 
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/webpayments-payment-apps-api/issues/99#issuecomment-278326772