Micropayments: A New Solution

Dept. of CIS - Senior Design 2009-2010

Noah Ready-Campbellanoah@seas.upenn.edu

Nate Conradconradj@seas.upenn.edu

Zachary Iveszives@cis.upenn.edu

Jonathan Smithjms@cis.upenn.edu

ABSTRACTToday, almost all web services rely on advertisements forrevenue. Though this model has been successful, it can beintrusive to the user experience, and therefore is ill-suitedto many services. One solution that has been put forth ismicropayments, i.e. small scale payments typically valuedat less than one dollar. Such payments could be for itemssuch as digital content and premium web services. Thoughmicropayments offer much theoretical promise, all attemptsto-date have failed. However, due to recent social and tech-nological developments, we believe that the situation is dif-ferent now. Using an approach with capacity to function inboth the short term and the long term, we plan to create aviable method for micropayments to finally take root on theInternet. Such a creation would allow entirely new marketsto emerge.

The solution we propose to fill this void is BitNickelTM,a micropayments system designed specifically to address thefailures of past attempts and to provide a platform for futurescalability. The overriding design principle of the systemis its ease-of-use, both for merchants and users. To thatend, it employs a simple, light-weight interface that requiresminimal user input and navigation, which we believe is thekey to capitalizing on this opportunity. It also uses severaldifferent strategies to minimize the costs associated with eachtransaction, thereby enabling the profitable implementationof the system.

1. INTRODUCTIONSince the first years of the World Wide Web, businesses

have tried to make a profit from it. Given the initial lackof trusted payment systems, digital cash became one of thehottest topics in the Internet sector in the mid 1990s. Dozensof papers were published on the subject, and companies werestarted to solve the perceived difficulties, including Digi-Cash, Trivnet, and CyberCash. Most of these attemptsfailed or faded away as users became familiar with and trust-ful of simple online credit card processing. Despite inherentshortcomings, including insecurity and unwieldiness, creditcards were good enough for most transactions, and their in-cumbent advantage simply proved too great to overcome.

Though most of these attempts were directed at simplyreplacing the credit card for standard ecommerce purchases,one subgroup was aimed at a slightly different need: micro-payments. Micropayments have been variously identified asbeing less than one cent all the way up to less than five dol-lars, which is the accepted definition today [4]. Credit card

fees are generally too high to make such transactions prof-itable for the merchant, so a fundamentally different solutionwas needed. However, again, most of these early solutionswere met with failure. Typically they required that userssign up and use a new currency, and user adoption was amajor hurdle to growth. Indeed, these initial failures haveprompted some to argue that micropayments are simply un-necessary in the digital economy [15].

1.1 A resurgenceHowever, there are signs that this view is misguided. Cell

phone-based payments, most of them being micropayments,have taken off in many overseas markets; in South Korea,for example, they account for over 70% of online payments[2]. Within the U.S. resides Apple’s iPhone App Store [13],where users pay small amounts for simple iPhone applica-tions via their iTunes account. Apple recently announcedthat more than 2 billion apps have been downloaded, withthe market worth up to $500 million annually [16]. We be-lieve that the resounding success of such markets indicatesthat micropayments deserve a second look. Just as YouTube[3] and Facebook [27] only triumphed after a slew of earlierattempts, there is the potential for a modern micropaymentssolution to finally take hold. The remainder of this paperis organized as follows. In section 2, we discuss work donein the field related to our project, particularly pertaining toa company with a very similar idea. We emphasize theirmistakes and how our approach differs. In section 3, wegive a high-level overview of our system. Sections 4 and 5delve into more technical detail about each of the main seg-ments of our project. Following that, section 6 discusses thegeneral results of the project in terms of areas of successand areas for improvement. Section 7 covers possibilities forfuture work, and finally, section 8 draws a variety of con-clusions on the feasibility of our system and infers variouspossibilities.

1.2 A micropayments solution

Figure 1: BitNickelTM logo

The BitNickelTM solution presented in this paper lever-

ages one of the key insights that can be gleaned from pastattempts, namely that social and legal hurdles, rather thantechnical challenges, are the main barriers to acceptance ofa new payment system. More specifically, this paper pro-poses that customer adoption is a more important factor forsuccess more than merchant or financial institution adop-tion. This insight is what enabled PayPal[10] to triumphand has allowed Danal Co [2], the largest of the Koreanphone payment companies, to flourish, despite the higherfees it charges merchants and the logistical troubles its hadwith telecom operators. Naturally, in order to capitalize onthis realization, a robust technical foundation is necessary,and the remainder of the paper is devoted to its discussion.

