Re: Payment Method Identifiers

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/

Received on Wednesday, 4 May 2016 01:59:50 UTC