This work is licensed under a Creative Commons License.
By John S. James, January 2005
This micropayment "smart codes" design, an accidental invention, resulted from the need to sell newsletter subscriptions in a world increasingly divided between rich and poor. I believe this computerized payment system could help artists make a living, help organizations raise money, and do more besides. I'm proposing these ideas for open-source, community-based discussion and development, and am publishing them for general use, with no claim of ownership. The basic idea (computerized payment codes, each with its own Web control center, and able to reproduce new generations of codes without limit) seems to be new, and not implemented anywhere as of January 2005.
Smart codes will make certain small, online payments much easier than paying with credit or debit cards or PayPal -- for example, allowing some small purchases with no human intervention at all, under rules and limits the buyer can set or change any time (see "zero-click purchasing" and "robot negotiation" below). And if you read, hear, or see something you like on the Web, you will easily be able to contribute 10 cents, 25, cents, 5 dollars, or any other amount to the author or to a designated organization -- giving encouragement as well as money.
Also, smart codes will allow fans or friends of a musician, writer, or other artist to buy any number of bulk copies of a particular work or collection of works, releasing free downloads for people throughout the world (accessible by a Web link containing a smart code that can be shared through social networks) -- so most downloads can be free to the end user, while the artist still gets paid for every one. This should help promote (as well as support) the artist, because if you like a song or other work that costs money, you could legally send free download links to any number of friends -- either paying in advance for a few copies for your friends, or relying on copies donated by friends or fans of the artist anywhere in the world. Only if the donated copies were exhausted would the end user receive a payment-request form, through which he or she could purchase one download -- or pay for many downloads and use one personally, instantly recharging the smart-code links wherever they are (since the payment recharges the control center that all those links use). Or the purchaser could create a new link (with a new code and new control center) for private distribution, to contribute the downloads to personal friends or colleagues, instead of contributing to anyone in the world who had received the previous link. Either way, paid access is being purchased by those who have the money, and then widely shared through social networks -- instead of the artist or a publisher demanding that everybody pay for their own personal download, which often doesn't work very well.
Any unused bulk downloads of music or other content could be set to expire at a certain date, and their remaining financial value will automatically return to the donor who paid for them, without any human intervention. Or a donor who neglected to set an expiration date could cancel the smart code manually and receive the remaining value, if it turned out that there was not much interest in the music or other download. Third-party Web sites could review or recommend music or other work that costs money but is currently available free by donation -- promoting and supporting the artist while also giving their own visitors coded links that could save them money.
In a very different use of smart codes, moviegoers will be able to buy paperless digital tickets by cell phone or instant message even while sitting in the theater, and deliver these admission codes by phone or message to their friends outside. They could use the same smart code to pay many different merchants for different kinds of goods and services (unless the code were intentionally restricted to certain payees by the person who paid for it).
Smart codes will let people send money to friends or family members even if neither sender nor receiver has a computer or email address, since these codes can be managed by telephone if necessary.
And new users can simply buy or be given a smart code, and they are ready to go; no registration or sign-up process at all is necessary, either to spend the money that the code contains, or to generate new codes that can be published and used to receive money. The reason no account setup is necessary (unless somebody's rules require it) is that the code itself is the whole account; there are no user names or passwords in this system. New users can receive a new smart code from anyone who already has a smart code with enough value in it, and start using the new code immediately. And they always have the reassurance of knowing that their maximum financial risk is limited to the value of the code.
Smart codes are like cash. You don't need to register to use cash, you don't need to log in or remember a user name or password. You can give cash to anybody and receive it from anybody. You only risk what you carry with you, and can subdivide cash to limit the risk by carrying less. But you can't use cash to pay money by computer or telephone, you can't customize it with instructions to act independently in helping you do business, and you can't have it reproduce children and grandchildren, forming family trees of financial instruments that can inherit related, customized instructions. With smart codes you can.
An entirely different use of smart codes will allow particular donations to historically important organizations to be recorded, displayed, and authenticated forever, so that they can later be traded as collectables if an organization is indeed memorable -- turning a "donation' into an "investment" as well, thereby creating a whole new incentive to give to the most important causes.
The estimated processing cost for most smart-code financial transactions is less than a tenth of a cent. Some transactions may cost more than that.
This article only hints at the possibilities of what appears to be an endlessly flexible financial instrument. Note that while most end users may never encounter the Web control center of their smart code, or even know that it exists, they will still benefit from the new business models this system makes possible.
My site, http://www.MicropaymentSmartCodes.com, provides the information needed to implement a working prototype of smart codes fairly easily. I am no longer writing software and cannot develop the system myself, due to other commitments. Instead I want to start a public discussion to illuminate the design and leave anyone free to use it non-exclusively, commercially or otherwise.
To understand the basic idea, start with conventional payment codes like gift certificates, the Starbucks card, etc., which have recently become a multi-billion-dollar industry (gift certificates or cards are really codes these days; the piece of paper is not necessary). Conventional gift certificates have major drawbacks. Each can pay only one merchant; customers are locked in and give free use of their money for no economic advantage; and the dirty little secret of the business is how many gift certificates are lost or otherwise not redeemed -- pure profit for the card issuer, pure loss for the customer. (Yet customers spent an estimated $17 billion on gift certificates in the 2004 holiday season alone, proving a strong non-economic appeal. So we will show how to use smart codes to make gift codes better.)
Smart codes are computer-controlled payment codes that can have dozens or hundreds of different options, information displays, and user interactions set or changed at various points in their ancestry. Most importantly, they can instantly reproduce any number of fully powered "children" codes, which can inherit many options from their parent by default. In this way any smart code can produce new, customized codes in any quantity desired. And each of these children is also a fully powered smart code with its own control center, able to reproduce its own children and grandchildren in turn, through any number of generations. Some or all of the financial value of the parent can be given to each child, as the owner wishes.
A smart code might simply pay for goods or services (or receive payments through a new code it generates -- the same code cannot do both, since one code must be secret and the other must be public), and do nothing more. Most end users may only pay for purchases or donations, and may never even know that a control center exists. But still they will benefit, because this endlessly flexible financial instrument makes possible new business models that would be difficult or impractical with conventional payment systems. We outline some of these models below.
Every smart code has its own control center at its own Web address. The owner of the code can use the control center to change its information or options (and to reproduce children codes). The code itself is the whole access; there are no "user names" or "passwords" to remember in this system, no "logging in" except by entering the code.
If a code is lost or compromised, its owner can cancel it through its parent (or other code specified for this purpose, if any); in that case all unused financial value reverts to the parent (or other code set up to receive the value). Also, codes can be set to cancel themselves automatically at a given date, so that all value in a lost code will ultimately return on its own without any human intervention -- one less thing for the owner to worry about. And no one ever needs to replace a lost password, since there are no passwords in the smart-code system.
The same smart code could pay many new merchants, not just one. In fact, as we show below, new merchants could join simply by buying a smart code from anyone who already has one, and issuing new "public codes" (explained below) to receive payment. And these public codes could accept payment not only from other smart codes, but from credit cards or other conventional payment systems as well -- which should greatly help in the early adoption of smart codes.
Most importantly, each smart code's control center allows the possessor of that code to reproduce any number of new "children" smart codes, which will usually inherit the parent's options by default (most but not all options can be changed then or later if the owner wants). The owner of the parent decides how much of the parent's value to give to each child. These children are fully powered smart codes that can reproduce in turn, to any number of generations, forming family trees of ancestors and descendents with related but differing options. So while most code owners will never see the control center but only use their code to pay for articles, music downloads, digital movie tickets, contributions to organizations, or other goods or services, they will still benefit by buying or being given highly customized codes that automatically handle all kinds of errands and other purposes for both buyer and seller, and make new business models possible.
[Technical note: code reproduction and option inheritance is easy to implement, since each code with all its options is simply one record in a database on a Web server -- and that code's "control center" merely displays some or all options and allows certain changes through software provided by the server -- including allowing the creation of the new "children" codes, each of which is a new record in the database. The child inherits options by default, simply by copying most of the parent's record into the child's record. The actual code assigned to the child is a newly generated random number or other character string that is not already in use in the code database (unless the owner who is creating the child chooses to override the random sequence and assign a name for the code).]
One illustration of the power of this system is how easy it is to extend codes from paying only a single merchants to paying many merchants -- and to integrate credit cards and other conventional payments as well. All the codes discussed above in this summary must be kept secret -- because they have financial value that anyone who has the code could spend. But a code owner who uses the control center to produce children codes can specify that some or all of these children will be "public codes" that never contain any financial value, but instead receive payments and automatically transfer the value to another, secret code (by default, the parent). These "public codes" could then be published and distributed by the code owner to receive payment for goods, services, or donations. The money paid into public codes cannot be spent by unauthorized persons because they do not have the secret code that has received the money. Each public codes is a one-way money door.
This system allows multiple customers and merchants to do business even though they may not trust each other, as long as they can all trust the server run by the organization that maintains the codes. Note that the code-issuing organization does not need to be involved when a customer uses its code to reproduce multiple children (its server handles the process automatically). It might charge a small amount for each new code produced, to support its operation and also to prevent a customer from creating millions of new codes (which would prevent other customers from using any of them, and require excessive storage space on the server). And it may place limits on each code it issues, such as how much money can be received per day by credit card into all descendents of that code. Higher limits may be approved for individual codes, if the code-issuing organization trusts its owner to make good the losses in case of abuse (trust that could be based either on personal knowledge, or on insurance).
The control centers of public codes could be used not only to take orders, but also as instant Web sites -- since anyone who has that code could see the text or other information placed there by its owner (who could set up or change the site by using the secret parent of the public code). These Web sites could provide product information, take orders, accept many forms of payment, and automatically do some fulfillment tasks such as authorizing downloads. The public code could be contained in a Web link allowing one-click access to product information, up-to-the-minute fundraising campaign results for nonprofit or "cause" organizations, or any other information the owner wanted to make available. The owner of the parent code could produce any number of different public codes to keep track of different campaigns, advertisements, or fundraising appeals; separate or combined accounting reports will both be available through the parent. And of course the owner of a public code could change the information, or delete the code and Web site entirely, at any time.
Public code could receive payment by smart codes, by credit or debit cards, or other conventional payment (provided that the server accepted and allowed those payments). Payment options could be chosen at the public code's control center/Web site, which could allow mix-and-match (for example, paying by smart code up to the value it contains, then charging the balance to a credit card). In any case the money goes to the same place, crediting not the public code that receives the payment, but a secret code (usually the parent of that public code). The control center of the public code can include forms for ordering, including all payment option provided by the code server (the organization responsible for managing the Web site that provides and processes the codes). The merchant receiving the payment would never need to see the credit or debit card information (reducing the risk of fraudulent use), and might never see a smart code used for payment either -- although the server might keep this information privately in case questions arose.
Smart codes allow music, writing, visual arts, video, multimedia, or other content to be marketed not only to the end user, but also to fans and friends who want to support the artist, or make specific work more available, either generally or to certain people. Most downloads could be free, while the artist still gets paid for every one.
The way this would work is that anybody interested in the music or art could buy a smart code good for any number of downloads -- 1, 20, 500, 10,000, etc. (presumably with large discounts for the larger numbers). For their purchase they would receive a link with a smart code included within it, good for that many downloads of the song or other work. They could email this link to friends and associates, along with an explanation that the link has money value, and any requests they want to make about further distribution. For example, a customer who wants to support and promote the artist might buy many downloads and urge his or her associates to send the link to anyone likely to be interested. But if money is tight, the customer might send the link only to members of an interested organization, and ask them to wait a week before sending it on, so that the members could use it first.
When the link is clicked, the control center (for the smart code contained in the link) checks if any paid downloads are available. If so, it gives permission for the content to be downloaded or otherwise delivered (either from the same server, or from a different server).
If the link is exhausted, then the user who clicked on it will get a payment page -- allowing payment for a single download (his or her own), or for multiple downloads. Notice that a purchase of multiple downloads will instantly recharge the links already sent out, wherever they are, anywhere in the world. Of course the user will also have the option of buying a new link (the same link with a new smart code), in order to share the content with whomever he or she chooses.
Music and art that people care about form loose communities, sort of linking people together, sort of not. The marketing we are suggesting here -- seamlessly dealing with the traditional single-copy purchaser as well as with more serious (and usually richer) friends and fans of an artist -- can help develop these links by giving them economic reality. The customer may buy one download to enjoy it -- or buy 2,000 downloads right on the same purchase page, probably paying by credit card. The same action supports the artist, promotes the artist to new potential fans, gives many people a gift of financial value, and thereby distinguishes the sender's email and message from the flood of email around us. These reinforcing incentives make action (sales) more likely.
Smart codes could make it easier for artists to sell their work online, entirely on their own, than to set up a simple Web site without downloads or sales today. And artists could pay for the service as a percentage of sales, with little or no upfront cost. If in addition popular reviewers are looking for good material, and integrating free samples into new compositions that could have widespread appeal on their own, then it will become much easier for quality new work to be noticed, and begin to develop a constituency.
Smart codes could provide fully digital, paperless admission tickets to movies or other events. Unlike paper tickets, you could create them on the fly and transfer them by telephone.
Suppose you go to a movie and decide that three of your friends must see it, and want to invite them to the next showing, which you will see again with them. Before calling to invite them you call the automated number of your smart-code account. With minimal setup by the theater, your smart code can produce a ticket code (another smart code) that admits up to four (or any number) of people, arriving either together or separately. Smart codes for event admission can be short and easy to write down; a six-digit code is usually enough (1,000 ticket codes can be issued, with the odds against a guess getting in through any of them being less than 1,000 to one). Without leaving the theater you can phone or instant-message your friends and send them the code. If you are not the trusting sort, you could create a separate one-person code for each of them.
Zero, one, two, or three friends arrive, use the code instead of a ticket to get in, and meet you in the theater; you also use the code for yourself. The only equipment the theater needs in order to accept these paperless ticket codes is an ordinary speakerphone; it is left connected to an automated phone line at the smart-code server while people arrive for the show. Of course enough seats must be reserved through the regular ticketing system to cover all ticket codes sold. When someone or a group arrives, that person or the attendant enters the code and the number in the party into the speakerphone, which tells the attendant whether the individual or group is admitted. The server also charges your account (your smart code) for the admission(s), and adds that value to the theater's smart code (from which it can later be transferred to the theater's bank account).
The smart-code software could automatically refund all or part of any unused codes, depending on the terms the theater decides to offer. To encourage sales, theaters might refund the price if there were plenty of seats, but not if the show was full; the policies would be set as options in the smart code and applied automatically, avoiding labor cost.
The usual gift certificate locks you in to one merchant. Smart codes can pay many merchants, since new ones only need to buy a smart code (and generate public codes) to receive payment. But cash can pay anybody -- yet is often avoided as a gift, probably because it contains no personal information.
Smart gift certificates could be given a limited list of public codes (particular merchants or particular offers) that they could pay. The giver could either make up his or her list from scratch, or could incorporate the lists of independent gift experts (each can be entered by one code, no matter how many items [codes] it lists). The giver could expand this list at any time, before the gift is given or afterwards. The giver may also include an escape code, giving the recipient the option of paying any merchant that accepts smart codes, or getting the money in cash.
The smart code could display only those gifts that it contains enough money to purchase -- and even show what colors and sizes are in stock, if the merchant makes this information available online.
Expert gift selections added to those of personal friends could improve the usual hit-or-miss selection process, resulting in more valuable, even life-changing gifts, professionally selected for particular kinds of children or adults with particular inclinations, strengths, or weaknesses. Each expert would be motivated to improve his or her reputation for doing this selection well -- strengthening the link between merchants and customers. If we are doomed to consume, why not make the most of it?
Here's a completely different use of smart codes. Secret codes containing no financial value could acknowledge charitable contributions to potentially historic causes -- allowing specific contributions to live forever. These codes (reified contributions) could be traded as collectables, potentially developing value far greater than the amount contributed -- creating a new reason to give, by making each donation to an historic cause also be an investment owned by the giver. (What will a $50 year-2005 donation to a now unknown but later critically important organization be worth in 10 or 20 years?) Note that while the acknowledgement code must be kept secret, its information could still be displayed openly through public codes, showing information controlled by the owner (or by the recipient of the donation) -- such as donation date, campaigns the money was used for, photographs, videos, or other multimedia, and the overall meaning or story of the donation. When the secret authentication code is sold to another collector, the new purchaser could use its control center to have the code replaced with a new one, assuring exclusive possession.
These examples of what smart codes can do are more fully explained in other articles on this site (see links below). Many of these uses are novel, even seemingly bizarre, since they would be difficult to handle with conventional payment systems and are therefore unfamiliar.
So far we haven't far addressed how the organization that issues the codes will be paid for its work, since the answer is so easy. One way would be to charge a percentage transaction fee -- probably one percent or less for most transactions, because the processing cost is so minimal (see "Estimated Transaction Cost," below). Possibly only the more expensive transactions would be charged, such as those requiring multiple servers, encryption, or automatic generation of additional transactions (such as automatic payment of royalties or taxes whenever a sale takes place).
The money is right there in the code, so there's no issue of billing, collections, or not getting paid. For psychological and marketing reasons it would be better to charge the merchant who receives the money than the buyer who spends it, even though the amount is the same. This is what credit cards do.
A small amount, maybe a penny or more, would also have to be charged for each new code created, to prevent users from indiscriminately creating millions of codes.
Merchants could get together and operate the code service without fees, to increase sales. This might be problematic, however, because they would likely set the codes to favor themselves over other merchants, so customers would be inconvenienced by needing to use multiple codes when otherwise one would be enough.
For most purposes, a smart code of 12 random digits would be long enough. This length allows a million different codes to be active at one time -- while the odds against a guess hitting any active code is a million to one. Or ten million codes could be issued, with the odds against a guess being 100,000 to one. [Technical note: only the server that issued the code could tell if a guess is correct -- and it would recognize an attack long before 100,000 guesses had been tried. Decryption programs that could try millions of guesses would be useless, because they would have no way to tell if a guess was right or wrong, except by asking the server every time.
For tickets to a movie or other event (good for a particular showing only), six digits (or four alphanumeric characters) would usually be enough. Either one allows 1,000 digital tickets (codes) to be issued, while keeping the odds against a guess getting someone into the show at 1000 to 1 or less. No one could try hundreds of different guesses at the door to get in.
Probably most codes will allow their owner to make up a nickname or alias that either replaces the code entirely, or can be used as an alternate. The new name could be any length or format the owner wanted. It could be a word, phrase, number, famous quotation that would have to be entered exactly, the name of someone's dog, etc. Of course the owner is responsible for the loss if the name he or she makes up is too easy to guess. The server only enforces the requirement that the code chosen not already be in use.
The name or nickname could even be picked by the owner to be intended to be guessed -- rewarding the winner of a contest who first put together clues from a newspaper, radio station, email, etc. There might even be several rewards given for the same code, so that the contest winner would hurriedly call, say, 30 friends and have them use the winning code immediately to get one of the $50 checks offered -- activating many telephone trees and engaging new people in the contest (and whatever program is behind it).
On the other extreme (of tight security), a code with a very high value might be a longer random number, for example 18 digits, making the odds against a guess be astronomical -- 1 in 1,000,000,000,000,000,000 to be exact. A business could put thousands of dollars into such a code, and then never give it to any third party. Instead, that code would only be used over a secure connection to the server, to have the server generate codes of lesser value, sent back to the owner over the secure connection. These smaller codes would then be used to make payments, with no risk of loss beyond the value they contain. The large code could be refilled by mailing a check when necessary -- largely eliminating transaction fees from credit cards or wire transfers.
All of this can be implemented straightforwardly, with a skeletal working model probably taking a few weeks or less for a good programming team. Only a few options would need to be available first -- since the businesses that issue the codes will be developing and refining new options forever.
Security with this "smart code" system is a whole discussion; see "Variable Code Formats," above, and also see the links below. What's different with smart-code security is that users can choose as much or as little of it as they need for their own purposes. For example, owners could choose any length desired for their codes, trading off security and convenience as appropriate.
The code owner must have secure communication available with his or her server, but many purchases may not need to use any encryption at all. To see why, look at the obstacles any theftware would face in trying to harvest codes during their transmission:
PINs could be added if necessary, although probably most smart codes would either be too small to bother, or restricted to certain payees, probably making a PIN unnecessary. Other codes, kept safe at home or in the office, could be used to hold high values, and/or to cancel the everyday-use code if a thief changed it in an attempt to lock out the legitimate owner.
Note that there is no stable ambiguity about multiple ownership of a smart code -- since anyone who has the code can lock all others out, by having the control center change the code. It is the owner's responsibility to keep their codes secret (except for public codes, of course). The owner could also make arrangements for a separate code, such as the parent, to regain control of a code that has been stolen. But if the owner is careless, the advantage of this instability is that the organizations providing the codes will seldom or never be asked to help resolve ownership (since usually would have no possible way to do so). Smart codes will cost little, partly because there are so few occasion where human customer support is needed or even possible.
Note that the fact that two different code servers might happen to have the same valid code is no problem at all. A valid code given to the wrong server is equivalent to a random code given to it, and the smart-code system is already set up to handle that.
There could be a problem with fraudulent Web sites set up to take orders and harvest valid codes, which would then be robbed. The maximum loss would be limited to the value of the code, since smart codes will normally have no demographic information, and therefore fraud cannot result in identity theft (unlike the "pfishing" scam that asks users to "update" their information at site that pretends to be their bank or financial institution). A defense would be to make sure that any large, unrestricted smart code was submitted only to code servers trusted by the server that issued the code (see next paragraph on trusted servers). When there is any doubt, the URL of an unknown merchant's public code could be submitted to the server that issued one's own code. Later, browser software or plugins could handle this task automatically, by demanding a password before sending the user' secret smart code(s) to any server not known to be trusted. An additional defense is that after the theft occurred, the code would have to be cashed at a trusted server (which might be hard to do) before the legitimate owner discovered the theft and cancelled the code.
The idea of the trusted code server is that smart codes would only be compatible across servers that agreed to police their customers to prevent fraud. While anybody could buy a smart code, the server on which it was issued would be responsible for stopping any ongoing criminal activity. It could do this by shutting down codes that were abused, and limiting the amount of money a new code could receive until its owner had established trust, which could be done in various ways.
If the managers of a code server failed to do this after receiving credible complaints, other servers could take it off their list of code servers whose transactions would be honored (making smart codes issued by the negligent or untrustworthy organization incompatible with codes issued by the mutually trusting group -- a buyer on one and a seller on the other could not do business). So the mutually trusting servers might not be free of crime, but they would be free of large-scale or frequent crime. Therefore people could use the smart codes these servers issue to make payments, to anyone who has a public code on any of these servers, with only a small chance that they are dealing with a scam artist who will not deliver goods, or will make unauthorized charges to their code.
As we show elsewhere, this smart-code system does not require a critical mass of early adopters in order to work, but could be started and used productively by a single organization -- greatly facilitating startup. Other artists, merchants, charities, or causes could then add themselves to the system simply by purchasing a code from that organization. Then any code owner could use his or her code to pay anyone else who had a code on the system.
A completely different startup path is codes to acknowledge donations to organizations (potentially giving specific donations investment value as collectables, mentioned above). A key advantage of this path is that organizations could simply start giving out an additional acknowledgement page to future contributors -- containing a code and an explanation, and perhaps titled, "Save This Page; It May Be Valuable Some Day". There is no immediate money transfer -- except to encourage donations if the idea catches on.
So far in this article (except briefly in the Security section above), we have assumed that all the different codes are managed by the same code server (the same code-issuing organization, which could usually manage all the codes on a single computer server). But it turns out that groups of servers could work together, allowing any code owner on any of the servers to buy from any merchant on any of the servers -- provided only that the servers all trust each other to operate honestly and be sure that they can pay their debts to each other and to their customers. (If an organization is not trusted, then it isn't accepted into the group, and its codes are not compatible with the others -- a big incentive for accountability.)
It turns out that different mutually trusting servers could work together even if they did not agree on any technical standards up front -- not even the code length or format. So anyone could go ahead and implement their own codes now, without having to wait for technical agreement, and combine with other smart-code systems later -- another big advantage for startup of smart-code use. This sounds astonishing, but it's true because a secret code can be charged if it can be delivered to the server that issued it, so technical agreement is necessary only for the communication protocols between the code servers -- delivering the code, delivering the acknowledgement of the success or failure of the payment, and administrative messages; of course this communication must be secure. But no agreement is needed on what the codes look like -- all numeric? alphanumeric? Chinese characters, if all the servers could represent them? And no agreement is needed on the basic internals of the servers (although advance agreement may be needed for some special features, such as robot negotiation between codes on different servers). The communication agreements could be forged later, long after the individual servers had been designed, implemented, and put into commercial use.
Our guestimate for the cost for processing each simple financial transaction in this system is about a tenth of a cent, regardless of the transaction amount. We computed this figure by rough calculation from commercial Web-hosting fees, and the associated bandwidth and storage limits. Note that most smart-code transactions use very little bandwidth (the most important information transmitted is the 12-digit code to be charged, and a few more digits for the price to charge against it) -- and most smart codes for typical uses should average well under 5,000 bytes on the server (including archival storage of transaction records), meaning that each gigabyte available could handle more than a 200,000 codes. Intensive bandwidth or storage uses such as video on public-code Web sites could be charged separately. We do not have an estimate for the added cost of secure transmission, which may be unnecessary for many transactions (see "Security" above), and could be billed separately if necessary.
A smart-code financial transaction between merchants on the same server is basically a very low-resource visit to a Web site, like a visitor who receives only a couple paragraphs of text, with no graphics, etc. at all.
The low cost allows micropayments such as 10 cents for reading certain information on the Web, or for a small contribution/encouragement to the site author -- amounts too small to collect by most payment systems. The hassle of approving many small transactions can be alleviated by zero-click purchasing, described above.
The widespread, convenient availability of computer power through the Web will fundamentally change the money we have known, loved, and hated for thousands of years. Even the smallest financial instruments can now be computer controlled, allowing new business models that could not exist before on any important scale. Our "smart code" proposal is one possible design.
Can you see any problem or other reason that anything described in this write-up could not work as stated? Or can you find any practical way to do the examples we describe with PayPal, credit cards, or other systems that already exist? For more details about the smart-code design, see other papers we have published on this site.
If the smart-code idea is workable, then we should use the opportunity this endless flexibility provides, to design money that works better for people than the system we've got. For example, you should be able to click to contribute 25 cents or some other amount if you like something you just read, heard, or saw on the Web (and if your code is out of money, automatically get a credit/debit-card form to recharge it if you wish). Then writers, musicians, and other artists will have a new income stream that they do not have today, directly from the people who care about their work.
Note that some of these writeups are repetitive or disorganized, because they were "defensive publication," intended to prevent parts of this system from being patented and denied to public use. We will reorganize this information when we have time.
See Smart Code Startup for suggestions on how artists, fundraisers, merchants, and others could feasibly introduce smart codes -- and for more details on how smart codes work. Or see Smart Codes: 12 Advantages Over Other Online Payment Systems.
For an earlier summary, see Micropayment with Smart Codes That Can Reproduce, October 28, 2004. Some clarifications and additions to this summary were added in an addendum, November 14, 2004.
For more details see a longer 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.
If you think something stated here will not work, let me know and I will either explain it or fix it.
Watch for a blog to continue this discussion, at our home page, www.MicropaymentSmartCodes.com
Privacy statement: we won't send advertisements or give out your email to anyone, and you can get off our list at any time.
Micropayment for online purchasing was disappointing for years, but may be ready for a comeback. The next big commercial push may be in instant messaging (SMS, short message service), using one's phone to pay for music, tickets, games, etc. An advantage of smart codes here (in addition to all the other advantages) is that people will be able to pay for event tickets and other non-telephone items through their phone, without going through their phone company.
Here are some places to look for micropayment information:
Watch this space for more links.
This work is licensed under a Creative Commons License.