W3C home > Mailing lists > Public > public-webpayments@w3.org > March 2012

Re: New specs: Web Payments, Web Commerce and Payment Intents

From: Andrew Durham <info@andrewdurham.com>
Date: Sat, 10 Mar 2012 11:10:59 +0000
Message-ID: <CAP5m0mSVF1FyDV+J50AxQy-6Zn996u5oy4G2P+xh5zS9PNyiRQ@mail.gmail.com>
To: public-webpayments@w3.org, Manu Sporny <msporny@digitalbazaar.com>
Hi, Manu,

I read the specification draft for Payment Intents
http://payswarm.com/specs/source/payment-intents/
to see how it would work with Cooperative Dominant Assurance Contracts (CDAC)
http://lists.w3.org/Archives/Public/public-webpayments/2012Feb/0048.html
Now my assumption seems incorrect that CDAC could simply be tacked on
to the existing algorithm. I look forward to seeing the slight changes
you said the algorithm would need to accommodate CDAC. In the
meantime. I'll keep studying it.

And, I came across what I think are three other issues in the code,
one of them major.

Terminology
Since this kind of contract is called an Assurance Contract, I suggest
including that term somewhere in the spec, maybe in the Abstract or
Introduction. "Parameterized payment" seems to be a significantly
broader idea.

Bad Links
You mentioned some links broke when you modularized the specs. The
links are definitely bad for "The Purchase Algorithm" in point 2 and
"Decentralized Settlement Algorithm" in point 8. There may be others;
I did not check.

Insufficient Funds
I see a grave issue with the algorithm in terms of how crowdfunding
campaigns run. A campaign could be publicly successful and yet its
promisor could still go unpaid if there are insufficient funds in the
promisee's accounts.

For example, let's say a promisor's campaign goal is $1000. At the
deadline, exactly that amount has been raised. The campaign succeeds,
but only just.

By then one of the early promisees has spent all the money in his web
payment account and forgotten about his promise to the campaign. When
the web payment algorithm finds this out, the total amount available
to be transferred to the promisor is less than com:minimumAmount.

In the algorithm, there is no indication of what happens then. Is the
contract voided? Does the promisor receive nothing? It seems like it,
and that is bad. The campaign has already declared its success but the
money remains untransferred. How is a promisor going to reopen a
campaign that has closed and lost people's attention? Or, if it gets
more money somehow, how will appropriate sequences in the algorithm be
restarted? It sounds like a mess.

I just read Kickstarter's policy. Amazon Payments handles
Kickstarter's assurance contracts. If a backer's credit card is
declined to Amazon, a backer is given seven days to rectify the
situation or the backer is cut from the list of those receiving
rewards. But the promisor still gets the rest of the money available.

I think that if the ps:PaymentIntents equal the com:minimumAmount by
the deadline, then all the promisee's accounts should be debited and
the promisor should get whatever is available, as at Kickstarter. Not
sure how to do that in the spec, but that's the logic, and it also
seems like it would much simplify the algorithm.

This scenario is a very small likelihood. Most projects that succeed
get more than enough to prevent this problem. But it is bound to
happen.

The only danger to the promisor in this case is that he won't get
enough to complete his project or fulfill his obligation to the rest
of the promisees. So I can think of four remedies:

1. The crowdfunding site could guarantee successful projects against
this contingency out of an account funded by the percentage it takes
of successful projects
2. Crowdfunding sites could recommend to promisors to add a certain
amount to their goal in case this happens based on internal failure
statitistics and in case it would be fatal to the project. It is
probably very small amount of cases and a small percentage increase
that is required.
3. You could allow for a second class of promisees called guarantors
whose accounts would only be debited if the first class failed to meet
the com:minimumAmount. They would be like fairy godmothers of the
crowdfunding world, only called upon when really needed.
4. Not sure, but PayPal's approach seems different than Amazon's, and
web payments could follow it. A promisee is actually charged at the
moment of promising. Only when funds are paid is the amount added to
the project's "total collected amount. If funds are insufficient, then
a promisee has time to add them. No one gets misled. If the project
fails, the money is refunded.

Oh, btw, I was looking forward to the conference call but could not
make it due to illness. I look forward to the next one.

Cheers,
Andrew

independent investigator in philosophy, health, & design
http://andrewdurham.com  the darkness conjecture
541.210.8470 vm
Received on Saturday, 10 March 2012 11:11:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:20 UTC