Re: [webpayments] Payment Method Identifier Registry should have oversight / formal structure (#25)

I don't mind that approach. For me that's as low as the bar should be
though.  At least then any "wallet" application can capture the information.

However, I strongly feel that same information should be discoverable by
the app.  When I go into "Android Pay" today and tell it I have a whatever
card, I don't need to navigate to the site and somehow pass the information
about how to use that card into the Android Pay app.  Android Pay knows
about the card and just deals with it.  Similarly it knows about basically
every affinity card I have ever thrown at it (in it's Google Wallet
incarnation).  Google has the resources to build all that intelligence into
their app.  I am sure that on their back end they have a dereferencing
mapping for all the things they support, so their app can dynamically
expand its collection.  Why not afford the little guy (Jim's Smart Wallet
Company) the same benefit by at least permitting Bob Pay to register their
information somewhere that is discoverable?  Then Jim's Smart Wallet has a
fighting chance and can compete on features instead of on how many
different payment methods it knows about.

On Mon, Dec 7, 2015 at 11:01 AM, Dave Longley <notifications@github.com>
wrote:

> It seems to me that when people go out and get new payment
> methods/instruments from various websites, those methods/instruments should
> contain standard, machine-readable, self-describing data. A smart wallet
> can then make use of that information which will have the affect of
> "dynamically expanding its collection". The new information can be driven
> to the wallet via the wallet's users and the wallet can present new
> features that arise from it.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/w3c/webpayments/issues/25#issuecomment-162592756>.
>



-- 
Shane McCarron
halindrome@gmail.com


---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/25#issuecomment-162595328

Received on Monday, 7 December 2015 17:09:37 UTC