Re: Mobile payments and Connectivity issue

> Anyway, I wouldn't design a mobile payment system so that it requires
> Internet connectivity.  Pushing [an encrypted locally signed
> transaction + a URL to the bank] through the merchant seems like a
> viable approach both for Web and Local payments.  Assuming that the
> merchant also is off-line is IMO bending things one step too much.

W3C = Browser not a mobile phone.

At a certain point device limitations and internet connectivity are 
major factors of what kind of transaction is possible.

1) Confirmation code to a merchants POS
2) High value transaction requiring a 2nd confirmation step, biometric 
matching, or real-time regulatory reporting
3) Delivery of an eReceipt
4) International payment
5) Transaction requiring a currency clearing house. Say EURO to USD or 
Bitcoin to
6) 1 time use electronic coupon or usage of loyalty points for a 
transaction
7) Lets not discount the back end payment systems require connectivity 
with their users.

Now a days connectivity is required for a lot of our lives.

BTLE, NFC, visual payment systems like QRCodes are still "connected" 
just differently. Nearly all use cases require a "connectivity" of some 
sort.

In the case of where connectivity is an issue I expect new technologies 
like a Wocket Wallet will be used instead. If all else fails, punt to 
the standard card transaction.

Erik Anderson
Bloomberg R&D & Co-chair W3C Web Payments IG/SG

Received on Monday, 4 May 2015 13:34:09 UTC