W3C home > Mailing lists > Public > public-payments-wg@w3.org > May 2016

Payment Method Identifiers

From: Zach Koch <zkoch@google.com>
Date: Wed, 04 May 2016 01:03:51 +0000
Message-ID: <CAOsZg64d4JCTCkVExa1i-TZ7ni6EgLp3rbj=2UcRPAbHQFYH9Q@mail.gmail.com>
To: Payments WG <public-payments-wg@w3.org>
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
Received on Wednesday, 4 May 2016 01:04:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 4 May 2016 01:04:30 UTC