Re: [w3c/browser-payment-api] Use navigator.payments singleton, factory method, or PaymentRequest constructor (#16)

> This means we should not have a singleton for a payment request.

Upon re-reading all the threads, I don't think anyone proposed a singleton object with shared internal state as a solution? So, I see no support for that, which is good, because I think we're all in agreement on that point.

I think what's being proposed is this general shape:

### navigator.payment Proposal

```javascript
partial interface Navigator {
  readonly attribute PaymentsInterface payment;
};

interface PaymentsInterface {
  Promise<PaymentResponse> request(..., options); // this is used by a merchant
  Promise<PaymentRequest> getPendingRequest(); // this is used by a payment app
};
```

### Example usage

To create a payment request, you do this:

```javascript
var pr = navigator.payment.request(...);
```

instead of this:

```javascript
var pr = new PaymentRequest(...);
```

Not much difference here, other than how much one has to type. So, let's keep looking for some other usages of the API, like getting pending requests (Payment App) and doing feature detection (general feature):

```javascript
// the payment app will need to make this call when it is invoked
var pr = navigator.payment.getPendingRequest();
```

It's true that we could do it like this:

```javascript
// the payment app will need to make this call when it is invoked
var pr = PaymentRequest.getPendingRequests();
```

Again, we could do it either way, no strong argument for one over the other yet. 

Now let's add a feature that doesn't really have to do with Payment Requests but does have to do with the payments ecosystem:

```javascript
var reg = navigator.payment.registerApp(...);
```

and this is how this might be handled with the current spec approach:

```javascript
var reg = PaymentRequest.registerApp(...);
```

Now it starts getting a bit strange. Why are we calling the app registration method on PaymentRequest? What does registration have to do with the PaymentRequest interface? This same argument will come up if/when we add any functionality that has a tenuous connection to PaymentRequest. For example, how do we initiate the storage of digital receipts? 

```javascript
var save = PaymentRequest.storeReceipt(...);
```

At this point, PaymentRequest stops being just about payment requests and is instead starting to be used as "the Payment Request API static object". To put it another way, we have two things that we're talking about here:

1. The functionality that is available via the Web Payments ecosystem.
2. The functionality that is available via a Payment Request object.

The current specification attempts to shove both items above into PaymentRequest and that seems like a bad thing to do from a design perspective because it turns something that's meant to be a fairly clean and simple interface (PaymentRequest) into a grab bag of functionality (everything that you can do in the Web Payments ecosystem).

So, by using the proposal above, it will help organize methods mostly unrelated to PaymentRequests under an easily understandable namespace 'navigator.payment.'


---
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/16#issuecomment-217269345