Gradual roll out of a different layers in payment/commerce standards

I don't want to be too argumentative, but I do want to talk about what I
think is the fundamental issue with comprehensive standards such as the
current draft of PaySwarm (http://payswarm.com/specs/ED/web-api/2011-09-26)
and also what can be done to improve it.

Now a basic payment is just a transfer of funds from one person/entity to
another.

There may be another side to the transaction, but there might not be one
either. In current payment systems when there is another side to the
transaction it is generally referenced in the description field and the
other part is handled by some other system, such as an invoicing system,
e-commerce site etc.

There also may not be another side to the transaction. I maybe transferring
funds from one of my accounts to another. I may be sending money to my kids.

Firstly PaySwarm uses the term *payment* to cover fully 2 sided business
exchange of funds for an asset resulting in a contract. This is a great
idea, but it is also where gaining traction might become problematic.

PayPal also allows you to cover both sides of the transaction, but
specifying what you are buying either from ebay or another shopping site.
Yet their base product is just a payment with no such information.

I want all the capabilities of PaySwarm. However due to the fact that the
vast majority of businesses or payment systems would likely not roll out the
full system due it requiring them to change fundamental systems in their
core business there will be very large problems with buy in.

However if we split this up in a stepwise implementation approach I think we
will not only become more successful as a standard but also more robust in
the long run.

By doing it stepwise it allows companies to start implementing the top part
and then step by step add support for more advanced functionality.

Core payment:

   1. Payment Request (Payment Links)
   2. Payment Processing (Perform pre authorized payments)
   3. Payment Notification - Standardize a way of notifying the parties that
   payment was successful
   4. Payment Receipt ( Similar to PaySwarm Contract but more generic)

Commerce extension:

   1. Assets
   2. Licenses
   3. Listings

These can be implemented by businesses and providers step by step. The
Payment Receipt for example could allow a link to an http page describing
the asset and terms in human readable terms rather than going all out and
implementing the full asset listing on their site.


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