Loading ...
Sorry, an error occurred while loading the content.

Re: [decentralization] Pricing and micropayments

Expand Messages
  • Rahul Dave
    Sarcasm aside, sooner or later, somebody has to pay. A lot of information is out there, free, and such information about concepts, products, etc gains value
    Message 1 of 43 , Nov 30, 2000
    • 0 Attachment
      Sarcasm aside, sooner or later, somebody has to pay.

      A lot of information
      is out there, free, and such information about concepts, products, etc gains
      value from being cross linked and freely available.

      The same is not true for web services, even though most of these are also
      free today. Why should I not have to pay for maps.yahoo, or an online calendar,
      or web email? Given the way online things have worked, its probably hard
      to now set up a charge for the basic functionality, but advanced commands
      could be grouped together and charged for.
      (and perhaps basic functionalities would have never taken off without being
      free.)

      The basic consequence of today's system, is that revenue is a function of brand.
      And their being no barriers to entry in the market, unless you were early like
      Amazon, or the first in a market, or have a portal agreement, you are toast.
      Online advertising dosent build brand, and too many players fractionate the
      space, making it hard to establish brand, unless you kill yourself first
      with an expensive marketing campaign.

      So what does this have to do with ISP's? If not ISP's, what are MSN and AOL
      (ok AOL is a proxy and name service too, but lets ignore that)? If web services
      were to be provided by ISP's, either through explicit signup, or giving
      the user a choice between two services with the same interface, this would
      provide the only hope for a lot of these services making revenue without
      marketing themselves hoarse. The ISP could charge $30 for basic 56K +
      web email+calendar+blog+whatever else ..and the user could have a choice between
      2 calendar providers, bla bla. For each aditional service, there would be
      a $2/month charge, for each additional command bundle, on a per bundle basis.

      All the ISP has to do is to act as a collecting payment, and authentication
      agent. The whole portal
      interface can be created at the browser directly or through RSS. Its not
      rocket science.

      Otherwise you might as well get out of the way and let the big portals, AOL's
      etc be the web..I even wonder how many small ISP's remain today...with no
      way to charge us for services provided, I also wonder how long will many
      services remain. Sure enough, demand will be fullfilled, but will we once
      again loose choce as we did woth operating systems and browsers.

      Rahul

      I got this from you:
      >
      > >
      > > I think for the system to work, it would have to be
      > > tied into the user's ISP bill. Works like:
      > >
      > > 1.User clicks on a link
      > >
      > > 2.Popup says "You will be charged $0.15 to access this
      > > site for one month, starting today"
      > >
      > > 3.User agrees
      > >
      > > 4.Charge is added to his ISP bill (ISP receives some
      > > sort of payment for hosting the charge)
      > >
      > > 5.If applicable, email reminder sent 3 days before
      > > access is lost to remind user to renew
      > >
      >
      > So then if a user wants to access a new service that the ISP doesn't have a
      > deal with, they need to:
      >
      > a) Send an email to the ISP
      > b) Wait a couple of days
      > c) Send another email
      > d) Recieve a reply that says "No, there is no demand for that service from
      > our users"
      > e) Start a petition to get it added
      > f) Find out the ISP is owned by a company which has an exclusive content
      > deal with another content company
      > g) Change ISPs
      > h) Finally get access to the service, only to have it go bust a week later
      > because of lack of take up from ISPs.
      > i) Realise that the content has been copied and is available for free on
      > GnuTella, anyway.
      >
      > <sarcasm>
      > Sounds like a good idea to me! I guess it might work on AOL, though. (Great
      > idea number 1 for today: Lets turn the internet into AOL!)
      > </sarcasm>
      >
      > Nick
      >
      >
      > To unsubscribe from this group, send an email to:
      > decentralization-unsubscribe@egroups.com
      >
      >
      >
    • Todd Boyle
      ... Gasp! This is a classic hardwired payment scheme. I suggest instead that the user should have some abstraction layer between himself and any settlement
      Message 43 of 43 , Dec 11, 2000
      • 0 Attachment
        > I think for the system to work, it would have to be
        > tied into the user's ISP bill. Works like:
        >
        > 1.User clicks on a link
        >
        > 2.Popup says "You will be charged $0.15 to access this
        > site for one month, starting today"
        >
        > 3.User agrees
        >
        > 4.Charge is added to his ISP bill (ISP receives some
        > sort of payment for hosting the charge) ...

        Gasp! This is a classic hardwired payment scheme. I suggest instead
        that the user should have some abstraction layer between himself and
        any settlement agent. Nobody is so stupid they will buy into some new
        network scheme that is hardwired to any particular settlement bank.
        Here is how intercompany settlement works.

        2. popup asks for 15 cents to be sent to an email address.
        3. user clicks ok and a javascript runs creating an email message.
        4. user clicks a stupid little icon on the bottom of the window that
        writes an XML journal entry into the message which says,
        "debit expense 15c, credit accounts payable 15c" and sends it
        to the seller.
        5. the icon posts my GL with an AP Seller. Now another transaction
        is sent to my settlement agent, which could just as easily be
        a kid down the block or Citibank. The key is, I have a choice:
        " debit the seller 15cents credit my deposit account 15 cents "
        (I am stating this in my debit/credit context not the banks.)

        6. It's posted by my GL and the settlement agents' GL. The settlement
        agent dutifully gives credit to the Seller's account if he's using
        the same settlement agent. Otherwise the settlement agent posts
        it to a mutual settlement agent indicated in that original URI. Or
        as a last resort, sends it off as a real bank transfer.

        7. The seller's settlement agent eventually gets the same kind of
        journal entry "credit seller debit settlement agent" and it then
        flows to the seller, "credit buyer debit your deposit account".
        He flows the entry into his accounting system. Or most likely,
        the "Seller" is a webstorefront operator and it flows the same
        accounting entry downstream to the owner of the website's acctg.
        system.

        8. the website understands it has gotten the money so it
        gives you the goods.

        9. Over time, the DNA arranges itself to avoid the punitive round
        trips to banks. Reputation mechanisms and insurers etc. etc.

        This is a thumbnail sketch of how intercompany journal entries work
        in large corporations. What you are doing is a balance sheet transfer
        of value. It sounds complicated but it is a snap. Anyway this
        would all be shielded from the user. Note I am *not* addressing
        security--a separate matter that drops out of the equation regardless
        of the mechanism of payment. What I am addressing is the crippling
        inconvenience of banks, and the slaughterhouse of fees when you
        round-trip money in/out of banks. These are what killed the last
        generation of cyber cash companies.

        Remember, a bank is nothing but a GL. Well, a crippled little
        excuse for a GL, having no interfaces and only one account, and
        a shredder to strip away any XML or data integration at the front
        door. :-(

        If they weren't a protected monopoly, banks would have been laughed
        out of the market long ago.

        Intercompany journal entries works in any agent, device, router,
        software, cellphone, Quickbooks, Peachtree, and every accounting
        or ERP or ecommerce system ever devised, they're all ready to
        rock n roll with double entry accounting. (in the background I hope!)
        Why are we screwin' around with banks? Beats me.

        Lucas said,

        > The failure of micropayments on the web was due, IMHO, to credit cards
        > being workable. There was an easy evolutionary path that reduced the
        > need for new infrastructure. We can't use credit cards with P2P in
        > the exact same way as with the web, because getting paid would require
        > users to open merchant accounts. But so what? You cash in and out
        > with denominations that make sense on a credit card, and in the
        > meantime transactions are aggregated at PayPal, or your ISP, or
        > whoever holds the merchant account.

        Noooo. You leave the money in the bank, and create information
        systems that point to it, just like traditional money pointed to
        gold. Forget the credit cards and Paypal which are just another
        facade for the banks. They kill your economics because they break
        everybody's automation by stripping away data, and, loading the
        gol darn fsCKing fees on every dang thing you try to do. They are
        network killers.

        Just leave your money in the bank and pledge it to some escrow or
        settlement agent. Nobody has any risk or extends any loans or credit.
        Systems will emerge that adjust for interest and all that.

        Clay Shirky said,

        > By this logic, PayPal should be micropayment central. We have all the
        > infrastructure we need, we just don't have any demand

        Wrong. Paypal cannot be micropayment central because it's part of a
        bank and doesn't want to compete with banks. Furthermore it's all
        by itself with no data interface yet. The Quickbooks webledger is
        integrating with Paypal so you will expect, it will begin handling
        smaller and smaller payments efficiently, steered thru the webledger
        users' interface. But guess what: Intuit and the Banks have no
        intention of doing anything stupid that destroys anybody's pricing
        structure. So you already know what will be the result.

        Clay said,

        > Watch Deutsch Telecom and Nokia. Both are making huge plays in the
        > "You don't need a credit card, you can just bill it back to your phone
        > bill" plays.

        Yes. They are also working on MeT. Some companies are pressing them
        to implement OMG GL in the phones; here is a little snack,
        http://www.cellular.co.za/met.htm


        Oliver Willis said,
        > hmmm
        >
        > hey, anyone out there want to turn (ISP settlement) into a real
        > business? :)
        >

        Oliver--it's already out there, http://www.ipin.com/ tried it
        and moved on. http://www.trivnet.com/ does it and they're moving
        on, too. There is a whole longrunning Internet Billing list on
        http://www.isp-lists.isp-planet.com/isp-ecommerce/9910/msg00150.html
        which has been a very tedious and depressing list, the last
        couple of years,

        Todd
        Note: this is not legal advice. This is an internet discussion forum.
      Your message has been successfully submitted and would be delivered to recipients shortly.