1.3 Micropayments applicationsAt first glance, this idea may not seem to have many uses.

The Internet has survived without them thus far, one maythink; why do we need them at all? First, consider an in-ternet service that currently generates revenue using ads.Take Pandora [20], an online radio service, for example:Pandora periodically interjects short commercials betweensongs. With our product, users could opt to pay only afew cents to skip ads for a month. Even more, they couldperhaps pay to unlock extra functionality, such as selectingsongs explicitly. This sort of application also easily fits withonline video streaming, such as on Hulu.com [14], or anymajor media site that currently injects ads into the prod-uct.

On another front, consider Facebook’s gifts: users canpurchase special virtual gifts to send to other users. Buthow many people actually pay a dollar to send a virtualimage? Though there is no public release with data on thematter, the rare use of the feature becomes apparent aftera few minutes of checking profiles. Part of that may be dueto the price, but another part of it is almost certainly thehassle of entering payment information.

Other applications include charging for downloads of bothdesktop and mobile applications. As illustrated by Figure2, users already show a strong preference for micropayment-scale transactions in the iPhone app store, with the prepon-derance being priced between zero and two dollars. Analystsattribute this fact to the integrated purchasing experience,and even name this feature as a central reason for the plat-form’s success [19].

Figure 2: Number of iPhone applications by price[12]

Finally, potential applications include fees for website reg-istrations, charitable donations, and other such small digitaltransactions. The list could go on, but this at least demon-strates the broad potential usage of a viable micropaymentsystem.

2. RELATED WORK

2.1 Security and trustInitially, security and trust issues were viewed as perhaps

the largest barrier to the adoption of online payment sys-tems. The works of McKnight et al. [5] and Egger [8] con-sider the fundamental necessity of trust within a marketand specifically examines consumers’ different psychologicalpropensities to trust. They advance models and techniquesfor extending such trust to the ecommerce setting, therebyremoving barriers to trade. Other papers focus on the tech-nical basis for such trust, for example appropriate crypto-graphic techniques, such as those discussed by Chaum et al.[6]. However, much of this research is somewhat outdated.Consumers have become accustomed to the idea of the In-ternet as a transaction medium, and the use of it as such isextremely prevalent [4]. It can be expected that this com-fort will only increase, making consumers more receptive toa new payment system than they might have been earlier.

2.2 Transaction efficiencyA second major focus of earlier research has been trans-

action efficiency, which is more directly targeted at micro-payments. Clearly, transactions must cost less to processthan they are worth to the engaging parties otherwise themerchant will simply lose money on every sale. Yang etal. [26] consider several different peer-to-peer techniquesdesigned for minimizing resource utilization. They acknowl-edge that such techniques are less robust than some alterna-tives, but also note that individual errors or cases of fraudare unimportant on the micropayment scale, and that large-scale fraud trends can still be identified and stopped. This issimilar to the fraud approach used by credit card companies.Rivest [21] uses a probabilistic model to aggregate micropay-ments into larger transactions, thereby lowering the averageprocessing cost. These discussions are more applicable totoday’s issues, but are still somewhat off the mark. Rivest’smodel is necessarily difficult to implement in practice, whenthere are refunds and processing errors to consider. Thecosts Yang et al. consider apply most to the sub-cent trans-actions, which are impractical anyway, as discussed in thenext paragraph.

2.3 Psychological transaction costsThe question of psychological transaction costs, a con-

cept referring to the mental burden placed on the user tocomplete a given transaction, was only considered relativelylate in the development of micropayment systems. Lesk [15]notes that many of the early micropayment systems aimedat sub-cent transactions, e.g. for a single page of an article,added additional psychological transaction costs which out-weighed the value of the transaction itself. It is simply toomuch hassle to evaluate whether it is worth reading the nextpage of an article at every turn. However, for larger, more-targeted micropayments, this argument has been shown em-pirically false. Nascent markets, such as those found in

South Korea and the App Store, both discussed earlier,prove the willingness of consumers to engage in transactionsat this scale. Additional examples in the domain of mas-sively multiplayer online role-playing games (MMORPGs)and other games further demonstrate this point.

2.4 A similar attemptThere is one previously attempted micropayment approach

which we consider very promising, and on which we base thesolution presented in this paper. The attempt was made byTrivnet [17], an Israeli company which has since moved intothe mobile payments space in Europe and Asia. Trivnet’sproduct was launched in 1998 and was a back-end paymentsserver it licensed to internet service providers (ISPs). Af-ter set-up, the server allowed the ISP’s customers to makecredit card-less payments to participating websites, with thepayments appearing on the customer’s monthly Internet bill.

