My two cents on Definitions

[els]

I'm Edgar, my primary interest is in alternative/ledger-based currencies from a research perspective. I don't have any payment processor experience, but what I offer is a simple stepping off point for setting up definitions that could be used in a protocol description. These bulletpoints were taken from http://tyaga.org/docs/IPP.pdf. The interoperability is demonstrated in http://tyaga.org/mUI/index.php?img=device.png and help/scenarios (recipes in Pelle's lingo) may be accessed separately from the demo at http://tyaga.org/NPX/help.php?f=how-to#. Visit those links for examples of how I substantiate the following concepts:

I. Discoverability:

- The essence of 'web' in web payment is the use of URIs (or IRIs) to denote payment endpoints. It's not so much about payments being made using a browser, but the use of URIs. So to me, the protocol's primary scope is mostly payment processor to payment processor, or accounting system server-to-server, messaging/interaction. The basis for a uniform user experience is discussed in section III.

- At the URIs involved, there would be a machine-readable document that lists links to explain supported payment protocols or identify payment processors. The protocol defines the meta fields in that document.


II. Payment States

- Offer: should indicate type of payment processing expected

- Pending: payee will reply in a decision in a separate message

- Decided:
    - Approved
    - Reset (amount, date, comments)
    - Rejected (This is not necessarily an error state where reputation causes payment rejection)

- Error (section IV)


III. Process/Flow
- For me, a big issue is whether to default to *Push* or Pull payments. Yes, both could be supported by a protocol, but there should be a preferred mechanism. I think a push payment is inherently more secure since a payee gives authorization to be credited, rather than a payer authorizing to be debited. The details of the payer's interaction with his or her processor is kept hidden from another payment system, while the payee only has to give the payer a URI to send the payment to. From the preference for a Push or Pull payment flow, a more-or-less uniform user experience would arise.

The main stages in a transaction message flow are:

- Notification: I suggest including an accounting_method or similar field to accommodate different payment processing scenarios (e.g., real dollars versus local currency). I also suggest the use of negative amount to simplify the representation of a previously completed payment, in part or in full.

- Verification: I suggest having a verification_method or similar field in order to make the payment verification method flexible. Some payment processors might want to use OAuth, others PKI, or something even simpler for someone like me.

- Response: Depending on the results of the Verification step, the Verifier may create a new payment record, transition it to a new state, or leave the payment in its current state

- Reaction: refers to the Notifier’s action based on the Verifier’s Response


IV. Error Codes
- Specify error codes specific to the protocol; reserve code ranges for errors to be specified by as-used accounting_method or verification_method.


Other Notes:
- I do feel that recurring payments should be outside the protocol spec and could easily be handled either as part of the accounting_method or higher application layer.
- In many ways I agree with Pelle in terms of leaving a lot of things out of the protocol, going as far as not even adhering to a specific authorization/delegation pattern.
- On the other hand, like Manu I also want to consider scenarios where only one transactor has network access. I think that is an important scenario for a payment protocol to address. This is also why I think browser-based interaction is an unnecessary restriction on user experience for a web payment protocol. For example, I like example scenarios involving vending machines.

Besides the above points and links, I don't know if I have much else to offer except to answer any questions.

Thanks,
Edgar

[els]

Wording correction under III - Notification:

... I also suggest the use of negative amount to *represent the
rejection* of a previously completed payment, in part or
in full.

[Alan DeRossett]

There already many existing Standards in use, that you can code in your
favorite flavor.
Does anyone use JPOS.org or an ISO Bridge to communicate with Banks,
Credit Unions or other Debit & Credit Card companies?
We had too to process payments online.
We are also members of NACHA and NRF-ARTS.org who have a large standard
called Unified POS. The reason I ask is all of our development must
follow these standards if its to work with existing Business Point of
Sale devices,Customer Banks, ATM machines or Phones. Even China Union
Pay the largest Card Company in China is processed with ISO 8583 over
the Web inside a secured message. JPOS is an open source project that
most banks not even know they use and the Unified POS includes all the
standard terms you might need for any commerce like a "Digital Receipt"
for DRM protected Ultraviolet media downloads. If your useing your own
stored value or ledger systems then its highly regulated by Governments
and here in the US the reporting can be the most expensive part of the
transaction.

Alan DeRossett
InstaPayment

[Pelle Braendgaard]

Very interesting and a many similarities of course with OpenTransact.

I've been thinking that we are missing a "status" field as to allow something like the "approved", "rejected" etc as you mention.

