- From: <Joerg.Heuer@telekom.de>
- Date: Fri, 15 May 2015 11:47:53 +0200
- To: <ij@w3.org>, <msporny@digitalbazaar.com>
- CC: <public-webpayments-ig@w3.org>
Hello Ian, all, Please find a few comments on the requirements below: Cheers, Jörg -----Original Message----- From: Ian Jacobs [mailto:ij@w3.org] [...] Here’s a quick comparison: * Open Loop: Web is open loop. We expect Web to act as a bridge between both open and closed loops. JH> as web technology is increasingly found in enterprise environments, I'd say our solution is neutral to that, but definitely supports open and closed loops as well * Immediate funds transfer. I think our expectation is to impose no time delays by virtue of our architecture. Any delays will be inherent to the underlying systems. * Push payments: We are enabling both push and pull payments within the system. * Same-day Settlement: Our expectations is to impose no time delays by virtue of our architecture * Open international standards: Yes! * Irrevocability: That seems to be a property that we would not enforce directly through our architecture but would depend on an underlying system. JH> again, this is one facet which we definitely won't want to be a hindrance for. Whether this is so or not depends on the business model and regulation. I'd welcome a lot of variety here... * Shared fraud service: Same * Tiered KYC: Same JH> KYC is an identity issue which usually plays a role in enrolment, at times it night go alongside with a transaction. That's why I'd hold hopes in a credential-based approach to both (in as far as people are involved at least) [...]
Received on Friday, 15 May 2015 09:48:28 UTC