From a technical perspective, this product is very simi-lar to that outlined in the next section (though it lacks theauxiliary credit card-based service). However, from a busi-ness perspective, Trivnet made several inadvisable businessdecisions. First, it positioned the product as a conveniencefeature to help service providers draw new Internet servicecustomers rather than sharing profits with the providers,which is largely wishful thinking, given the public’s view ofInternet service as a utility. Trivnet’s model contrasts withthe model outlined in this paper, in which a per-transactionfee given to the ISP, with such revenue contributing mate-rially to the ISP’s top line. Second, since the product waslicensed, it left the burden of business development on theshoulders of the ISPs. Trivnet simply did not do enoughto develop relationships with merchants, which significantlycurtailed the value of its offering. Trivnet’s final failing wasout of its control: it was too early. The Internet has evolvedsubstantially over the last eleven years, and many of today’smost popular services, such as Wikipedia [25], could neverhave existed then.

3. BITNICKELTM OVERVIEWWe propose BitNickelTM, a system specifically targeted

at micropayments, particularly focused on ease-of-use. Thebiggest step towards ease-of-use, in our minds, is the abilityto complete the entire transaction without changing webpages. Evidence for this convenience as the centerpiece ofa good web interface can be found easily by looking at theresults when it is absent. According to a recent study, over60% of shopping carts are abandoned [11], while anotherstudy estimated it as between 60% and 70% [7]. Why are somany abandoned? Because navigating through pages andpages of payment, billing, and shipping information is slowand clunky, particularly on older computers and internetconnections. Another major problem is that users are oftenrequired to register before making a purchase or because theprocess is too long and confusing [24]. Users want to enter aslittle information as possible on as few pages as possible in asshort a time as possible. Given these conclusions, through anentirely client-side JavaScript implementation, our systemallows the user to do exactly that.

Our system is initiated by a button; clicking on the but-ton creates an overlay interface, and the entire transactiontakes place there. The overlay features two payment meth-ods: payment by ISP and payment by credit card. Pay-

Figure 3: User experience flow chart

ment by ISP consists of appending the charge on to theuser’s monthly Internet bill. Essentially, as long as the cus-tomer’s ISP has technical support for our product, the usermust only enter the last four digits of the billing person’s so-cial security number for identity verification purposes. Afterchecking the identity with the ISP, the system then trans-mits the charge to the ISP for handling and confirms thepurchase to the product server. Credit card is included toallow users with ISPs that have not added our functionalityto use our system as well. The form for such payments isfairly standard, but one key feature is that the credit cardscan be saved, not only for that particular webpage, but forall websites that use our overlay. Furthermore, rather thanperform the credit charge instantly, payments are buffered.This is done because the average micropayment is so smallthat hardly any revenue would be generated given the sub-traction of the credit card company’s fee. Instead, creditcard billing is on a monthly basis.

4. FRONT-END IMPLEMENTATIONThe overlay, implemented entirely in JavaScript, features

two tabs. The user can select either the “Credit Card” or“ISP” tab. Merchants, upon creation of their custom but-tons, actually have the capability of disabling either of thetabs. While it’s unlikely any would want to disable the ISPtab, the credit card tab may be disabled because credit cardcompanies take a relatively high cut of the payment. Such adecision would unlikely take place unless a large populationof ISP’s supported ISP payment.

4.1 Payment by creditThe credit card tab, illustrated in Figure 4, loads previously-

saved credit cards, allowing the user to quickly choose one orto enter another. Saved cards can be protected, as there isa password field users can set to be required for use. Creditcards, when saved, are serialized to strings, encrypted, andstored in cookies. This storage allows them to persist be-tween uses and across websites, so that a user must only en-ter his credit card once on any website to be able to quicklyuse it again, anytime and anywhere. The encryption of theserialized string prevents attackers from extracting creditcard data from the cookies.

The overlay uses the Luhn Algorithm [9] in order to pro-vide a best-effort credit card validation measure. The algo-

Figure 4: Credit Card Display

rithm is a simple checksum that was developed by IBM andpublished in US patent 2,95,0048 ”Computer for VerifyingNumbers” in 1960. It is designed to ensure that no dataentry errors or random spoofing of credit card numbers ispossible. Credit card companies choose issued numbers insuch a way that they pass the checksum.

The actual implemented system uses a two-step creditcard verification process before a charge is accepted. First,the card number is checked with the Luhn Algorithm, andthen it is checked against an actual credit card process-ing system. The two-step process is desirable because suchcredit card validations typically are time and resource in-tensive, and may even cost a fee. The Luhn Algorithm,in contrast, provides a free, light-weight verification step tohelp reduce the number of full-scale validations needed.

