payment protocols

I have payment protocols for the open web on the brain and ran across a protocol based on texting: Paypal’s Text To Give system.

Text the donation code to the number shown. We’ll call or text you back to confirm the donation.

Here’s another one, this time specialized for tickets: txt2buy.

To buy a ticket; txt the event name to 60300 and you will receive a txt confirming the details and cost of the ticket.

You must reply to this txt with your 3 digit security code (the last 3 digits on the back of your registered debit/credit card) to pay for the ticket(s).

We then send you an entrance code by txt and email. Show your txt at the door and jump the queue.

6 thoughts on “payment protocols

  1. For compact payment ‘protocols’ also see:
    TipJoy: Twitter Startup Fails Despite Major Blessings

    It should be recognised that the mobile phone platform does have a significant advantage compared to the web/Internet of anonymous devices.

    However, I think payment is over-simplified when it is posed as the problem: “How can A transfer funds of $X to B?”.

    I suspect that the more sophisticated problem of “How can A and B express a public record of their agreement to make the equitable exchange Xa for Yb?” might be more tractable.

    The first is concerned with manipulating external funds via browser/website/paypal. The second is concerned with establishing for the public record that A and B agreed to make an exchange, probably monetary.

  2. How come the public record is the key part, Crosbie? Is it that the payment is backed by the credit record of the purchaser?

  3. I think the overall problem statement is how a web-scale system can enable the ordering, payment, and fulfillment process to be just as easy as in the Apple store.

    1) Hit purchase button from anywhere.
    2) Answer a confirmation question (“Are you sure?”).
    3) Download and installation runs itself from here out.

  4. If two people can create a persistent public record of their demonstrably authentic exchange agreement then it may be good enough to serve as an interim financial transaction in place of an actual funds transfer between bank accounts – the balancing funds transfer occurring at a later date (similarly published).

    A bit like a publicly visible cheque. Collect ’em all up and then publish a balancing cheque.

    If the cheques are good enough who needs to waste time transferring funds all the time?

  5. Lucas, I think your problem statement is right on. But I think the “web” answer is more in the client / user agent than in the cloud.

    Generally, payment mechanism on the web rely on someone being registered with a service, and then authenticated for each transaction.

    That service handles a bunch of stuff that has to do with banking, and so is designed fundamentally as a node in the bank network rather than as a node on the WWW.

    I don’t think that can be moved to the web in an open way. But, it’s possible to make that whole experience much more streamlined.

    For example, someone who has a Google Checkout account can easily buy anything sold via Google Checkout. Same with PayPal and Amazon.

    And, same with iTunes.

    (And, on the other side: same with sellers, albeit with different restrictions about who can sell what / where through each service.)

    And, that layer of web-to-banking service, theoretically, can be built on. And, I think it’d be most direct to work at the browser level, e.g. smart user agents.

    In this case, an online seller would present, via a data format, a manifest of acceptable payment services, behind the scenes to the user experience. The buyer’s user agent (say, web browser) would then, behind the scenes and without hassle to the end-user, select the user’s preferred payment method and present the user with the minimal confirmation steps necessary to complete the transaction through that mechanism.

    This could be akin to how Firefox handles subscription to RSS feeds, allowing the user to have a preset feed reader application that is invoked automatically when the user clicks a “subscribe to RSS” link.

    However, in the case of online financial transactions, the user agent would want to allow for many services or protocols, and let the user define which is preferred for which types of transactions.

    So, it’s “web” in the sense that it’s web browsers working directly banking APIs.

    What do you think?

Leave a Reply

Your email address will not be published. Required fields are marked *