Re: Payment Method Identifiers

Zach, thanks for raising this. I started trying to push the payment method
identifier related issues up the priority list late last week but need to
finish that for the call Thursday.

+1 on using absolute URLs

However, I have a slightly different take on the short names debate.

I don't think any payment method identifier at a URL that is not relative
to a base owned by this group (e.g. http://w3.org/payments/WG/methods or
similar) should have a short-name. For the many reasons discussed in the
issue lists I am strongly against us trying to maintain a public registry
and don't think it is necessary - these are just aliases, they are not
essential.

So I am +0 on using short-names, I think they add complexity that is not
needed.

That said, if we do use aliases/short names I propose we do the following:


   1. Any payment method specification that is published by the WG (Basic
   Card Payments is the first, SEPA is currently an editors draft and therefor
   a candidate) will define one or more payment method identifiers.
   2. These identifiers will all be absolute URLs and SHOULD all use the
   same base URL (to be decided what that is, I propose
   http://w3.org/payments/WG/methods/).
   3. The matching rules for payment method identifiers are preceded by the
   following normalization rules:
      1. If an identifier is not an absolute URL it must be assumed to be a
      relative URL with the base http://w3.org/payments/WG/methods/
      2. If an identifier is a URL with the protocol value equal to "https"
      or not specified set the protocol to "http"
      3. If the last character of the identifier is not the forward-slash
      '/' character, append a forward-slash '/' to the identifer.
   4. Any new payment method specs that are developed within W3C (or
   submitted to the W3C to be published in this namespace) will follow the
   same publishing process. i.e. Through consensus of the WG (or some other
   group nominated by the WG when our charter is up) a new payment method
   identifier spec will be adopted as an editors draft and later, also through
   consensus of the group, published as a working draft and then a note.
   5. Only payment method specs published in this way should use
   identifiers with the base URL http://w3.org/payments/WG/methods/
   6. The payment method identifier spec should define this process and the
   normalization rules but also explicitly point out that independently
   developed payment method specs are encouraged but that they must ONLY use
   absolute URLs as identifers.

It's important to note that the whole design of this system was to decouple
the designers of a payment method spec from the issuers of payment
instruments to create a level playing field and also encourage innovation.

That is to say, there is nothing preventing an authority over a specific
brand of payment instrument (like VISA, MasterCard, UnionPay etc) from
defining their own spec but that should not preclude the community from
coming up with their one too.

We (the WG) have decided to bootstrap this by defining a bunch of payment
method specs of our own and if, for example, the card companies decide they
don't like ours they can either:
1. Submit changes to it which the group must agree to adopt OR
2. Publish their own and persuade payment app developers and
websites/payment processors to use theirs instead or as well

We have given ourselves the privilege of using short-names for our PMIs
because any payment method spec that we publish will have gone through a
process that we know to be fair and transparent and this advantage should
encourage developers of new specs to use this process.

The idea is that while it feels like there will be a lot of fragmentation
the market will likely force standardization and we get that without
limiting innovation or handing control to any specific entity or group.
Instead, the success of a payment method standard is down to adoption and
that is influenced by a number of factors we can't control (a good thing I
think).



On 4 May 2016 at 03:59, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 05/03/2016 09:03 PM, Zach Koch wrote:
> > In short, I want to propose a modified version of Option 1b Namely, I
> > think all payment method identifiers should be absolute URLs
>
> +1
>
> > 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.
>
> There is one concern that I have with what you say above.
>
> The first is that I don't think we'll ever be able to get rid of those
> short-listed schemes once people start using them. Web Payments examples
> will proliferate online using the short names and merchant site and
> payment apps developers will blindly copy the examples and that will be
> that.
>
> Payment Apps are not going to risk not matching against "visa-debit" if
> merchants are putting that in their payment requests (because payment
> apps developers want people using their apps and there is a strong
> incentive to NOT throw an error when they see "visa-debit" and they
> support "https://visa.com/payment-methods/visa-debit".
>
> Browser vendors will want to continue matching a Payment App that says
> it supports "visa-debit" when seeing "visa-debit" in the Payment Request
> (OR the URL equivalent) because developers will complain that it's
> "breaking the Web" to not do so.
>
> Merchants won't update their websites for years after implementing a
> number of short-listed schemes and will complain loudly if you take
> those short-listed schemes away from them.
>
> So, while I agree that this particular part of your proposal would lead
> to a better world, I don't think we could realistically force that
> transition without making large parts of the payments ecosystem very
> cranky.
>
> > My proposed starting list:
> >
> > visa visa-debit visa-credit mastercard mastercard-debit
> > mastercard-credit unionpay unionpay-debit unionpay-credit amex
> > discover
>
> +1 to this list.
>
> How does a merchant say they accepted tokenized versions of those cards
> as responses? Do we need a new short name for that, or does the basic
> card payment method have a "tokenization field"? My concern is that we
> may need to double the size of that short list if we want to support
> tokenization?
>
> > My hope is that in the not-too-distant future we're able to remove
> > these short codes from the spec
>
> Unfortunately, I don't think this is realistic for social reasons. :(
>
> > 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).
>
> +1, in fact, I think this would be a good reason to reach out to the
> schemes (again) and get them involved.
>
> So, I'm generally supportive of Zach's modified 1b proposal modulo the
> concerns raised above.
>
> A couple of follow-on questions:
>
> If we wanted to use these short names in the HTTP API (assuming it's
> added as a work item), how would we do it?
>
> If the group doesn't think we could ever remove the short names, doesn't
> that put us in the position of requiring aliases for the URLs the
> schemes pick? Wouldn't we have to say "visa-debit" is equivalent to
> "https://visa.com/payment-methods/visa-debit" somewhere?
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> JSON-LD Best Practice: Context Caching
> https://manu.sporny.org/2016/json-ld-context-caching/
>
>