4.2 Payment by ISPThe ISP tab, shown in Figure 5, is far simpler in ap-

pearance. The first components to notice are the statementcontaining the client’s domain name, Internet Protocol (IP)address, and ISP. The other main feature is the input boxfor the last four digits of the social security number.

Figure 5: ISP Display

In a process shown in Figure 6, the overlay automaticallyperforms a reverse-DNS lookup using the user’s IP addressto determine the user’s ISP. The user then must enter thelast four digits of the social security number of the personresponsible for the internet bill. This required input is to

prevent charges from accumulating on public or insecure net-works, since knowledge of the person’s social security num-ber indicates either a close relationship or identity theft; thelatter case would have far more serious implications than ahandful of erroneous micropayments.

Interestingly, the overlay must be implemented very care-fully in order avoid destroying the DOM of the site in whichit is embedded. Specifically, when using the JavaScript doc-ument.write() method to add new scripts, the opening andclosing tags "<script>" and "</script>" must be brokenup into separate strings for writing, "<scr"+"ipt>" and"</sc"+"ript>". This methodology departs from the offi-cial HTML 4 specification, but is required due to the mostcommon browser parsing libraries. As a matter of expe-diency, the browsers parse the tags too early, in order toachieve a small speed advantage. Clearly, however, this candramatically revise the intended layout of the page, and re-sult in a variety of issues[22].

Figure 6: ISP Flow Process

4.3 Phishing protectionOne of the major security vulnerabilities associated with

a system such as BitNickelTM is that users interact with thesystem via a widget embedded on third-party sites. Thisopens up a potential avenue for malicious attacks known asphishing, where a malicious entity poses as a trusted par-ticipant in the transaction in order to extract informationfrom a victim. Specifically, an attacker could duplicate theappearance of the BitNickelTM JavaScript button and over-lay, put it on an ecommerce website, and use it to extractcredit card information or social security digits from unsus-pecting users.

This vulnerability is common on the Internet, so thereis also a common solution, typically based on a public-keycryptography. In a common implementation using the RSAencryption scheme, a public key is sent from the server tothe client. For phishing to work, the entity must supplya public key for which it knows the corresponding privatekey. To prevent this, trusted companies such as VeriSign[18] use cryptography to sign and approve the true publickey from the server. This guarantee cannot be tamperedwith, so an entity attempting to use phishing to deceive auser would be unable to provide a valid VeriSign certificate.This functionality is demonstrated in the flow chart of Figure7.

Figure 7: Protecting BitNickel From Phishing At-tacks

4.4 Input sanitizationFinally, for both security and stability purposes, the over-

lay intensely sanitizes and validates all inputs. Symbols thatcould not be part of any valid input block form submission.Symbols that could be valid are escaped with a backslashto prevent them from interfering with the database. Thiscombination of sanitization and validation prevent SQL in-jection attacks, wherein an attacker uses malformed inputsto interfere with or hijack SQL code.

This sanitization forms an important component of theoverall security architecture of the BitNickelTM. In a re-cent security report published by Symantec [28], cross-sitescripting (XSS) was listed as the most prevalent securityvulnerability of all known attacks. XSS is typically enabledby allowing unsanitized input from users, which is then pre-sented to other users within the context of the original site,and with the same-origin privileges. Consistent and rigoroussanitization of input prevents such attacks, and thus cuts offan important attack vector.

4.5 Front-end designCode modularity is an important feature of the front-end

design. The website, shown in Figure 8, makes heavy use ofCascading Style Sheets (CSS) as well as JavaScript in orderto create an appealing user experience –a critical componentof success in the competitive online billing market. Each log-ical component of the CSS and JavaScript is broken into itsown server-side file, which is then linked to the appropriatePHP-rendered HyperText markup language (HTML) by theuser’s browser. This design minimizes redundant file trans-fers and also caters to browsers’ caching systems, simulta-neously achieving user experience goals and minimizing thestrain on the web server. Moreover, as demonstrated in theserver-side domain in the following sections, the correspond-ing reduction of the code base improves the robustness of thecode.

4.6 Future interface developmentThough the system does not currently support actual charg-

ing of credit cards and payment via ISP, the remaining tech-nical steps to do so are trivial. The only remaining techni-cally complicated task is to shore up security. A good firststep would be to use Hypertext Transfer Protocol Secure

(HTTPS) instead of simply HTTP. HTTP adds TransportLayer Security (TLS) and Secure Socket Layer (SSL) au-tomatically to all communication. This would give a goodbasis of security which could then be substantially improvedusing the encryption scheme we designed over the course ofthis project. As illustrated in Figure 9, the server transmitsa public key to the client, which then encrypts everythingstored locally.

