Re: Payment Method Identifiers

I just did a front-to-back read of all the specs, and I have a number of 
comments that I plan to bring to the list once I've digested them a bit. 
One of these comments has an incidental impact on identifiers, so I'm 
going to describe it in this thread. I apologize if this isn't 
completely baked, but I wanted to get it into the conversation before it 
moved on too far.

As a prerequisite, I'm going to assert that most sites making use of the 
payment API will generally have a fall-back mechanism for browsers that 
do not yet support their payment methods (since the alternative would be 
not accepting money from those users). Given the way the system is 
currently described, this can lead to the following situation:

 1. I'm a regular user of sell-me-stuff.com. They use the payments API,
    if available, and fall back to an html-form-based credit-card system
    if not. They accept several basic card methods, as well as a bitcoin
    method.

 2. As I don't historically have any payment apps installed, I usually
    go through their form-based system and pay with a credit card.

 3. Later on, I go to a different site to purchase music. As they only
    accept bitcoin, the site guides me through the process of installing
    a payment app that supports a bitcoin method.

 4. Upon my return to sell-me-stuff.com, instead of bringing up the
    credit card form that I'm used to, I get a payment app that gives me
    the option of paying in bitcoin, but not with a credit card.


Clearly, this would make me quite unhappy, if I wanted to continue to 
pay sell-me-stuff.com using a credit card.

There are a bunch of little design choices that got us to the point that 
the system exhibits this as an emergent behavior. I think we can tweak 
them a little bit here and there to make things more sensible, but 
almost every solution I've been able to thumbnail out requires payment 
app discoverability. That is: given a payment method identifier, one 
would need the ability to, minimally, discover information about the 
payment method for rendering to the user; and, ideally, locate a 
suitable payment app.

 From that perspective, I'm pretty certain that we want to ensure that 
identifiers remain mechanically resolvable (which is what I hear most 
support for, so I think we're good there). But beyond that, we need to 
make sure that the authority they resolve to is in a position to provide 
the information I mention above (whether the minimal set that lets a 
user know about a payment method that they don't yet have installed, or 
the larger set that guides them to an app that supports that method).

/a


On 5/3/16 20:03, Zach Koch wrote:
> Hi all -
>
> I want to once again jumpstart the conversation around payment method 
> identifiers. My hope is that we can reach some form of consensus over 
> the next couple of weeks, as I think it's one of the major parts of 
> the browser API spec that we still don't have a firm answer on.
>
> In short, I want to propose a modified version of Option 1b 
> <https://w3c.github.io/browser-payment-api/specs/method-identifiers.html#option-1b> in 
> the current spec 
> <https://w3c.github.io/browser-payment-api/specs/method-identifiers.html>. 
> Namely, I think all payment method identifiers should be absolute 
> URLs, but I do not think we should try and maintain a short identifier 
> registry (at least, not in the long run). We do need to bootstrap the 
> ecosystem, however, without waiting for the major payment methods 
> (e.g. visa, mc, etc) to define those URLs.
>
> To that end, I would propose we define a (very) short list of payment 
> methods that we write into the spec as a means of jumpstarting things, 
> but that we plan to remove them as soon as the short-listed schemes 
> provide an absolute URL that can replace them.
>
> My proposed starting list:
>
> visa
> visa-debit
> visa-credit
> mastercard
> mastercard-debit
> mastercard-credit
> unionpay
> unionpay-debit
> unionpay-credit
> amex
> discover
>
> My hope is that in the not-too-distant future we're able to remove 
> these short codes from the spec and instead rely on the schemes 
> themselves to provide the absolute URLs for these, e.g. 
> https://visa.com/payment-methods/visa-debit (or similar).
>
> I think relying purely on absolute URLs has a number of benefits, but 
> I would encourage your feedback. Hopefully we can find some time on 
> the call on Thursday to discuss things in more depth as well.
>
> Thanks,
>
> Zach


-- 
Adam Roach
Principal Platform Engineer
Office of the CTO