The False Promise of Frictionless Commerce

by Russ Jones on January 15, 2003

in Russ Jones, Writings

By Russ Jones

Micropayments—those pay-per-click, penny-level transactions—are
back in the news. Red Herring magazine recently published an article (1)
entitled "Micropayment’s Big Potential" that paints a pretty
rosy picture about several up and coming micropayment systems.

At first blush, this makes all the sense in the world. Online advertising—frequently
positioned (2) as the traditional alternative to micropayments—has
been a bit down on its luck lately, as micropayment advocates have long
predicted would happen. And demand from digital content providers grows
every month. Now, more than ever, the market for frictionless commerce
seems ripe.

But to say we’re skeptical about micropayments would be an understatement.
While there is plenty of interest in the industry to see micropayments
succeed, most schemes seem obsessed with per transaction cost. While transaction
costs do contribute to the friction, it is only part of the total friction
that must be overcome in order to move a payment from a real world buyer
to a real world seller.

This is not unlike the challenge of developing fuel-efficient cars. You
could design a more efficient engine. But unless you also figure out how
to reduce the weight of the car and radically rethink aerodynamic drag,
improvements in engine efficiency will be marginalized by the continued
cost imposed by other components.

The same is true in micropayments; advances in transaction efficiency
are not enough to financially compensate for the ongoing cost of customer
support, the inevitable cost of dispute resolution, and—most importantly—the
real-world cost of moving funds through the system.

Micropayments in Context

General-purpose payment systems have always been capable, on the surface,
of handling low-value transactions. I can use my credit card to pay for
a small cup of coffee at Starbucks and no one bats an eye. With Kinkos
ExpressPay, I can use my credit card to pay for a single $0.08 photocopy.
You could send me a penny through PayPal right now.

While these systems are not optimized for small payments, they certainly
support them—as long as there are not too many of them. As micropayment
proponents would point out, with general-purpose transaction costs higher
than low-value transaction revenue they can’t afford to be in the business
on a sustained basis.

True micropayment systems are optimized for low-value transactions. To
reach lower operating thresholds, they cut corners in various ways. Almost
all amortize the fixed cost of funds over many merchants by acting as
a payment network for consumers. Some don’t verify that each transaction
actually completes. Many don’t provide non-repudiation. You get the idea.
The argument, which we believe, is that when operating at coin-level transaction
values, some of the requirements of general-purpose payment systems can
be ignored.

This isn’t to say that micropayment systems are simpler to develop than
general-purpose payment systems. While optimizing for low-value transactions
allows developers to cut certain corners, the challenges associated with
buying and selling digital content introduce new problems.

For example, the flakiness of the Internet as a delivery channel means
that micropayment systems must be able to replay online purchases without
forcing the user to pay twice. The fact that consumers can arbitrarily
click "stop" or "refresh" on their browser during
content purchase further complicates things. This forces micropayment
systems developers to integrate payments with delivery.

For merchants, the most important features of any micropayment system
are URL pricing and protection. URL pricing lets merchants, for example,
set the price of a specific MP3 song. URL protection assures merchants
that the MP3 song can’t be downloaded without somebody paying first. Merchants
don’t want to sell the URL to a MP3 file, only to have an unprotected
download URL freely passed the Internet. (3) Furthermore,
with transaction values so low, digital content providers cannot afford
to be involved in disputes or manual refunds; all processing of purchase
refunds has to be automated.

These are not unsolvable problems. Early micropayment systems solved
these problems and the next generation systems will have to as well.

What About Peppercorn?

Triggering this renewed interest in micropayments—and featured prominently
in the Red Herring article—is a proposed new micropayment system
called Peppercorn. (4) Conceptualized by Ron Rivest,
co-founder of RSA Security and a professor at MIT, Peppercorn uses probabilistic
sampling to reduce by a factor of 1000 the number transactions that must
be processed by a third party payment processor or financial institution.

How it would actually work, for our purposes here, is immaterial. We’ll
accept—for now—that the proposed architecture dramatically reduces
the infrastructure cost for any party that operates the system. The challenge
for the Peppercoin developers (5) will be to provide
all of the other micropayment functionality along with the operational
environment that mitigates as much of the friction as possible.

So, Where’s the Friction?

Even when system operational costs are significantly reduced, there is
still plenty of friction in micropayment systems. The friction comes from
the real world costs associated with getting funds from users, settling
funds with merchants, and providing customer support to both.

  • Costs of Funds and Settlement. While many micropayment systems
    are, correctly in our opinion, agnostic about how money moves in to
    and out of the system, all have to rely on real world payment systems
    to do so. Which ones and in what combination vary country to country,
    which indicates to us the importance of flexibility. Funding costs include
    the cost to move funds into the system via credit cards and ACH transactions
    (6) , as well as and prudent fraud detection costs
    as required to minimize fraud losses. Settlement costs typically include
    the cost of periodic ACH settlement or the costs of issuing physical
  • Customer Support. While micropayment systems often automate
    much of the merchant refund processing, dispute resolution is often
    still required. Because the micropayment provider plays the same role
    as a merchant, relative to the consumer, the customer support burden
    is very similar. PayPal, for example, while not a micropayment provider,
    reports that it spends $0.35 per user per month on customer support-an
    expense that appears to be independent of the number of transactions.
  • Losses from Fraud. Fraud losses are entirely associated with
    the cost of funds and include losses from fraud, chargebacks by consumers
    if applicable, and any associated penalties. The good news about fraud
    is that it is really a new user phenomenon and typically not a problem
    with ongoing month-to-month users.

