Great example of GUI for OpenTransact

37 views
Skip to first unread message

Pelle Braendgaard

unread,
Apr 23, 2012, 10:40:03 AM4/23/12
to opentr...@googlegroups.com
http://www.baekdal.com/insights/we-need-to-drastically-simplify-payments-online/

Thomas Baekdal mocks up the flow for what payments should look like in the future.

This is basically the OpenTransact TransferAuthorization.

P

--
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking

Walter Stanish

unread,
Apr 23, 2012, 9:26:57 PM4/23/12
to opentr...@googlegroups.com
> http://www.baekdal.com/insights/we-need-to-drastically-simplify-payments-online/
>
> Thomas Baekdal mocks up the flow for what payments should look like in the
> future.
>
> This is basically the OpenTransact TransferAuthorization.

I sincerely hope not.

IMHO this self-styled 'insight' is a first-financial-worldview fantasy
promoting little in the way of (immediate or potential) innovation,
continued lock-in to the established centralized payment providers
(who are not really global, despite the author's claims), significant
privacy issues (who wants a payment company tracking their browsing
via iframes?), increased potential for compromised client based fraud
(despite the author's claims), and very little in the way of
consideration for mobile, digital currency, third party, complex
localized fee/shipping/taxation, or many other edge cases that are
critically important in a mature payment system.

Regards,
Walter Stanish
The IFEX Project
http://ifex-project.org/

David Nicol

unread,
May 1, 2012, 11:24:45 PM5/1/12
to opentr...@googlegroups.com

On Mon, Apr 23, 2012 at 8:26 PM, Walter Stanish <wal...@ifex-project.org> wrote:
>> http://www.baekdal.com/insights/we-need-to-drastically-simplify-payments-online/
>>
>> Thomas Baekdal mocks up the flow for what payments should look like in the
>> future.
>>
>> This is basically the OpenTransact TransferAuthorization.
>
> I sincerely hope not.

Hmm. I stopped reading about a third of the way down, according to the scrollbar. Having invented and deployed a one-click payment system back in the day, it's validating to see the specifications for it described. And I also know the answer to this question, which isn't really rhetorical:

Why is it that we accept this? Why is it that, after twenty years, this is still the way to pay for things online? No wonder it is hard to make money online. Imagine if you had to do this in every physical shop.

It is sales 101. Never put complicated steps between the customer and the sale.

The answer is, purchase decisions are not made based on the convenience of the payment framework. That answer comes from an article in e-Week or similar, I have no idea how long ago.

Tipjar was trying to promote one-click purchases in 1996, that worked essentially like the buttons described in that essay:

in 1997, I would have encouraged CBS to link that button to

    http://tipjar.com/cgi-bin/give?rec=CBS&amo=39.95&cur=USD&mes=download+NCIS+season+8

which goes to a page where the customer identifies themselves. Which is still there, and if you follow that you can log a transaction in the transaction queue to pay "CBS" which is not at this time a registered identity string, but the part of the system that accepts the give instructions doesn't know that.

On relaunch (pending since '98 or so, after I started using Kagi for credit card processing and got defrauded) the customer will be able to be logged in already, using cookies.



--
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" are to be interpreted using situational ethics.
Reply all
Reply to author
Forward
0 new messages