… perhaps we should stick a quick definition "standard"(?) of micropayment here, before launching into yet another variation of the micropayment idea … Or do we assume everyone already has read the Wikipedia:Micropayment article?

another variation on the micropayment idea

Here's my idea for MicroPayment.

Problem: it costs more than the value of the payment to process a payment.

Solution: pay a large amount sometimes rather than a small amount all the time.

So, for instance, when I go to a website demanding a .001 payment, I don't pay every time. Instead, I pay .50 to every 500th site that I visit demanding such a payment. On average the sites make about the same amount of money as they would under the micropayment, but you save on processing fees by aggregating payments.

The obvious dilemma is: how can web sites force users to pay anything at all under this model? You check up on them stochastically. In order to view websites which require micropayments, viewers must buy a membership with a micropayment authority for a small fee ($5 or so). They also give the authority to charge a credit card in the future if they refuse to pay. They are given a permanent cookie that contains a member identifier.

Each month or so, participating sites submit (parts of) their server logs to the authority. They also submit logs of the money they were given by the users. The authority audits the logs and gets a rough estimate of the amount of hits that viewers have made to various sites. From this the authority can estimate what the viewer "should have" paid. The authority then compares that to the total amount of money that each user has contributed. If any user is found to have underpayed by a substantial amount, their credit card is charged what they owe plus a punitive fine ($10?).

There is a maximum amount that any site may charge any user per time period ($10?)

Of course, auditing every user and every log may be a substantial amount of work. Some users and some logs could be randomly chosen instead.

Problems Any participating site could cause trouble for a user by erroneously reporting hir to have visited more than they did. The trouble they can cause is limited by their per-user-per-month ceiling, however, so users don't have to be too alarmed. Obviously, the central authority audits sites who seem to report/cause more than the average number of underpayments.

Users can partially "beat the system"; if they know that only 5% of the server logs are audited, they can compute the chance of getting caught times the punitive fine and weight that against the money they save by underpaying by certain percentages (because if you don't sample all logs, most of the places that a user visited probably won't show up each month; so a user can divide their payments accordingly). They can then reduce the amount that they pay by the computed amount. However, this is not really a big problem; say it is optimal to pay 100 times less than what you should. Vendors simply charge a penny where they would previously have charged a hundreth of a cent. At that price range, you still aren't scaring off many viewers. And most people will be honest anyhow.

Users could commit blatent fraud by letting a million people use their account and then cancelling their credit card and disappearing. This will happen a lot; however, most people will be honest and will not use such systems.

At the end of the day, even with widespread fraud site operators will still make much more money than they would now. Right now, most webpages that would be priced in the micropayment range either don't exist, are provided free, or have a non-micropayment monthly fee which scares away 99% of the users who would user the service if it were cheap.


See also PepperCoin.

Interesting idea. The random checks ("Trust, but verify" – ancient Russian proverb) seem reasonable. But some people may find the randomness in the "every 500th site" a bit unsettling. Yes, the user can deterministically pay his fair share (always within $0.50 or so of the total). But it seems kind of random exactly which site will get the money on his 500th click. A particular web site isn't guaranteed to get paid every 500th viewer. In theory, it should even out, right?


micropayment bounties on Wikipedia

Do the bounties on Wikipedia ( http://en.wikipedia.org/wiki/Wikipedia:Bounty_board ) count as a sort of micropayment? Sure, it's $15 or $20 a whack, much larger than the $0.50 stuff we're talking about here … but it seems like it's going in the right direction.

micropayments in web comics

Scott McCloud? ( http://ScottMcCloud.com/ ) in Information Wants to be Cheap promotes the top 3 micropayment services, and several web comics that use micropayments.

can micropayments stop spam?

Some people suggest that requiring payment of $0.005 or so per email would have no significant effect on normal email use, but would be enough to stop spam. Wiki:SpamSolutions

will micropayments succeed or fail?

Clay Shirkey has a pretty persuasive arguments that micropayments will eventually fail.

Let's see if I can summarize the basic argument:

The fact that I don't like this dismal conclusion doesn't change the fact that it looks like a valid logical argument. But perhaps there are arguments against it, such as Micropayments and Free Content by Douwe Osinga 2003 (at Google Europe).

See also MicroCredit.



  • "The Internet is so huge, any kind of content has lots of producers." – I disagree. See VisualLanguage researchers, for example. There is no replacement for Visual:HornsVisualLanguageBook. Niel Cohn has written many things, freely available on the web, but it is fragmentary, and not as directed as Robert Horn's main book.
  • Exhaustion. If the field is relatively small, it's relatively easy to exhaust a particular source.
  • Exhaustion. A given person can only output so much. They may conceal some of what they produce (requires payment, or attendence to costly conference– the "tour" model, applied to ideas.)

That said, this doesn't necessarily mean we'll have micropayments, and, it doesn't mean that the argument isn't describing something substantial- it clearly is.

Define external redirect: McCloud

EditNearLinks: MicroCredit CategoryWebTechnology


The same page elsewhere: