Re: Micropayments: myth?

["Vladimir Z. Nuri" <vznuri@netcom.com>]

>
>> the wallet action will always
>> be tied with some other action. the user picks up the phone to dial
>> somewhere, and it says, "that will be .3c-- will you pay"? he says
>> yes. 
>
> How will you know the cost is .3c a priori?
>What's to stop me from saying yes to the .3c and staying on the line
>forever?

I don't understand why this micropayment thing is being thought
so complicated.

I am making some simple assumptions that seem to not be obviously
apparent, apparently.

I don't think micropayments make sense in transactions in which
the buyer requires the ability to back out of a purchase. in
other words, if I download an FTP file, pay 2c, and then say,
"this isn't what I wanted", I don't think a refund is typically going
to be supported. it would be up to individual vendors, but I doubt
very many would allow it.

a service [x] knows how much they are going to charge for a file
or a http transfer. they tell the user, "you can have this for
[x] cost". the user *sends* them the money to get the data.
there is no concept of the company going into their wallet and
pulling out the cash. the buyer sends the token and initiates the
entire transaction. I am not saying this micropayment thing is
going to be the only way future transactions will work. of course
not. it's just one way that makes some assumptions.

what about services that don't deliver? I would imagine a cyberspatial
equivalent of the BBB will be just fine for that. an agency that
registers complaints. a company doing a micropayment bilk scheme
could only get away with a small amount of cash before they got
a bad reputation. the reputation could be checked by the browser
prior to paying, that kind of thing.

the example I gave of a phone service billing people for phone calls
was not a great example for micropayments, but it could be pulled
off. imagine that your phone has a little readout that tells you
how much you are being charged. you can cancel the call. you can
watch your little readout as it bills you money. you could set
limits, "do not pay more than 10c/minute". these limits are built
into your *local* wallet (browser, phone) etc.-- they are not
handled by the company that is charging you. hence you retain
full control.

  If you disallow that, how?  Will it cost the same amount if
>I'm not sending anything as it will if I'm sending a live video + audio
>feed?  If so, what's to stop me from bundling my whole neighborhood's
>Internet traffic into this call?  If not, how will you tell the
>difference without monitoring my usage and requiring me to pay for the
>additional bandwidth I use?

MICROPAYMENTS. they are for small transactions. the standard billing
model will be used in other situations as it is today, although it
will be moved into a cyberspatial equivalent. micropayments are NOT
going to be the only way the future economy will work. I think some
people seem to have some misconceptions about this. it won't make
sense to use microcurrency everywhere. I don't know if micropayments
will ever be tied to each pack like you are proposing. at least
in the beginning, I would assume a structure like the internet is
today with a micropayment charges built on top of it like I suggested
with browsers or that kind of thing.

companies will probably charge for bandwidth if they are charging for
network services. you can't send a lot of data without using more
bandwidth.