To make communication safe from replay attacks, therewill also be an encrypted signature in all packets containinga timestamp, a MAC or IP address, as well as perhaps someother information as needed to make it verifiably authen-tic. While this system could have been implemented duringthis project, no custom encryption scheme can be consideredsafe unless it has been subjected to an intensive review byexperts. Even then, there can often be vulnerabilities. Con-sequently, for the purposes of this project, it seemed best tosimply design the scheme but leave its implementation forfuture work.

Figure 8: User-facing website

The other main tasks to complete are the transmission ofISP charges and the framework to give permission for prod-uct delivery. For the former, all that needs to be done is lookup whether the user’s ISP is compatible with our product,and if so, securely transmit to the ISP the payment infor-mation. For the latter, a cryptographically signed certificatecomposed using keys known only to the BitNickelTM serverand the product server. The client would get the certifi-cate from the BitNickelTM server and post it to the productserver. The product server would check the certificate, andupon its successful verification, would then deliver the prod-uct.

5. BACK-END IMPLEMENTATIONThe website, as illustrated in Figure 8, has been created

for important tasks such as custom button creation and ac-count management. Such features are integral to the ideaof this project. Since such features cannot exist without awebsite to serve them, we constructed a user-facing informa-tional website for the project. It is dynamically served, usingthe recursively-named PHP: HyperText Preprocessor (PHP)server-side scripting language. Different logical divisions of

the website are distributed across different PHP files, witheach being included in the necessary user-accessible scripts.This model maximizes code re-use, which makes implemen-tation more efficient and extensible, as well as more robust,since re-implementation of similar features increases the like-lihood of bugs appearing. Furthermore, this design decisionwill enable integration with the MySQL relational database,as the PHP/MySQL web services stack is highly optimizedfor efficient serving.

Figure 9: Credit Card Flow Process

One current note about the website is that, while it islisted at a custom domain, www.bitnickel.com, it is hostedon a University of Pennsylvania server. This is accomplishedusing DNS masking; this basically shows a frame of the un-derlying site to any visitor of the domain. The URL bar ofthe browser will not reflect the actual page viewed on thewebsite due to this setting. This problem is merely due tothe current hosting situation, and would not actually affecta realization of the project, though.

5.1 Database backboneThe crucial functionality of the website relies on a MySQL

database. Depicted in Figure 10 is a visualization of thedatabase model for the future of the website. Currently,there is no account management page implemented, so thedatabase model actually used does not support such a fea-ture. The changes needed to allow account management arenot particularly complex. To facilitate future work contain-ing this feature, we have created a model that would allowit. The model is located in the Appendix, Figure 14.

An important security note for this database model isthat only a hash of the password for each account shouldbe stored. Storing only a hash prevents database intrusionfrom allowing passwords to be stolen. Even if an attackercopied all of the password data, a cryptographic hash is one-way –that is, the attacker cannot use the hash to determinethe original password. Therefore, the attacker would not beable to hijack any accounts.

5.2 Button generationIn addition to a demo of the button on the website, there is

an implemented interface, depicted in Figure 11, for generat-

ing custom buttons. The current inputs are company name,domain, whether to accept credit cards, whether to acceptISP payments, and the amount to charge. In an actual busi-ness application of this project, inputs for an account nameand password would also be necessary.

Figure 11: Button Creation Form

Clicking “create” then displays a custom JavaScript refer-ence to be used to link the button. There are also directionsfor how to add it to a website, as shown in Figure 12. Thescript linked provides all of the overlay’s functionality to theHTML object implanted in the merchant’s site; it is basi-cally a reference to a PHP file on our server that accepts ahash of a button ID as a parameter. Including only a hashrather than the button’s ID itself is a simple security pre-caution to keep information that could be used in a databaseattack from becoming available. Finally, the copy button isa simple flash trick to copy the text to clipboard for userconvenience.

Figure 12: Button Creation Result

5.3 Future website developmentThe main component of future work will be an account

management section. This is what will allow businesses touse our product. Using the accounts they can already cre-ate, they can gain access to features such as the ability toview their pending revenue. The main needs would be toview current balances, check charges on each button, and tocreate new buttons on the same account.

Figure 10: Current Database Model

To implement the account management section, the firststep to be taken is to replace the current database modelwith the one found in the Appendix labeled Figure 14. Fromthere, the steps to supporting the aforementioned functionsare fairly simple. Most of what remains are basic SQL func-tions to aggregate the relevant data. Creating a webpage todisplay that data would also be fairly trivial.

