Re: [w3c/webpayments-method-identifiers] Why URLs? (#9)

@tabatkins 
> I got the payment_app_id from where you pointed me to - I don't see anything at that destination that talks about registering a payment_method_id.


It's:
```webidl
    static Promise<void> register(URLString payment_app_id,
                                  URLString request_url,
                                  sequence<PaymentOption> payment_options);
```
Where:
- `payment_app_id` is a unique identifier for the payment app (n.b., if URL isn't okay for an identifier, we may need to re-think this as well)
- `request_url` is the place the identified app is retrieved from (posted to in the current document; but, as I say, that's changing)
- `payment_options` (maybe not the best name) is a list of these:

```webidl
dictionary PaymentOption {
    DOMString           label;
    DOMString           icon;
    sequence<DOMString> enabled_methods;
};
```
...and `enabled_methods` is a list of **payment method identifiers** that the payment app can support. (I forgot that these aren't called `payment_method_ids` in the spec; they probably should be).

> Was I misinterpreting every use of "app" by people earlier in the thread?

Probably. There's a as-of-yet undefined notion of having "native apps" registered for some payment methods as well, but that's a complication that we don't need to bring into this issue. For the purpose of _this_ conversation, it really does not make any difference whether it's a SW-like thing or a native app. For the purpose of _this_ conversation, what we need is some system for creating guaranteed unique payment method identifiers in either a decentralized, zero-friction manner.

-- 
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-method-identifiers/issues/9#issuecomment-240312150