While many micropayment systems substantially reduce the infrastructure
cost, they all must bear the cost of funds and settlement, fraud losses,
and customer support overhead. Peppercorn is no different. When coupled
with marketing costs, product development costs, and G&A overhead,
it’s no wonder that micropayment providers often charge transaction fees
of 15-30% on small value transactions.

While outrageous on the surface, it’s important to remember that micropayments
are all about soft goods. Since the production costs are sunk up front,
there is no incremental cost for content providers, as for software developers,
to deliver one more download.

The Micropayment Paradox

There are two fundamental challenges in micropayments that we call the
market adoption paradox and the competitive advantage paradox.
Both are equally real and equally frustrating:

  • Market adoption paradox. New micropayment systems, like other
    payment systems, suffer from the well-known chick and egg problem—no
    buyers because there are no sellers and no sellers because there are
    no buyers. Two-party adoption is a tough problem. As if the two-party
    adoption problem isn’t hard enough by itself, some micropayment providers
    have actually gone to market with a three-party adoption model—consumers,
    digital content providers, and financial intermediaries. Which came
    first, the chicken, the egg, or the chicken farmer?
  • Competitive advantage paradox. Micropayment systems, like Peppercorn,
    that stress transaction efficiency as their biggest competitive advantage
    have another problem to overcome. Payment systems designed for efficiency
    are only really efficient at scale. First and second year transaction
    processing costs are so small that differences in cost efficiency between
    competing approaches is completely masked. In other words, a single
    system with a T1 connection is as much overkill for a poorly conceived
    micropayment scheme, as it is for an insanely great micropayment scheme.
    It’s only at scale that these things matter. And, consumer convenience
    and ease of use are far, far more important to reach scale than transaction

Taken together, in our opinion, it is difficult to come to market as
a micropayment provider that must (1) simultaneously woo both consumers
and digital content providers needed to (2) achieve early adoption traction
before (3) someday achieving scale in order to (4) exploit a transaction
cost advantage that is critical for (5) being financially viable. There
are just too many inter-dependencies in this business model.

But all is not lost; the underlying technology and intellectual property
in many micropayment systems is quite valuable and could be leveraged
in a number of ways.

Overcoming Market Adoption Hurdles

We see several ways that technology vendors could overcome adoption hurdles.
One approach that might work for Peppercorn and others is to give up on
the many-to-many problem inherent in payment networks. Rather than pitching
a micropayment service to consumers as an easy way to pay multiple content
providers, technology providers could focus instead on the unique problems
of a single digital content provider.

It’s not as glamorous as the original vision—let’s take a little
bite of every transaction on the Internet between every consumer and every
content provider—but it directly addresses the near-term customer
pain and provides clear entrée into the market. While some content
providers are looking for pay-per-click functionality, nearly all want
an easy way to flexibly provide subscriptions. Payment interoperability
between merchants could come later when the market requires it. Solve
the problem of the chickens now and let the chickens worry about the eggs

A second approach would be for technology vendors to look beyond subscriptions
to service metering. Instead of working to monetize value-added content,
they could think instead of monetizing value-added services. The Web services
community is just now starting to explore the business models needed to
support commercial Web services. Metering these Web services will be a
big opportunity for somebody. Aggressive micropayment providers need to
start exploring this opportunity soon or risk traditional ISP and telco
billing vendors moving in to solve what is essentially a high-volume,
low-value transaction problem.


Moving real money from buyers to sellers over the Internet has inherent
friction. While breakthroughs in transaction processing cost are important,
they are marginalized by the ongoing cost of funds, customer support,
and losses from fraud. Regardless of end-to-end transaction cost, the
key challenge in micropayment is multi-party market adoption. It’s a very
hard problem.

While interest in pay-per-click is growing, there is stronger demand
short-term for subscription solutions. And if adoption of Web services
is as robust as predicted, there will be good potential in service metering.


  1. "Micropayment’s Big Potential",Red Herring
  2. "The Case for Micropayments", Jakob Nielsen,
  3. As a point of clarification, this problem is more
    fundamental than digital rights management (DRM). We are not suggesting
    or advocating that DRM technology is part of the solution.
  4. See:
  5. In a bit of confusion, “peppercorn” the scheme is being productized by “peppercoin” the company.
  6. Attempts to mitigate real world payment cost via
    aggregation have their own soft white underbelly. Post-purchase billing
    risks insufficient usage prior to reaching economical billing thresholds;
    prepayments create liquidity issues for buyers.

Publication History

Initial Publication Date: January 15, 2003

Comments are closed.

Previous post:

Next post:

Clicky Web Analytics