In addition to the account management section, there areplenty of areas for improvement to make the website moreprofessional and useable. Such features could be added givenenough time, but they fall beyond the scope of this technicalproject.

6. USER EXPERIENCE

6.1 PerformanceFor the most part, performance in terms of computation

time is not a concern in this project. The only extent towhich it does matter is that the user interface should notbe noticeably slow. At this point, with the majority of theJavaScript to power the client written and tested, we cansay that the computation time is currently negligible, and allclient operations are essentially instantaneous. A mild delaycould arise when encryption is added, but it would certainlynot be enough of an issue to make the overlay uncomfort-ably slow. The amount of delay obviously increases withthe complexity of the encryption and the size of the key, butit is also decreases with hardware advances. Really, clientswith fast hardware should notice little delay, while thosewith slow hardware would hardly notice the time comparedto the delay of other tasks.

6.2 Client interfaceIn terms of the interface’s user friendliness, the two con-

cerns are time required for use and simplicity. Though theseare both fairly hard to determine, we have conducted a smalltrial with this product consisting of showing it to severalusers and asking them to rate it. Overall, the remarks wereentirely positive about both amount of time required andease-of-understanding. The persistence of credit cards viathe encrypted saving feature allows repeat credit card usageto be quite fast. Similarly, since the user only needs to enterfour digits, payment via ISP is also quick. Similarly, theratings on ease-of-use reflect the success of features such ascookie-based default tab selection and the credit card per-sistence.

7. FUTURE WORK

7.1 Credit card-based functionalityThe credit card processing wing of the project needs fur-

ther development in several areas. First and foremost, theencryption of sensitive user data must be strengthened andrefined. Likely this will involve encrypted cookies, as well asencrypted HTTPS transfers. This security will be basedon an RSA public-key encryption scheme where all keysare stored on the server for security. Such a design wouldcompletely protect the client-side from any vulnerability,since nothing could be compromised without the private-keystored on the server. Secondly, code must be added to actu-ally communicate with credit card companies for test debitsand routine charges. All that would be required would becode to transmit the card data to verify that the data de-scribes a valid card and code to actually charge the finalpayment. The business aspects such as what fee to pay the

credit card companies and what fee to charge as profit areleft outside of the scope of this project.

7.2 IP address-based functionalityThe execution of ISP-based charges has been left to the

future, given the inherent business-facing difficulties in ar-ranging partnerships and obtaining access to test systems.Nevertheless, leveraging the same steps outlined in Figure6, we have laid the groundwork to make such an advancetechnically easy. In short, all that remains to be done is toadd a component to the ISP’s software that receives a securetransmission of an IP address and four final digits of a socialsecurity number, verify that against billing information, andthen add a charge to the financial database. The businessaspects such as what fee to pay to the ISP and what fee tocharge as profit are left outside of the scope of this project.

7.3 Website functionalityThe main missing feature of the website is the account

management section. Much, if not all, of the functional-ity needed from the database to support such a module al-ready exists in the back-end. The key points of the ideaare the ability for a merchant to log in, to view all existingbuttons and their balances, to edit these buttons, and tomanage their method of extracting money from the buttons.Clearly, the merchant needs to be able to change settings,but the more subtle need is to maintain information aboutcustomers for marketing purposes. Though marketing is anoften trivialized field, marketers actually base decisions onraw data. The more raw data available, the better targetingis possible. The ability to track purchases and data aboutthe customers, therefore, would be invaluable to merchantsusing this service. While there are privacy concerns involvedwith the availability of this data, such issues can be handledby privacy policies and agreements. This component, how-ever, was deemed to be more of a business feature and lessof a technical feature necessary for the demonstration of ourcentral idea. It was therefore triaged to be left for futurework.

7.4 Back-end functionalityTo serve the true functionality of credit card charges, a

script must be created to automatically crawl through thedatabase periodically to check card balances and usage datesto perform the charges if the balance is over a certain pointor if the card has not been used for a certain amount of time.In a functional business, there would also be a need for fi-nancial record-keeping of the ISP charges, which is currentlynot supported. The general idea of this project is that thiswould occur on a monthly basis, but the timeframe wouldbe easily changed in the event that business decisions de-termine another choice to be optimal. Also, as mentionedearlier, a small portion of the included database model wasoptimized out when the decision was made to exclude theaccount management section from this project. To then im-plement the account management section in future work,various tables and fields must be added back in to the back-end. The work needed is fairly trivial given the databasemodel, so this should be no concern to any future develop-ers. Functions for extracting the data in useable form tosupport basic account management functions or even mar-keting research would also be relatively simple to create.

7.5 SecurityThis will be by far the largest component of future work.

