Re: [w3c/browser-payment-api] PaymentDetails should include a transaction ID (#287)

@halindrome 
>I don't like the idea of this in the payment method data. That data is opaque to the payment app, which means the payment app cannot then help its user out with correlating things later.

This came up in break-time conversations earlier this week, too. The fundamental problem is that we're conflating payment-specific transaction identifiers (which might have meaning outside the browser context, such as auditing with a third party that a payment has occurred) and transaction identifiers that are purely a matter of local concern to the payment request/payment app APIs.

If we're going to allow payee websites to ask about existing transactions, we need an identifier -- of concern only inside the browser -- that lets it indicate which transaction it's talking about. It would be a horrible mistake to try to mix this up with an identity that meant something to the payment method.

So, we're basically given three options:
1. Let the payee choose the *browser-scoped* transaction ID
2. Let the payment app choose the *browser-scoped* transaction ID
3. Let the mediator (browser) choose the *browser-scoped* transaction ID

Option 1 has the drawback that it imposes the unnecessary task of generating a unique ID on the myriad payee apps, to no benefit.

Option 2 has that same drawback for the payment app, with the additional flaw that it requires a new id-providing call altogether when the app is first invoked.

So I like option 3.

Concretely, what I would propose is: at the time the constructor to `PaymentRequest` is called, part of its construction is adding a read-only `transactionId` attribute to the object. On the payment app side, this same value would also appear in a read-only `transactionId` attribute at the top level (i.e., as a peer to the `data` attribute) of the `PaymentRequestEvent` object.

```webidl
[Constructor(sequence<PaymentMethodData> methodData, PaymentDetails details, optional PaymentOptions options),
 SecureContext]
interface PaymentRequest : EventTarget {
    Promise<PaymentResponse> show();
    Promise<void>            abort();

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

    readonly attribute DOMString            transactionId;

    // Supports "shippingaddresschange" event 
             attribute EventHandler         onshippingaddresschange;

    // Supports "shippingoptionchange" event 
             attribute EventHandler         onshippingoptionchange;
};
```

```webidl
interface PaymentRequestEvent : ExtendableEvent {
    readonly attribute PaymentAppRequestData data;
    readonly attribute DOMString transactionId;
    void respondWith((Promise<PaymentResponse> or PaymentResponse) r);
};
```

To be clear: if the app and/or the payee want to correlate some payment-specific payment request identifier with the *browser-scoped* payment ID, that's trivial:

`bobpayPaymentAuditToken[request.transactionId] = auditToken`

I think this is simple to implement, imposes no additional load on payment methods/attributes/apps that don't care about it, and allows for all of the correlation use cases that have been described so far.

**TO BE CRYSTAL CLEAR: IF THERE IS A PAYMENT-METHOD-SPECIFIC TRANSACTION ID THAT MEANS ANYTHING TO ANYTHING OUTSIDE THE BROWSER, IT IS A DIFFERENT THING AND IS SENT IN THE OPAQUE `data` FIELD**. This proposal in no way attempts to replace those mechanisms. Any correlation between payment-method-specific identifiers and the browser-specific identifiers is done by the payee and payment apps in whatever means, if any, they find it appropriate to do so.

-- 
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/browser-payment-api/issues/287#issuecomment-249231673