Re: Categorized use cases updated w/ comments

On 08/14/2014 04:45 AM, Michael Williams wrote:
> i added the use case i suggested: 
> https://www.w3.org/community/webpayments/wiki/UseCases#Unclassified.2FUnreviewed

Great, thanks for the addition Michael.

Could you fill out how you think this might work? For example, what
you're proposing sounds a bit like intermediary bank processor as it
relates to bank wire transfers. These sorts of arrangements tend to lead
to high fees due to the risk taken on by the intermediary, so we've
tried to steer clear of them in the past.

A better approach would be to do something like convert to Bitcoin at
your payment processor and then complete the transfer in that way with
the receiving merchant's payment processor converting back into the
currency in question.

>> Use Case: When a customer intends to make a payment, it is
>> possible to pick
> a payment processor trusted by the merchant as an intermediate proxy 
> for a payment processor not trusted by the merchant.
> 
> am i wrong in thinking that the current use cases only support a 
> handful of mega payment processors? for example, if 1000 people band 
> together and create a cooperative payment processor, how will they 
> ever be able to use it if they are unknown to nearly all merchants?

There are a couple of ways around this problem, but the core of the
issue has to do with how the payment network clears the money. We could
do one of these things:

1. Use a clearing network that is decentralized like Bitcoin, Ripple, or
Stellar. This would mean that payment processors wouldn't need to
coordinate with each other wrt. clearing and what sort of digital
receipt is acceptable could be a function of your payment processor, not
the merchant. That is, merchants wouldn't have to keep track of who is
trustworthy and who isn't.

2. Create some sort of new clearing network that deals in fiat money,
tied in w/ their local governments, where each payment processor can do
instantaneous clearing. Some organization, like FinCEN or US Fed could
license payment processors to function across this network and thus
their digital signatures on the digital receipts could be trusted by
merchants.

3. Create a system where the merchant could check the digital receipt
and their account to ensure that payment was made to the account. This
would require instantaneous clearing, but that's possible given that we
build the technology (nothing new would need to be invented, but it
would take time to standardize such a thing).

4. Create a trust-metric that enables merchants to calculate the
trustworthiness of a particular payment processor based on how other
payment processors rate them. There is a big bootstrapping problem here,
of course, so then the question is "how do you bootstrap such a system?"

The ultimate question is how do we create a system of digital signatures
on receipts that merchants can trust w/o falling back to a centralized
database like we have for the Certificate Authority system, or to a
mega-providers always win scenario?

The various approaches above have benefits and drawbacks, and we don't
have a clear solution that's been proposed.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Sunday, 17 August 2014 03:21:53 UTC