This work is licensed under a Creative Commons License.
Thousands of people make a living on eBay, selling directly to customers. But it is much harder for writers, musicians, and other artists to sell their work online directly to their audience, without going through a large corporation. Here is a micropayment design that addresses this problem and does more besides. I developed it through accidental discovery while exploring how to sell my own writing online, in ways that encourage people share paid access with others.
The central innovation is a micropayment debit code that can make payments online -- but also can reach a Web control center (hence the name "smart code"), allowing the code's owner to create any number of new debit codes that have part of the value of the original, and may be customized with many optional features as well. These new "children" smart codes can also reproduce, through any number of generations. This simple idea has great flexibility, improved security, and endless practical uses.
Any smart-code owner can create new codes online (or by phone) for many purposes, including: paying money while greatly limiting potential losses; receiving money online; admitting friends to movies or events; creating digital gift certificates with expert assistance; sharing paid access to works of favorite artists (supporting them through giving to friends); licensing content; automatically registering for Web sites; creating instant Web sites and public announcements; reselling customized codes to specialized markets; giving library or other clients limited access to expensive databases; establishing ownership of digital art; having robots negotiate prices and make small purchases automatically; establishing trust/credibility/reputation trees; or assisting fundraising by permanently recording donations to historic causes so they can be sold to collectors. Different code-issuing organizations can provide seamless interconnectivity for users, even if they did not agree in advance on any technical standards. And the estimated cost of processing most financial transactions this way is about a tenth of a cent, regardless of the transaction amount. Most of the details are explained in this summary, others in an earlier paper (see link below).
I have no ownership interest in these ideas, and want to start a discussion to improve them and make them widely available.
Short, Secret Codes: One buys a short, random, secret code (8 alphanumeric characters is long enough for almost all uses) for any amount desired; money can also be added later through any means of payment. These codes are maintained by a code server, at a Web site run by an organization that issues the codes (the "broker").
No Logging In: This smart code is the whole account access; it replaces the account name and password, which go away since there is no "logging in" or "registration" in this system.
A Simple Transaction: In the simplest case (when the buyer and seller have the same broker), the buyer gives a secret smart code to the seller, who presents it to the broker, along with the seller's non-secret "public" code (explained below), that has no financial value but is used to make payments into an account. If the secret code has the funds, the broker deducts them and credits the public code, and sends an approval message to the seller, who then releases the document or whatever else was purchased. If the seller is not trusted, the buyer can create a new, low-value secret micropayment smart code, perhaps enough for a single session, or just for the exact amount of a purchase -- a small amount in a typical micropayment. And the broker's code server keeps a record of every transaction, so a seller who fraudulently charges buyers' codes would soon become known. The communication channels would normally be secure (as with credit-card transactions) -- although in many cases the amounts at risk are so small that secure communication might not be necessary in practice. There is no encryption in this system, except for that which is already used to provide secure communication. [Also see "Complex Transaction, Part I" and "Complex Transaction, Part II," below.]
Low Transaction Cost: The cost per transaction is extremely low -- usually comparable to the cost of an average low-bandwidth visit to a Web site, probably less than a tenth of a cent or less (estimated from the fact that a Web site can handle well over 100,000 such visitors a month while being hosted commercially for well under $100 a month). Smart codes have very low bandwidth, storage, and computer-processing requirements.
Security -- Better Than Credit Cards: Smart codes are more secure than credit cards, for several reasons -- for example, the fact that a merchant being paid by a smart code never has a legitimate reason to keep the code once the payment has been credited, eliminating the merchants' databases of credit-card numbers that are a major target of thieves (the software keeps a permanent record and provides a receipt). Also, users can create new smart codes whenever they want, for whatever value they want, limiting the loss if the code is stolen. And because these codes are random and known only to their owner and to the broker's code server, they cannot be cracked by decryption programs, no matter how much computing power is available.
Security -- No Pfishing: In the "pfishing" scam, fraudulent email pretending to be from banks or other financial institutions asks people to log in to their account through a Web link provided, and update their information -- but actually all the information they give, including their account name and password, goes to criminals, who use it to drain their accounts and steal their identity. With smart codes pfishing does not exist, as there is no account name or password, and the code's control center does not need any personal or identifying information. Code owners will need to protect valuable codes and give them only to organizations they trust; they can create low-value codes at any time and use them for micropayments to unknown merchants.
Security -- Optional PIN: An optional PIN might be used to protect a high-value code, or one encoded onto a debit card (or credit card, if the organization issuing the codes also wanted to sell credit). The advantage of a PIN is that it is remembered by the user, or otherwise kept separate from the code itself. Each code owner could choose whether the inconvenience of entering a PIN for every transaction was worth the added security for the value in that code. The option could be changed, but of course the PIN would be required in order to turn off the PIN for future transactions. If the PIN were lost or forgotten, it could not be replaced; but the "parent" code (see below) could cancel the code entirely, and retrieve any remaining value.
Other Security Advantages: The most that can be lost in case of theft is the value of the code, and the owner can control that by creating new codes with any values at any time. For example, the owner of a valuable code could use it to create a smaller one to carry around; if the new one were lost or stolen, little money would be at risk, and in any case its parent could cancel the lost code and retrieve its value. Another security plus is that codes can be restricted to particular uses; for example, a code restricted to paying for medical articles could probably not be used by thieves before its value could be taken back. Only the code owner and his or her broker would have the valuable secret code that was used to create other codes. No third party would ever have it, and a secure communication channel between the code owner and his or her broker would be essential.
Security -- Role of the Brokers: Security in this system relies on the integrity of the brokers (the code servers) that manage the databases providing the codes. But all transactions take place either within one broker who serves both buyer and seller, or with different brokers who are members of a group who have agreed to process each other's clients' transactions. A broker that could not be trusted could not remain as a member of an ethical group -- giving the average user a solid basis to trust any broker involved in their transactions, even if they have never dealt with that broker before.
How Many Codes? Eight-character alphanumeric codes (not case sensitive) allow more than a million million possibilities -- enough to have a million codes in use, with the odds against guessing any correct one being more than a million to one (or ten million codes in use, with the chance against a successful guess more than 100,000 to one). The server would recognize an attack long before 100,000 guesses had been tried. And even a very lucky guess would compromise only one code, not the whole system. For special uses, such as admission to a particular movie or show, four-character codes would allow 1,000 digital tickets, with the odds against guessing more than 1,000 to one.
Parent and Child Codes -- Ancestors and Descendents: Every smart code has its own control center (accessed through a Web site), which most customers will never need to use. But code owners can use it to create new codes, which are remembered by the server as children of the original (parent) code. These codes can have part of the value of the parent code, and can have dozens of optional customized features as well. The children are fully powered smart codes that can also reproduce -- linking the many codes issued by a server into trees of related ancestors and descendents. Many practical consequences follow; for example, if a code is lost, the parent can retrieve any remaining value -- unless the code was created as "irrevocable" (in order to sell it to third parties, for example) in which case its value cannot be taken back.
Public Codes: All smart codes discussed so far must be kept secret, because they can be used to make payments. But smart codes can also create children codes that are designed to be made public. These have no financial value, but can be used by anyone to put money into the secret code that created them, in order to pay for goods or services or to make donations. A public code also provides public information about its owner, and also about all of all of its ancestors back to the root on the code server; some of this information is not controlled by the code owner, but by the owners of ancestor codes. And because there is no limit to the number of public codes that each secret code (or each public code) can generate, different public codes can be used to keep track of different marketing campaigns, fundraising appeals, advertisements, or sales persons and teams, organized in hierarchies if desired. Of course this private information could not be reached through the public code alone, but would require the secret code that created it.
Easy Addition of New Merchants: Public codes therefore allow anyone with a smart code to become a merchant immediately and start receiving money online (the code server could require approval -- perhaps by the parent code, creating trust or credibility trees since only trusted code owners could authorize new merchants). This allows business or fundraising ideas to be checked out rapidly, without wasting setup time and overhead on the many ideas that will never work in practice. The control center for a public code even provides an instant, rudimentary merchant Web site; the new merchant or fundraiser can simply type in the information they want made public (using their secret code), and then give out a Web address that includes the public code through which payments would be entered (and which would collect usage statistics that could be either public or private). The public code will also give information about its ancestors (assuming that their owners want to provide any), so anyone can check for information about the credibility of the family tree.
All Transactions Recorded: This system makes a record of all transactions. These records can easily be saved forever and remain accessible to whomever has the code but not to others -- even after all organizations involved in the transaction are defunct, which has important practical consequences noted below. And the code server can easily summarize the transactions into reports, including total expenditures by date or amount, and total income generated through each public code.
Zero-Click Purchasing (Robot Negotiation): Smart codes can contain rules, created or approved by the buyer, that automatically negotiate on the buyer's behalf with the seller's Web site or other software. For example, a buyer might decide that spending up to ten cents a minute (for certain purposes such as access to newspaper archives) was OK, and any transaction that met this limit would happen automatically without the buyer's involvement (zero click to purchase -- although the buyer would of course have selected the content of interest). Much more complex strategies, including back-and-forth negotiation between the robots, are possible; the buyer will be asked for approval only if the robots cannot reach agreement among themselves. Such automated buying and selling strategies could be sold or leased as products. Robot negotiation may be essential for very small micropayments, since otherwise the hassle on the buyer to click each time and approve many transactions could become prohibitive.
Complex Transaction, Part I -- Buyer and Seller Using Different Brokers: The buyer and seller can be using different code servers with different code lengths and data formats, if the brokers who run the code servers agree with each other on communication protocols and payment processing. This is true because the goal is always to deliver the buyer's secret code (and purchase amount) to the buyer's code server, which uses the secret code to authorize payment from that code's remaining value. The buyer would enter a secret code into the seller's Web site, which might already have the seller's public code (or the buyer might enter this as well, for example if a public code in a newspaper advertisement offered a discount). A buyer who did not trust the seller could first create a new secret code for the exact amount of the purchase, and use it. The buyer would identify his or her broker (code server), to which the secret code would be presented for payment (the browser could automate the providing of this information). The seller's code server would then present the buyer's secret code to the buyer's code server, which would charge that code and send permission by secure communication to the seller's code server, which would then credit the seller, and release the document or whatever else was being purchased (either directly, or by telling the seller's site to do so). The brokers would have to settle accounts among themselves periodically, especially if some tended to serve buyers and others tended to serve sellers.
Complex Transaction, Part II -- International Alphabets: A transaction could also involve a different code alphabet; for example, one code might consist of four Chinese characters, which the other party could not easily enter at its keyboard. This problem of code alphabets could be solved by allowing public or secret codes to have an all-numeric alias that could be used instead of the code (or by designing the code system to use numbers only, if such international transactions are expected to be common). Another approach would be to have the seller's site compute prices in different currencies (including exchange costs -- and guaranteeing each price for a short time such as 15 minutes, in case the exchange rate changed). In this case the buyer could send the price and a secret code to his or her own broker, and get a numeric authorization code (a temporary code identifying the broker and allowing just that amount to be charged to the secret code that created the authorization code -- perhaps within a short time limit). The buyer could cut and paste the authorization code into the seller's Web form (or this process could be automated). The seller's site would submit the authorization to the buyer's broker and receive a confirmation that the charge had gone through. If the authorization code did not come back to the buyer's code server before the expiration time, it would be cancelled, and its value returned to the secret code that created it.
Saving Time on Complex Transactions While the simple transaction outline above requires only a single Internet interaction (from seller's site to the broker and back), complex transactions can require up to three (to get the authorization code, to give it to the seller's site, and for the seller's broker to get authorization from the buyer's). If the processing time required is a problem for a person waiting to read an article, for example, the time could be shortened with just a little trust. For example, a secret code owner could optionally create a special code that his or her broker would use to certify that at least a certain amount (for example, $10) remained in the account. With this assurance from the broker, the seller's site could release the purchased information as soon as the buyer entered a payment code, and then put the financial transaction through without the buyer having to wait for its completion. If the account balance went below $10, the buyer's broker would no longer provide that code to sites the buyer visited.
Easy Implementation Path: The software to implement smart codes is straightforward. (While a great may options could be provided, most of them could wait and be implemented later.) And a single organization such as a publisher or a charity could successfully use this system by itself, to start. As new code servers (new brokers) come online, they can talk to each other even if they were designed with no thought whatever to compatibility; only simple communication protocols must be agreed, and there could be several different protocols in use -- a fact discouraging monopoly control of smart codes as a means of payment. All this would be transparent to the users of the codes.
Assuring Credibility: This system makes it very easy to receive payment online, so credibility will be critical. One way to enhance it would be for trusted organizations to list others that they trust, which could list others in turn. In case of a violation of trust, higher levels of this credibility tree would either resolve the problem one way or another, or reduce their own reputations if they neglected to do so. Also, a different kind of credibility tree is provided by the codes themselves, since public codes will make available information about their ancestry all the way back to the broker that maintains the codes.
Selling Content Online: Artists, musicians, or others with online content could sell it through a code server. Anyone could buy a smart code and use it to download the artist's content -- or that of any other merchant on that code server, or on any other code server that agreed to work with it. New artists might sell their music, articles, or images for five cents, 25 cents, or more. These would be downloaded either from the code server itself, or from a specialized server run by the artists.
Sharing Paid Access to Support Artists and also Give to a Community: Anyone with a smart code could create a new smart code good for, say, 50 downloads of an article or song costing perhaps 20 cents each. This new code could be restricted to that use, and then included in a Web link sent to an email list of maybe hundreds of people. The first 50 who used the link would get the content free; others would be asked to pay the 20 cents, through their own code or some other means. If all 50 downloads were not used by the end of an expiration period such as 30 days, the unused value would automatically revert to the parent code -- returning any unused value to the donor (with the restriction off). Therefore a fan could support a favorite artist, while also giving dozens of people a gift with a small but real monetary value (thereby distinguishing their communication from the flood of free material, in that somebody cared enough to pay for it). The greatest benefit to the artists might be introducing new people to their work in this way.
Licensing Printed Or Other Copies of Proprietary Work: Another way of sharing paid access is that a company that wanted to print, say, 500 copies of a copyrighted document could pay for the copies online, and receive a public code that anyone could use to verify that 500 copies had been paid for. This code could appear on the reprints.
Digital Tickets for Admissions to Movies and Other Shows: Friends could telephone short, prepaid codes to admit any number of people to a movie or other show. Four-character codes are long enough for admission to most events (a thousand digital tickets, with less than one in a thousand chance of guessing any) -- and a single code could admit any number of people, whether they arrive together, individually, or in groups of different sizes. Even last minute, somebody could call from the theater, and use either voice or the Web on their cell phone to create a code to admit their friends to that show -- then phone or email this digital ticket to their friends. At the theater their friends would enter the code on a keyboard or give it to an attendant, who would then see on the theater's equipment how many more people could be admitted by that code. The owner of the secret code could also check it by cell phone or otherwise to see how many people had been admitted. Of course the code server used by the customer would have to talk with the theater's equipment to make this possible.
Codes for Clients of Libraries, Etc.: Libraries could give their clients small-value codes to allow limited access to proprietary databases that otherwise would be unavailable to them. Any value unused at the end of an expiration period would automatically revert to the library.
Public Health Messages or Homework Assignments That Pay: Service organizations could put out public-health messages, such as anti-smoking or disease control, with a couple brief questions to show that a person had read the message. Correct answers might credit 20 cents or so to the public code he or she provided, for the first 500 people who answered correctly (total cost to the service organization, $100 -- and benefits could include bringing the campaign to the attention of many more than these 500 people). School homework assignments might also be motivated this way, perhaps with school-provided codes to prevent students from answering multiple times.
Reselling Codes: Anyone could buy a code and use it to create other codes to re-sell, perhaps to specialized markets. Similarly, the organization that runs the software and provides the codes does not need to be the same as the organization that manages the money -- dividing the "broker" role (noted above) into these two very different functions.
Medical and Scientific Journals: Today it can cost individuals, small businesses, or small universities from $5 to $40 or more to download a medical or scientific article from a journal -- probably about 100 times what it costs a major university for the same download. Many people who want the articles just do without. Smart micropayment codes would facilitate a mass market to individuals and small organizations, increasing profits while lowering prices. Journals could make large sales of online access that could then be broken up at will for resale to small organizations or individuals, and the cost of the financial transactions would be negligible.
Automatic Web Registration to Avoid Hassles: Web sites run by some newspapers and some other organizations now often require free registration to use them -- a increasing hassle if one is searching for information among dozens or hundreds of newspapers, many of which one may never visit again. Secret smart codes could provide registration information, if the publishers' sites could receive it in some standard format. Publishers would have an incentive to allow such automatic registration, as they lose visitors under the current system, as many visitors look elsewhere instead of bothering to register. Of course the information could be faked, but that is true currently as well. End users would certainly have an incentive not to share their identity code with others, since if the code got out, others could speak in their name. And they could not simply give another code the next time, unless they went to the trouble of setting up that code with an identity -- and those who cared enough to set up a different identity could register that way in any case.
Parental Controls: Smart codes could be restricted to allow only certain purchases. Parents could get advice on what to allow from organizations they trusted. In fact, these organizations could list recommended movies, etc. on their Web sites in a standard format, and parents could list the Web addresses of one or more organizations to produce smart codes that could only make purchases that one or more of them had recommended.
Digital Gift Certificates: Last-minute shoppers could create smart codes instantly for whatever value desired, and telephone them to recipients (or their voicemail). These certificates could include gift recommendations as well. Organizations, experts, or anybody could publish their lists of gift recommendations, preferably on the Web in a standard format, and givers could automatically populate their gift codes with the recommendations of one or more expert sources they liked (and then personally edit the list if they wished). Gifts too expensive to buy with the code (using price estimates provided by the experts) could be automatically deleted. Unlike conventional gift certificates, these would not be designed to promote particular merchants, but to provide the best possible gifts by offering the giver expert help in selecting the best choices for the occasion.
Fundraising I -- Sharing Donations through an Aftermarket: A donor to a charity could give more than he or she could otherwise afford, because the contribution would be documented through a secret smart code. With this code the donor could create new smart codes (with no cash value for purchases), used to re-"sell" portions of the donation to other supporters -- immediately, or even years later if he or she needed money then. And these children codes could similarly be subdivided into even smaller donations. People could contribute more because they could probably get their money back if they ever need it, from friends who also support the cause.
Fundraising II -- Historic Donations As Collectables: Donations to charitable or other organizations can be maintained permanently (see below), through an archival code server even after the organization is gone. The code's control center would document that the donation occurred, and provide historical and other facts about its context. Donations could therefore exist forever, preserved only by the code; and donations to historically important projects or causes could develop market value as a collectable, potentially much greater than the amount donated. The owner could use the code to generate public codes that could be used to show the donation to others or print associated documents, and to prove possession for the purpose of sale, without revealing the secret code that established ownership. People already collect buttons, T-shirts, and other memorabilia from important movements; these usually result from small donations. Smart codes representing small or large donations could be collected as well, giving donors additional incentive to contribute to the most memorable and important causes.
Maintaining Codes in Perpetuity: Once codes are no longer active but are maintained for historic value they will have very little actual use; therefore brokers or specialized archival organizations could maintain the code databases online forever at very low cost, which could be funded with a modest endowment -- or by modest charges for public use of the code database, if no endowment were available. The cost would be further reduced since the same companies that insured perpetual existence of the codes could also provide emergency backup while the organizations that issued them were active, a function needed anyway. They could do this since they would frequently receive and archive encrypted copies of the code databases they were preparing to preserve for the future.
Digital Customized Art: Smart codes allow the code itself to be the "original" of a digital art work, allowing new customized work to be created -- regenerated using images, sounds, or texts supplied the owner, as allowed by the artist. For example, if you owned such a work and used the code, your family or pets could appear in photos depicted in a scene -- or on Mt. Rushmore, or in the clouds, or in patterns of leaves on trees or on the ground. Or a popular singer could be accompanied by your cat. More abstract works could take elements of style, such as color schemes or rhythms, and use them when regenerating an image or a song. Artists could produce limited, numbered editions of, say, 50 copies of such works, which would exist as 50 secret codes that could be sold to different owners -- increasing income while reducing prices, maintaining potential resale value of the codes, and greatly reducing the problems of storing and transporting works of art. Anyone could make copies of the result, but only someone with a code could have the server regenerate the art, integrating image, sound, or text files the owner provided, using programming created by the artist.
Supporting Different Languages: General-purpose computer translation remains unreliable, but editors (each working in his or her own language) can code certain text so that can be output in many different languages. This could be done first in specialized areas such as tourist services, where it is relatively easy to agree on certain unambiguous meanings (hotel, breakfast, train, museum, and a few hundred more) and how they should be translated. Smart code owners could then specify their language of choice, and automatically see any such coded text in that language, if their server offered a standard language package. Smart codes do not do this language processing, but could encourage it by providing practical uses for each incremental development.
Most people think a lot about money, but very little about the money system itself. For example, everyone knows that governments do things to increase economic prosperity. But did you ever notice that money would have little meaning if it were not kept scarce, or if its scarcity did not cause suffering and death for many people? So in parallel with measures to increase prosperity, governments also work to maintain poverty, especially of certain races and peoples. The standard policy of purposely creating unemployment in order to restrain inflation is one example, and there are many more. Money evolved to help manage scarcity -- not today's technology of potential abundance. And for now at least, powerful institutions are addicted to that scarcity and make sure it is maintained. Otherwise collecting money would be like collecting stamps, in that people would seldom humiliate themselves or commit crimes to do so. The fact that most people on Earth have money problems most or all of their lives is a political choice, not a law of nature.
A micropayment system that greatly reduces the cost and hassle of some financial transactions could lead us to revisit certain rules (both open and hidden), and rethink what we want to do. We could better design systems that work for people if we understood which failures now result from accident, and which result from design.
I wrote this summary to show the richness of possibilities of micropayment "smart codes." Clearly there are hundreds of other potential uses.
For more details see my earlier article, "Micropayment Smart Codes for Small Business, Arts, Fundraising: A Better Way to Pay Online," at http://www.communicationpractices.org/micropayment/draft2004-10-07.html.
I will probably start a blog for discussion. If you are interested let me know, or check back at www.MicropaymentSmartCodes.com for further information. Privacy statement: we won't send advertisements or give out your email to anyone, and you can get off our list at any time.
2004-10-28
Addendum 2004-11-14
Some clarifications and additions to this summary were added in an addendum, November 14, 2004.
John S. James
jjamesXXX@MicropaymentSmartCodes.com [see note below]
People: remove the XXX from the email address. (Spam robots: leave it in.)
http://www.MicropaymentSmartCodes.com
----------------------------------------
This work is licensed under a Creative Commons License.