While exploring better ways to sell information online, we developed a design that we believe will be important in online commerce generally -- financial accounts each with its own Web control center, allowing each account to have its own settings for dozens or hundreds of options and services offered by the server, and also to reproduce children accounts without limit, through any number of generations. Each new account will inherit the options and services of its parent, and allow owners to make inherited changes if they wish -- leading to family trees of related accounts that can evolve through practical use. This article shows how organizations can let people give as much or as little as they choose, without breaking out of the moment to do all the steps usually necessary to pay money.
Note: A shorter version of this article was published in AIDS Treatment News, http://www.aidsnews.org/2005/07/smart-codes.html, online July 31, 2005.
While looking for better ways to publish a newsletter online, this writer, who designed and wrote software in a previous career, invented what looks like a new tool for online commerce. This article outlines fundraising possibilities of this "smart codes" design for computer-controlled money, with financial accounts that can reproduce without limit, inheriting options and services. Believing that this approach may be a fundamental advance that should not be patented and owned exclusively by one person or company, I published it online for anyone to use, and am encouraging open-source software development.
This article focuses on fundraising -- on making it convenient, engaging, and rewarding to donate as much or as little as one chooses. The details needed to do everything described here are already published at http://www.MicropaymentSmartCodes.com. But that site looks less at fundraising than at how musicians and other artists could use smart codes to market their work independently through social networks worldwide -- allowing friends, supporters, and other donors to buy bulk prepaid downloads as gifts, for sharing in smart Web links through networks, so that most downloads can be free while the artist still gets paid for them. (For our readers, the same system could also make medical-journal articles more accessible, as journals could easily sell thousands of downloads at a time to third parties who could market them effectively to those now excluded because they are not part of a big university, corporation, or other institution.)
This article considers four fundraising scenarios:
At this time (July 2005) the smart codes described are only a design; the software to provide and manage them has not been written. I am committed to AIDS Treatment News, and would like to use smart codes in our fundraising, but am not in a position to develop this accidental invention as a business. I can develop it as a conversation, and am looking for others to help explore next steps. Perhaps you know someone who might be interested.
Smart codes are financial accounts maintained by a computer server that has an address on the Web. Anyone with a smart code can pay anyone else with a smart code, simply by copying the code itself into a Web form provided (and entering a payment amount, unless that is already included on the form). If there is enough money in the paying account and the transaction can otherwise go through, the server subtracts the amount from the payer's account, adds it to the payee's, and generates a transaction record for each, so that their owners can obtain accounting and other reports whenever they want them.
And anyone with a smart code can receive payment not only from other smart codes but also from credit or debit cards, or other means of online payment (subject to restrictions -- which will be necessary since the organization running the server might have to pay disputed charges). This is because the organization that runs the server that manages the codes only has to set up an account with each payment system once, and then can process payments for thousands of different codes. The code owner gets the money, but never sees the credit-card or other payment information. Such payment processing is already routine; for example, anyone with just an email address can receive limited credit-card payments through PayPal. But as we will show, smart codes can offer a world of flexibility and services that credit cards and PayPal cannot.
Anyone who has a smart code can reach that code's control center on the Web (by going to https://www.codeserver.com, where "codeserver" is the site that manages the codes, and entering the smart code into a box provided on that site). At the control center, dozens or hundreds of options and services (financial or otherwise) that are provided by the server, can be set or changed for that code.
Most importantly, the control center allows the code owner to have the code reproduce any number of "children" smart codes, which by default inherit the options and services of their parent -- and part of the parent's money, if the owner chooses. These children are fully powered smart codes that can also reproduce, through any number of generations -- forming family trees of related accounts that can evolve through practical use. Servers can program new options into their system at any time, even after their codes are already in widespread use (the new options are turned Off, meaning no change in existing operations, until code owners turn them to some version of On).
Some options may restrict codes in ways that are binding on all future descendents. For example, restrictions might be necessary on the amount of money that could be handled, or the forms of payment that could be accepted, until the code owner had established trust in some way (PayPal uses such a system). Another example: smart codes could be limited to paying a secret list of smart-code payees, and be worthless otherwise; these codes might be emailed or otherwise distributed without encryption or other security, since they would usually have no street value. Any such restrictions would have to be binding on all children and descendents of that code, or they would be meaningless because they could easily be evaded.
These payment smart codes must have names (the codes themselves) that are hard to guess; otherwise, anyone could spend the money they contain, or change options at the control center. For most purposes, 12 random digits will be enough; this allows up to a million codes to be issued, with the odds against a guess reaching any of them being more than a million to one. But users can create their own names if they prefer (as long as the name is not already in use on that server); these can be alphabetical and of any length.
A special kind of smart code, called public codes, can be freely published and distributed; these should have names that are easy to remember (not names that are hard to guess). These codes can never pay any money; they can only receive money (which immediately credits their parent code, which remains private).
Every public code automatically has a public Web page that the owner can customize by pasting text, pictures, or other information into it. Usually a public code will be embedded in a Web link, so that users can reach that code's Web page by clicking on that link just like any other Web link -- without needing to know about smart codes at all. This page could automatically provide many payment options that the donor or customer could choose (as noted above), without the code owner having to do any work to set them up.
Each server will be able to manage many thousands of codes, and offer smart-code service throughout the world, even to people using different languages and currencies. International users will be able to change their choice of language and currency if necessary at their code's control center, from among supported options. Smart codes do not do language translation, but could provide system messages in many languages -- and also standard business phrases, allowing anyone to click a flag on a public-code site to refresh the display with all those phrases in their language of choice. All the work is done on the server; usually smart codes will not need to run any software on the end user's computer.
International transactions will also benefit by reduced cost of currency exchange, since many currency conversions among buyers and sellers will tend to balance each other, and therefore be essentially free (as noted below, the processing cost per smart-code transaction will probably be less than a tenth of a cent). And if the owner of the public code checks another box at the control center, users of the Web page will also be able to click on a row of currency symbols to re-display the page showing only those payment options available to them, and any rules or regulations that apply.
Note that each server might only issue a few codes, which could reproduce into millions if the code owners and their business or social networks wanted that many. The server might charge a small fee for each new code created, to prevent uncontrolled growth.
As we noted at http://www.MicropaymentSmartCodes.com, codes from different servers can be compatible (buyer on one and seller on the other can do business) if the organizations running them agree to handle each others' codes. Usually this is true even if the different servers have seemingly incompatible code formats, and no agreement on technical standard in advance.
This smart-code design provides unprecedentedly flexible financial accounts that can be created, have children, be shaped for special purposes, or die, in an instant. The children can inherit dozens or hundreds of options and services (financial and otherwise) that the server has made available, creating family trees of accounts that evolve as users' needs change. End users will have ultimate control over most of these options and services, in case they want to make any changes -- but in practice they may never need to change anything or even know that the control center exists. This is because smart codes will usually come into their lives not randomly, but through business or social networks, or for special purposes. So all the options an account owner needs will often have already been set by other people, in ancestor codes, before the new code was born.
Smart codes will have many uses besides fundraising. For example, they could let artists and performers even in remote villages (far from any computer or online access) sell downloads of their work through social networks worldwide -- with the help of someone who records and edits the work at the scene, and later uploads it and sends "smart links" to people likely to be interested. (Smart links are smart codes embedded in Web links, allowing people to use them without knowing anything about smart codes; in this case they will keep track of how many prepaid downloads are available free -- or subsidized at any level desired, which can vary from moment to moment and from donor to donor -- and provide other services as well.) The income, mostly from donations/sales in rich countries, could be an important source of support for people who otherwise have no good opportunities.
The artists' codes could even deduct and make tax payments automatically as sales happen. Smart codes will also be able to mail paper checks, through contracts between the server and various office or management services; the code owner can select these at the control center. The codes could automatically send income to artists or their villages, probably at certain intervals or when certain amounts had been reached, through whatever channel seemed best.
Some of the most important business and fundraising uses for smart codes (including three of the four fundraising scenarios below) have no need for any critical mass of users. They will work perfectly well even if only one person or organization in the world were using smart codes, and no one else had ever heard of them -- greatly facilitating the introduction of this technology.
Smart codes are ready to use immediately. There are no user names or passwords to remember (the code itself is both). With smart codes there is no need to register, open an account, or log in. Once you get a smart code (from a friend or colleague, or from the Web) you can spend its money, or create public codes to receive money from anyone.
When you get a new smart code, you can go to its control center to change its name -- assuring that only you and the server have the code, and the person who gave it to you does not. In fact, for additional security, the server can recognize your code by a "hash" function, without even keeping a copy. In that case, short of sophisticated tapping of secure online communication, you will have the only copy of your code in the world.
The big security problem today is "phishing" -- getting people to submit personal financial information to fraudulent Web sites posing as those of financial institutions. Smart codes do not need any personal information, so the code itself is the only target for phishing -- and owners can keep any large amount of money in a code they never use except to reach its own control center, and generate smaller children codes for everyday use. Smart codes can provide other unique anti-phishing measures as well -- in addition to benefiting from the standard precautions that everyone should take to protect all their accounts.
Another security feature is that a smart code can be cancelled instantly at little or no cost in case it has been compromised -- either online, or by telephoning a number provided by the server, and entering the code. Usually the parent code receives the remaining money in case of cancellation, but the owner could make other arrangements through the control center.
What if you lose the code -- the world's only copy, so it could not be replaced? One approach is to use the control center before the code is lost to create an alternate name (an option the server should provide), and put it in safekeeping for emergency use. Using the alternate name you could cancel the lost name (in case somebody finds it and tries to use it), create a new name for yourself, and put the alternate back into safekeeping.
Usually it is a hassle to donate money to an organization through its Web site. Typically only one or very few forms of payment are accepted, and often multiple pages of paperwork are required to pay any money. PayPal costs a minimum of 30 cents and credit cards cost more, so small donations (such as $1 or less) are not practical. Smart codes can solve these problems.
To start fundraising with a smart code, go to its control center and have it reproduce a public code -- a restricted smart code that can only receive money and transfer it elsewhere, but never spend it. You can give that code any name you choose (if it is not already in use on the server) -- and also copy text, pictures, or other information into the Web page that every public code automatically has. The address of your new Web page will be something like www.codeserver.com/project, where "project" is the name you chose for the smart code you created.
Usually each public code will be used for a particular fundraising campaign or merchandise offer. The original smart code can produce any number of public codes for different income streams (such as different fundraising appeals or merchandise offers), each with its own automatically generated Web page that can provide your information to the public, and accept many different forms of payment. To reduce squatting (hoarding desirable names), the server may offer one or a few free public codes with each new smart code, and then start charging for them.
Smart-code names could suggest the campaign or other offer. Or you could use your email address as a smart-code name to receive payment; hopefully no one else would be using it.
You could even check a box at the control center and have each Web page include a public, color-coded display through which donors can see the fundraising progress so far, and watch, in cartoon or graphic form, their own contribution going into the pot -- assuming that this service had been programmed in the server, as it probably would be for fundraising use. You can place links to the donation pages on your regular Web pages, in emails or blogs, in print, etc. Donors who contribute through these smart links don't need to have any smart codes, or have ever heard of them.
Incidentally, Web pages for public codes (and for smart-code control centers) are dynamic, generated "on the fly." They don't exist at all except when someone is using them.
How many times have you seen something you liked online, and wished you could donate a dollar or two or maybe five dollars for encouragement? And how many of these times have you actually donated nothing? Probably 100% -- meaning that you have given zero to these causes you wanted to support.
Organizations might work together to tell potential donors that if they get a smart code, they can easily donate small amounts whenever they want to, to any organization that is using smart codes. Just click the standard donation link, paste the smart code into a box provided for it, and click to send the payment. The payee will get the money, but never see the code. Only the server will see it. Optionally, the code could be restricted to donate to only a certain list of organizations -- guaranteeing tax deductibility, for example, and making the code worthless if stolen (although the owner could cancel the code, transferring its money to another code the owner controls). Accounting records could automatically keep the information needed for claiming the tax deduction, and smart codes could include an option to automatically print acknowledgement letters composed by the recipients -- just one of many kinds of accounting reports available at the code owner's request.
The estimated processing cost of a smart-code transaction (based on U.S. commercial Web-hosting fees) is less than a tenth of a cent, regardless of the amount of money paid. Even small donations like 20 cents become available for constructing rituals of community and participation.
A common argument against micropayment is that even if a purchase price is very low, there is still a mental cost of making the decision, and this cost is not reduced proportionally. That argument does not apply here, where the donor is already inspired to contribute some amount, no matter how small, often within a social ritual of participation and encouragement; the mental decision has already been made, and smart codes only make it feasible to carry out. Unlike a purchase, a contribution gives the donor full control of the amount. For various reasons the mental-cost argument against micropayment does not apply to any of the four smart-code scenarios in this paper.
In the U.S., individuals donate far more money than all the foundations and corporations put together. Most of it goes to religious organizations. Maybe that is because they provide a convenient way for people to donate either large or small amounts, and are regularly in touch with their members.
See The Economist, July 16,2005, "The Glue of Society" (subtitle, Americans are Joining Clubs Again), pages 13-17 of a separate "A Survey of America" section. Note the last few paragraphs on megachurches. One of the largest "has 2,600 small groups, coordinated by 9.200 ministers, for its congregation to join -- for computer nerds, cyclists, knitters, you name it." Yet this church held its first service only 25 years ago.
Many donors to service organizations have been offended by getting too many fundraising letters -- seemingly contradicting the idea that being in touch regularly is important. But a pressure-free link to an attractive Web page, for those who want to use it, should be OK to include with material that people are reading anyway.
It is important to develop a basis for personal involvement -- not just a horror story and request for a check. "The Glue of Society" notes that while "the old clubs had many functions, social, recreational, and professional" and were funded by membership dues, the new organizations "were professionally led advocacy groups" funded by foundations or direct-mail appeals, with little or no network of local chapters. They seem to have failed to meet peoples' needs -- so the megachurches and other things are growing to fill the gap.
Today, millions of people assemble at the same time in various locations worldwide to listen to concerts for good causes. But except for the money, which may accomplish fairly little, there is seldom much practical followup, exposure to the actual work of the cause, which would provide opportunities to consider long-term personal commitment. How could this change?
One way to support followup would be to integrate the music with a family of related Web pages where people could donate money directly to specific projects, or help as a volunteer in other ways. The format for a public-code Web link will be www.campaignzz.org/project. Therefore one word of a Web addresses could be included in campaign songs or other materials; if the name of the server for the overall campaign was well known, only the name of a particular project within it would need to be sung. Singing one word, chosen to fit the music and the cause, could get listeners to the Web address for donating money or volunteering.
A great practical value of including a site name is that then a song that may move people does not have to carry along followup information separately, on the side. Wherever the music goes (concerts, radio, Web sites, podcasting, links in blogs or emails, informal performances, or otherwise) a link for involvement in helping the cause is right there, part of the art itself -- a bridge connecting the music world of personal and group feeling with the practical world of personal and group action.
Smart codes are not required to do this, but they make it easy to have Web sites with short, consistent, memorable names. If the server is well known, only the public code needs to be sung. Also, smart codes would automatically provide multiple payment options, in a consistent, familiar format.
Could volunteer signup and involvement options, so often botched, also be designed right -- and included in smart codes as boilerplate that could be modified for the needs of each organization? The possibility is worth exploring.
This scenario may seem bizarre, and I am the first to admit that it might not work for people. But I believe it will help raise money for potentially historic organizations (and in AIDS, that is all of them). Certainly it will work technically, cost very little, and easily fit with conventional fundraising. It only needs smart codes -- plus archival arrangements (using incorporation, endowment, insurance, backup, and other methods) for credibly keeping these smart codes active and publicly accessible for decades or even centuries, on the Web or its successors.
Each donor of money, volunteer time, or other goods could be given a smart donation code dated that year, acknowledging the donation forever. This code would hold historical information from that year, such as text, pictures, music, or video interviews with participants who might note how the funding was used. The donor (or any other owner of the donation code) could control the private or public display of this information through public codes, which the owner could change or withdraw at any time. Also, the donor could add his or her own information to the code, becoming part of the code's history -- added layer after layer by successive owners, and ultimately making each code unique.
If an organization had major success within the year, and did well in telling and recording its history through the hopes and dreams of participants, the value of its donation codes would likely rise, especially for that particular year. Also, large donations would usually be rare, so their donation codes would be worth more.
Could these digital artifacts -- exclusive access to rare, ultimately unique, historic codes -- develop market value to collectors, like a rare stamp or coin, that might become much greater than the nominal value (the amount of the donation, in this case)? If so, then each donation could become an investment as well, creating an entirely new incentive to give.
But could codes develop value as collectibles, without any physical object? No one knows until it is tried, but there is a strong case that it will work. This is a digital age, and everyone knows that codes can have value. Donation codes controlling access to video, etc. can hold far more historic information than a stamp or coin. Also, everyone involved will have their own reasons for wanting this fundraising method to work -- the organizations that receive the money originally and want to encourage donors, the donors who get the codes as a benefit and want them to be valuable, the participants recorded for history, everyone who wants organizations to do better in telling what they have done and why, and of course the organization's clients, who benefit from funding for services. And collectors may compete with each other to own all codes for a certain year or historical period that was particularly significant for an organization -- greatly raising the prices of these investments.
Also, many people who want to donate may need an "excuse" -- a token that is special, memorable, and potentially valuable for themselves, so that they do not feel they are pouring money meaninglessly into an ocean of needs and appeals. And it helps that these donation codes will require the contribution by a deadline, the end of a historic year -- or the chance to receive a free donation code from that year will be lost forever.
Smart-code software will be easier to write than one might expect. For example:
(1) It can run entirely on the server and does not need to run any software on the code owners' computers -- avoiding hassles, and making smart codes compatible with any operating system, any browser that provides secure communication (only occasionally necessary, it turns out), and any telephone (with or without email, SMS, or Web access).
(2) Code reproduction may seem complex -- but it is not. Each code will be one record in a database on the server, and reproduction will consist mainly of copying that record, plus changing a few obvious fields like the name (the code itself, which must of course be different from any other code on that server).
(3) Codes on different servers can be compatible (buyer using one and seller using the other can do business) through a communication protocol that sits on top of the different servers, and delivers each code to the server that issued it, to be charged by that server. This is true even if the different servers have few or no technical standards in common (for example no agreement on code format). So smart-code servers can proceed into practical use, without waiting for agreement on standards.
Could something so easy do so much, yet not have been invented already? Yes, for two reasons. First, this system of computer-controlled money could not have worked at all until recently, when Web access became widely available. Also, today's business mindset would be unlikely to invent it, due to the focus on registering each user. Conventional registration destroys the flexibility of account reproduction, with its inheritance of options and service. And without inheritance, the control center with dozens or hundreds of services would be unfeasible, as codes could not evolve in the community without the tedious work of manually setting the options required for each new code.
I have developed this design for a year and a half, and have not found any fundamental problem with it. If you think that anything here or on the Web site below could not work as described, please let me know at aidsnews@aidsnews.org. If I'm wrong about the potential of this smart-code design, that should become evident quickly in a wider conversation, so not much effort will be lost.
I want to facilitate a working or advisory group to improve this smart-code design for fundraising and other purposes, and explore options for developing the idea without restricting public access and use. You can reach me at aidsnews@aidsnews.org
For more information, see http://www.MicropaymentSmartCodes.com