Comments: What is FC (iv) - The Payment is the Message

Now all you need is a huge client who will bully their suppliers into using your system - see

Posted by Darren at March 4, 2005 04:53 AM

I disagree with the comment about EDI - it was and still is widely deployed and mostly using X25 et al in the supply chain.

EDI is entirely message based and can even integrate with faxes on the edge of the network, plus do payments if the agreements are in place. I agree it is not very adhoc :-)

Posted by fm at March 4, 2005 11:36 AM

It sounds like a cool program, you ought to release a free version for non-commercial use. What kind of payments does it use? Anything that end users could reasonably get access to?

I don't see why you had to use datagrams just because you are sending a stream of unsolicited messages to the client. Is this some hack to get through firewalls?

Posted by Cypherpunk at March 4, 2005 03:28 PM

What kind of non-commercial use could a payment system have? I have always wondered what "free for non-commercial use" means for other software, but I would imagine that a payment system is something that by definition is used for commerce :)

Posted by dash at March 7, 2005 05:36 PM

Commerce is about trading for profit, one supposes. Trading for other reasons is also good fun; we are using the payment system to coordinate artists and production of art. Some of the contracts are making a name for themselves as art, and some value is moving around simply to better account for the favour economy.

Pretty much all the client side software is open over at (I have to push out a new release including the messaging component.) The issuance server software is not open, but is gradually migrating to more open. As and when I get around to it, I'll add issuance capability into the client-side, that seems to be a more robust model than server-side issuance.

Posted by Iang at March 8, 2005 10:34 AM

Obviously any system that makes payments needs to have bills and invoices, obviously any system that makes bills and invoices needs to have messaging. Though obvious, it is seldom done.

But instant messaging is real time and by default does not generate a readily filed record, while bills and invoices are frequently batch mode, and must correspond to fileable records - which is more like mail than instant messaging. And, of course, if a system for making payments works somewhat like mail, then it must have phishing resistance, which means it must have some kind of logon and password management that provides mutual authentication, like SRP or augmented PDM. And, of course, a system for making payments should be capable of being readily linked to a system for managing reputations, which is more like usenet news than email.

So though linking instant messaging to payments is a step in almost the right direction, I think it is a step in not-quite-the-right direction.

Posted by James A. Donald at March 13, 2005 11:01 PM


yes, this is why I suspect there is more mileage in picking a payment system and adding IM than the other way around.


The system I wrote it in is our old favourite: WebFunds/SOX/Ricardo/SDP1. The program is downloaded from the site. It isn't exactly ready yet, as I haven't had time in the last month to do a new distro, also the distro is a very primitive zip file. Still, aside from those planet sized nits, it works ;)

Posted by Iang at March 14, 2005 06:28 PM
Post a comment

Remember personal info?

Hit Preview to see your comment.
MT::App::Comments=HASH(0x17ebe50) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/ line 125.