As outlined earlier in the paper, a security scheme mustbe implemented to maintain the safety of the credit carddata stored locally in cookies on clients’ computers. Thissystem will most likely be a public-key scheme wherein theprivate key is stored on and never leaves the server, and thereexists a unique key pair for each client. Then the publickey could encrypt data for the cookies, and it could notbe easily decrypted since that would require extracting theprivate key from the server, assuming the actual method ofencryption cannot be broken. This proposed system wouldrequire further changes to the database backbone.

The IP-based payment, conversely, already enjoys sub-stantial security due to the nature of Transmission ControlProtocol (TCP) communication. This protocol relies on theestablishment of a socket between two known hosts, and, inorder for the communication to occur, the addresses of bothhosts must be known. This poses a significant architecturalobstacle to any would-be attacker. For example, in Figure13, an attempted attack is demonstrated, with the attacker’ssocket communications illustrated in dotted arrows, and theuser’s communications in solid arrows.

Figure 13: TCP Architectural Security

Also required is an encryption system to protect the con-tents of transmissions from the client to the server. Thesame public key as is used for the credit card storage couldbe used. What is necessary is a signature for the contents ofeach message that would prevent tampering with the valuesor replay attacks. This signature would most likely includea hash of all of the arguments, the client’s IP-address, anda timestamp at a bare minimum. The timestamp and IP-address would ensure that the message is only valid fromthat client at that specific time, thereby preventing replayattacks. The hash of the arguments prevents any argu-ments from being changed, such as the button performingthe charge. A system of this sort cannot be easily imple-mented in a secure manner. A bare minimum to attempt tocreate a secure system should include an intensive review bya panel of security experts. Every facet of the system mustbe examined.

The positive note about security in this project is thatflaws will not be instantly financially devastating. Each ex-ploitation can only cause a few dollars of damage at most,

since this is a micropayment system. Malicious entities,then, must repeat their attack many times to do much dam-age. This convenience allows for a secondary model of se-curity, in which transactions are monitored to try to detectpatterns that might indicate the system is being exploited.By inspecting the overall flow of transactions, a well de-signed algorithm may be able to discover attacks and aidimplementers in fixing security flaws before much damagehas been done.

8. CONCLUSIONSThe success achieved in the implementation of this project

puts forth the indisputable idea that a viable micropaymentssystem is within the grasp of today’s businesses, even thosewith rather limited resources. Our two-person team man-aged to create a functional manifestation of this design inwhat technology firms would consider to be a fairly smallamount of time.

While there are a variety of vulnerabilities that threatenthis idea, the project has shown that they can be overcome.As long as the field of cryptography advances and continuesto show that it can create methods of public key encryp-tion that are safe from man-in-the-middle or general crack-ing vulnerabilities, this project will be able to function in amanner that does not render insecure the client’s credit cardinformation or social security number. We have shown thatJavaScript can be used to not only create a comfortable andoperable product to manage micropayments, but that withthe current state of cryptography, that it can be a safe wayto do business.

The remaining challenges which lie outside the scope ofthis project but must be overcome to realize our vision canbe enumerated as follows.

First, this idea may fall under the reach of U.S. Patent US2002/0156696 A1. This patent makes a claim to micropay-ments systems operating over a network where involving op-eration by a service provider, including an ISP [23]. Patentlaw and interpretation falls outside of the areas of expertiseof those working on this project, so such a judgment is leftto others in the field. Let it suffice to say that we are notwholly convinced that it is covered, since our system doesn’tinvolve sole operation by an ISP. Furthermore, even if thesystem is patented, its creation and operation could still beprofitable, as was the case for Google [1] in its youth.

Second, a business must make the effort to broker dealswith ISPs for their participation and merchants for theirusage. This step is truly crucial. It’s almost something ofa chicken-and-egg problem to actually pioneer this project;it’s hard to get ISPs to add support without a customerbase, and it’s hard to build a customer base without themain convenience of this project. Such a problem raises thepossibility that only an ISP or a web merchant that couldprovide enough exposure to potential customers to enticeISPs could succeed.

Third, most, if not all, of the features suggested in thefuture work section must actually be implemented. As dis-cussed in each of the subcategories, all of the componentsother than security are relatively simple on their own. Theideas described in the security section, however, are the mostcrucial, the most complex, and the most costly to realize.We believe all of the required work to be manageable, but

it must be done well.

Though these issues exist, the key note is that they areall feasible. There are no unsolved technical issues with theideas raised by this paper. Furthermore, as time passes andbusiness settings change, it is more than probable that acompany with the ability to execute this project finds itfiscally viable and realizes our idea.