About the verification methods. OAuth 2 itself right now is about Authorizing tokens and the the actual authentication is handled by various separate specs such as:

http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-15.html Which is what most people think of as OAuth 2

http://tools.ietf.org/html/ietf-oauth-v2-http-mac-00 uses HMAC signing but could easily be extended with RSA signing if need be.

I think though most providers will stick with the bearer tokens. An institution could in theory require rsa for larger values.

I do agree that the interop is important. I just think it shouldn't be a requirement. For example the idea with OpenTransact is that it can be used for many different types of assets, not just denominated in national currencies. Forcing interop in the way Manu discusses it would severely limit the scope of the standard.

I will write up the recipe shortly for this and after feedback propose an open transact-federated spec for dealing with it.

P

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

[Pelle Braendgaard]

It would be interesting if someone could come up with an OpenTransact/ISO bridge.

Obviously there would have to be some kind of mapping between public account urls and what is used with ACH.

How do you handle account mapping now? Can your customers pay using routing and account numbers?

P

[Tom Brown]

it's nice to see a constructive thread again. is there a primary motivation for producing a federated spec right now?  correct me if i'm wrong, but this seems to be related to friday's teleconference.  i listened to the teleconference and it seems it can reasonably be characterized as a series of undefined accusations against the opentransact spec.  it's "centralized", "not interoperable" and by the end "it doesn't scale". if there's no agreement on what centralized, interoperable and scalability mean, these accusations are meaningless.

at IIW, all participants are allowed to add a meeting proposal on the agenda wall.  by "the law of two feet", if you don't think the meeting is worth your time, you simply get up and leave it for another.  i'm not saying conversations about the spec should happen at IIW, but i'm saying that i prefer the process under which the opentransact spec is developing where people are allowed to vote with their feet.

cheers,
tom

[Alan DeRossett]

The Current ACH transaction system is the problem right now Banks only do Batch processing of ACH trasactions. Many of their systems are designed to produce the most possible chaos from an accounting standpoint. You may not get a reject on an ACH transaction till up to four days later. This ensures that banks are never liable and the account holder is. Rejected ACH transactions are subject to Charges on both ends by banks. A real time reject or denied response would prevent Banks from earning overdrafts. With ACH you will need a "Status" field.
The open transact /ISO bridge could be set up on a simple linux system. Jpos.org provides an in expensive comerical deployment or just download it yourself.
from jpos.org
 "In addition to XML, we can extend ISO/Bridge in order to interface with your SQL database, message oriented middleware or just setup a filesystem based message exchange."

Alan DeRossett
InstaPayment

[Alan DeRossett]

Types of Tax supported?
I was wondering if OpenTransact or Payswarm provides the VAT fiscal
device support that's required on purchases in the EU for VAT registered
traders or Vat Fiscal devices like receipt printers. The specs are part
of a POS transaction from most Unified POS systems.
Payments must be recorded for VAT and electronic Tax payments made for
each sale. I know the US is working on their own version of collecting
directly at the point of sale or ATM. Several US states have already
started to demand sales Tax be paid from each transaction online,
Amazon.com is currently being assessed.
The Streamlined Sales Tax Amnesty Program is suppose to automate the
collection from internet sales Tax for all 5400 different tax
districts. Systems will need to charge the appropriate sales tax based
on a customers location and pay immediately to the local tax authority.
An Audit trail is also required.

Vat Fiscal Receipts
http://hapatwa.com/efd.php
MS
http://msdn.microsoft.com/en-us/library/microsoft.pointofservice.fiscalprinter(v=winembedded.1002).aspx
Streamlined Sales Tax
Malta
http://www.vat.gov.mt/fiscalreceiptbooks.aspx
US State Sale Tax
http://www.streamlinedsalestax.org/

Alan DeRossett
InstaPayment

[Manu Sporny]

On 01/15/12 17:26, Alan DeRossett wrote:
> Types of Tax supported? I was wondering if OpenTransact or Payswarm
> provides the VAT fiscal device support that's required on purchases
> in the EU for VAT registered traders or Vat Fiscal devices like
> receipt printers. The specs are part of a POS transaction from most
> Unified POS systems.

PaySwarm allows you to specify a tax amount when listing an asset for sale:

http://purl.org/commerce#Tax

The tax will be gathered and applied directly to the destination account
at the time of sale by the PaySwarm Authority. This allows vendors to
automate their tax-collecting duties and pay taxes in real-time (making
end of week/month/year tax calculations unnecessary and thus reducing
operational costs).

-- manu

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Web Payments - PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/