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

> So, payment method identifiers are literally just unique identifiers that identify a means of payment (schema, behavior) between a payment requester and a payment app. Quite literally anything that is globally unique will work. GUIDs would be technically fine, although they are pretty developer-unfriendly.

I'm not sure I necessarily agree with this. There are situations where this is true (e.g. basic_card), but it does not necessarily hold true for proprietary payment schemes. BobWallet.com can not arbitrarily say it supports AlicePay.com if AlicePay.com is a proprietary payment system. It just can't work. So there has to be some mechanism by which the payment mediator can validate this statement. This is why payment method identifiers are identifiers, but they can't *just* be identifiers. Something has to live at the end of that.

We've just tried to solve this problem in steps. We pushed for URLs because we were pretty sure we would need something machine readable to live at the end of that URL that we could get. I realize Tab is trying to say that we shouldn't agree to use URLs until we agree what should be at the end of them, but I'm not sure that is necessarily true. But we probably should get consensus in the group that something should live at the end of that URL before agreeing to use URLs. 

-- 
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-240247631