9. REFERENCES[1] Sergey M. Brin. Google. http://www.google.com/.

[2] Rebecca Buckman. Just charge it. In The Wall StreetJournal, June.

[3] Steve Chen. Youtube. http://www.youtube.com/.

[4] Marianne Crowe. Emerigng payments. Federal ReserveBank of Boston.

[5] Vivek Choudhury D. Harrison McKnight and CharlesKacmar. Developing and validating trust measures fore-commerce: An integrative typology.http://www.bus.iastate.edu/mennecke/434/S05/

TrustScaleISR.pdf.

[6] Amos Fiat David Chaum and Moni Naor. Untraceableelectronic cash.http://74.125.155.132/scholar?q=cache:ehc4cy6pUdQJ:

scholar.google.com/.

[7] eCommerce Optimization. What’s the averageshopping cart abandonment rate and how is itlowered?http://www.ecommerceoptimization.com/articles/what-

is-the-average-shopping-cart-abandonment-rate-

and-how-is-it-lowered/.

[8] Florian N. Egger. Trust me, i’m an online vendor.http://www.delijst.net/delijst/pdf/chi2000.pdf.

[9] Michael Gilleland. Anatomy of credit card numbers.http://www.merriampark.com/anatomycc.htm.

[10] Andres Guadamuz Gonzalez. Paypal: the legal statusof c2c payment systems. University of Edinburgh.

[11] Anne Holland. Study data: Absolutely pitifulecommerce shopping cart abandonment stats.http://www.marketingsherpa.com/sample.cfm?ident=

29685.

[12] IPhoneRoot.com. Iphone application pricing update.http://iphoneroot.com/iphone-application-

pricing-update/.

[13] Steve Jobs. Apple app store.http://www.apple.com/iphone/apps-for-iphone/.

[14] Jason Kilar. Hulu. http://www.hulu.com/.

[15] Michael Lesk. Micropayments: An idea whose timehas passed twice? Rutgers University.

[16] Om Malik. The iphone app market size debate.http://gigaom.com/2009/08/28/the-iphone-app-

market-size-debate-is-it-2-4b-a-year-or-250m-

admob-responds/.

[17] Amit Mattatia. Trivnet. http://www.trivnet.com/.

[18] Mark McLaughlin. Verisign.http://www.verisign.com/.

[19] John Paczkowski. Analyst: Apple iphonepopularity growing threat to videogame console makers.http://digitaldaily.allthingsd.com/20090929/iphoneos-

gaming-platform/.

[20] Inc. Pandora Media. Pandora.http://www.pandora.com/.

[21] Ronald L. Rivest. Peppercoin micropayments. InFinancial Cryptography, pages 2–8, September 2004.

[22] Joel Spolsky. Stackoverflow.com llc.http://stackoverflow.com/questions/236073/why-

split-the-script-tag-when-writing-it-with-

document-write.

[23] Mordechai Teicher. System and method formicropayment in electronic commerce.http://www.google.com/patents/about?id=BjeeAAAAEBAJ.

[24] VisibleU. Hiring the internet.http://www.hiringtheinternet.com/2008/06/19/shopping-

cart-abandonment-on-the-rise/.

[25] Jimmy Wales. Wikipedia.http://www.wikipedia.com/.

[26] Beverly Yang and Hector Garcia-Molina. Ppay:micropayments for peer-to-peer systems. InConference on Computer and CommunicationsSecurity, pages 300–310, 2003.

[27] Mark Zuckerberg. Facebook.http://www.facebook.com/.

[28] Symantec Internet Security Threat Report. Symantec.http://eval.symantec.com/.

APPENDIXA. FUTURE DATABASE MODEL

Figure 14 is the database model to be implemented in fu-ture work to support an account management page. Thoughit looks drastically different from the model included earlier,there are only two new tables and one new field in an oldtable. The added tables are the Account Table and the Ac-count to Button Map. Also added was the Account ID fieldin the Button Table. Basically, this new model simply al-lows for a series of buttons to be grouped together underan authentication method. In an actual business implemen-tation, the Account Table would also have various financialfields for the extraction of button balances.

B. LUHN ALGORITHMBelow is a pseudocode listing for the Lunh Algorithm

credit card verification checksum. There is some variationin the details of the implementation for varying lengths ofcredit card numbers, but we implemented an algorithm verysimilar to the described below.

def Luhn_Algorithm_Check(credit_no):

sum = 0

count = 0

for d in credit_no:

temp = int(d)

if count % 2 == 0:

temp *= 2

if temp > 9:

temp -= 9

total += tem

return total % 10 == 0

Figure 14: Database Model for Account Management