Offline has already been solved in the non-Web world where different trust models are applied for different payment instruments. Based on the level of trust a limit is applied to transactions that can be performed online. EG: A platinum credit card is often authorised offline for low amounts whereas a debit card is usually required to go online. The rules for such a limit (often called a floor-limit - "authorised on the floor") can be complex and are usually set as part of network agreements or domestic directives. There should be no need to change this model for the Web. If the payer and payee are offline then the payee decides what transactions it will accept in this offline state determined by type (eg: usually cash withdrawals are not allowed), amount and how much they trust the credentials provided by the payer. The Web Payments standard should not try to define these rules but allow for offline on a similar model by supporting things like offline transaction signing etc. On 2 May 2015 at 18:57, Melvin Carvalho <melvincarvalho@gmail.com> wrote: > > > On 2 May 2015 at 18:20, Anders Rundgren <anders.rundgren.net@gmail.com> > wrote: > >> When doing mobile Web (browser) payments the connectivity issue wouldn't >> be relevant but when doing payments in a brick-and-mortar shop I see >> Internet connectivity as a stumbling block. This IMO excludes >> server-wallets unless they do "intelligent caching" like the Google Wallet. >> >> 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. >> > > I suggest to queue the tx locally until you get connectivity. > > >> >> Anders >> >> >
Received on Sunday, 3 May 2015 16:48:55 UTC