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:
- 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
- Reset (amount, date, comments)
- Rejected (This is not necessarily an error state where reputation causes payment rejection)
- Error (section IV)
- 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.
- 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.