Many wonderful inventions fall by the wayside because their inventors have overlooked one essential factor in the success of any new enterprise: ease of migration. It doesn’t matter if the “new” is far better than the “old”. It doesn’t matter if the “new” is far cheaper than the “old”. If it isn’t easy for the consumer to make the transition from the old to the new way of doing things, then—irrespective of how wonderful the “new” may be—it will fall flat on its face. And “getting started” is the Achilles heel of e-currencies. The e-currency issuers and e-currency exchangers are turning away vast amounts of mainstream web business because between them they have constructed one of the most impenetrable and user-unfriendly methods of “getting started” that’s imaginable. But with a little effort both the issuers and exchangers could direct this missing business through their virtual front doors, adding handsomely to their profits in the process.
Let’s look at what awaits the web user who’s tempted to make a first time purchase using e-currency:
Now Luigi wants to buy a widget—the kind of widget doesn’t matter—but like most of the other billion-plus users of the Internet he wants to buy a widget, and he wants to buy it online. So Luigi makes his way to Google and performs a search, a search that returns two hits.
As far as the first hit is concerned: “It’s-a not-a quite what I’m-a looking for. Eh! And it’s-a expensive, but maybe it-a do if I-a find nothing better.” As far as making payments is concerned Luigi—like most web users—uses a credit or debit card, so he scans the page for payment methods, “Eh! There’s-a no credit card logos at bottom of page. Ah! But here’s-a Paypal.” Luigi doesn’t know much about Paypal beyond that it’s a way of paying for goods and services, and he certainly doesn’t want to open a Paypal account. However, he does know that if he clicks on the Paypal logo then he will be able to pay by credit card without the hassle of having to open some new fangled account. So to Luigi’s mind the Paypal logo is no different from the Visa logo. It means his credit card will be accepted.
As far as the second hit is concerned: “Ah! It’s-a exactly what I’m-a looking for. And it’s-a cheap, very cheap. And it’s-a in stock.” Luigi scans the page for payment methods. No credit card logos, no Paypal logo, only strange unfamiliar logos, “What’s-a these logos, Pecunix, e-gold, 1mdc? Never-a seen these before. Maybe one of them like-a Paypal. Maybe I can-a pay with credit card?” But Luigi is soon disappointed. These methods of payment don’t allow him to use his credit card. But he’s very keen to get “just the right kind of widget”, so on this occasion he decides to investigate a little further. “Eh! Such a nuisance. Looks-a like I’d-a have to set up account. Can’t-a set up account here on merchant site, have to go to e-currency site. I have-a quick look. Ah! To set up account maybe not too difficult. But how I-a get-a money into account if I-a create one? Eh! So stupid! I cannot-a believe it! This site where I-a create account not allow me to put money into account, but just give me list of other sites where I-a have to go to put in-a money. Hey! I-a don’t-a have-a time for treasure hunt! These people not-a make it easy. Let’s-a look at this list of exchangers. Dozens and dozens of them. Which one to pick? Let’s-a try this one. I don’t-a understand! What’s-a this ‘bank wire’ thing? I never-a use this-a bank wire thing. Why can I not-a use credit card. I try another.” After visiting fifteen e-currency exchangers Luigi finally hits gold—well fool’s gold to be precise. “Ah, at last! This e-currency exchanger allow me to-a pay by credit card. But-a what’s-a this. I-a have to wait for days, maybe weeks. Have to be-a verified. Exchanger say he have to-a ring me at-a home to confirm identity. Eh! Well, all I can-a say is-a bugger off!”
So Luigi is now the not so proud possessor of an expensive widget that was not quite what he wanted, and some merchant still has in stock one cheap widget that was just what Luigi wanted, but which was simply too difficult to purchase!
This story illustrates the big problem faced by any merchant offering e-currency as a payment option. It’s just too much hassle for the first-time user to get started. Not only has the user got to open an account with the e-currency issuer, but he has to trawl through dozens of e-currency exchangers, some of whose web sites are broken, many of whose web sites are badly designed, and almost all of which insist on “weird” methods of payment that the user has never used, or never even heard of. And the few e-currency exchangers that do accept credit card payments have intrusive verification procedures that take days or weeks to complete. In short, while e-currency is just as easy to use as a credit card once the customer has a “funded” account, getting to this stage is far too complicated and far too time consuming to attract mainstream web business.
The challenge for the e-currency issuers and e-currency exchangers is how to provide a gentle and painless transition for the average web user away from the use of credit cards and towards the use of e-currency as a method of payment for web goods and services. The mistake that has been made to date is to expect that the web user will make this transition in a single step. It won’t happen. There needs to be several steps to ease the web user into this new way of doing things. And as a first step the e-currency issuers and exchangers must find a mechanism by which a web user can click on an e-currency logo and pay for goods and services using a credit card in the standard manner, without having to follow intrusive verification procedures.
Is this essential? Yes. Online merchants are no fools. Accepting credit cards will immediately increase an online business’ sales volumes by about 500%—and by far more in the long term—compared to all other methods of payment put together—and amongst all these other methods of payment the sales volumes attributable to e-currency are tiny for the vast majority of merchants. And while e-currencies have the great advantage of no chargebacks, this advantage is entirely worthless to a merchant if web users are not buying his goods and services in the first place. So until web users can click on an e-currency logo and make an instant payment by credit card, e-currency will remain a very niche market.
Paypal, despite its many sins, has been shrewd enough to serve as a third party credit card processor—allowing web users to pay by credit card has been a major factor in its success. From the perspective of the web user Paypal appears in the same light as Visa and Mastercard. Even if the web user doesn’t open a Paypal account he is still very aware of the name Paypal, so by acting as a third party processor Paypal is buying web user awareness and raising its profile. From the perspective of the merchant, particularly the small merchant, Paypal is a credit card processor with extra facilities; the merchant can accept payments from those web users who have Paypal accounts and from those web users who only have credit cards. It appears to be a win-win situation. Of course, the merchant will soon encounter the disadvantages of using Paypal, but these “nasties” are postponed until after the merchant has signed up and has been using Paypal for some time—possession is not only nine tenths of the law it accounts for nine tenths of the profit! So the message to the e-currency issuers is a simple one: you can’t compete effectively with Paypal until you offer the same benefits as Paypal.
In addition to raising their profiles and increasing transaction volumes, there is another reason why the e-currency issuers and exchangers would be wise to broaden their user base as quickly as possible. Big Brother is very keen to shut down the e-currency business—witness the recent attacks on e-gold by the US government, and its harassment of some US based e-currency exchangers. Until e-currency becomes much more widely used than it is at present it will remain vulnerable to such attacks. And accepting credit cards, just like any other credit card processor, is the fastest way to broaden that user base.
But accepting credit cards is only the first step. The e-currency issuers and exchangers need to ensure that every web user who has a credit card also has an e-currency account. Then they need to persuade web users to treat these e-currency accounts like bank accounts, and to use e-currency to pay directly for goods and services. How can this miracle be achieved? By:
- Establishing e-currency third party processors
- Offering reserved fund e-currency accounts
- Standardizing e-currency payment interfaces
- Implementing seamless shopping cart integration
- Automating virtual e-currency account creation
To begin with let’s have a look at online credit card processing. There are two main types of credit card processors that allow an online business to accept credit cards: the primary processors and the third party processors.
The primary processors offer lower charges (2-4)% and faster payments (about 5 days); but they have higher set-up costs, longer set-up delays, substantially more paperwork, and a lower acceptance rate.
The third party processors have higher charges (5-10)% and slower payments (2-4 weeks); but they offer lower set-up costs, very small setup delays (minutes to a few days), negligible paperwork, and very high acceptance rates (90-95)%.
Chargebacks are the main headache than comes with accepting credit cards since these are passed back to the merchant, sometimes accompanied by additional chargeback fees. And the acceptable chargeback rates have been pushed down in recent years to around 1%, whereas previously 2% was the norm. This can make it difficult for online merchants, where the chargeback rate can average (2-3)%, though the rate varies very widely depending on the type of online business.
Recent years have seen some third party processors operating what amount to scams. The chargeback rates for high risk online businesses, such as gambling and adult sites, can be of the order of (20-30)%. Even though acceptable chargeback rates are of the order of 1%, these businesses can still operate by setting up as third party payment processors. By attracting large numbers of low risk online businesses they are able to dilute the chargeback rates for their high risk sites, so that on average their chargeback rates approach 1%. By changing the IP addresses of their high risk businesses on a periodic basis they are able to persuade the card companies that they are not only keeping chargeback rates within the guidelines but are also policing those guidelines in an effective manner.
But these third party processors have an additional money making trick up their sleeves. They can effectively extort money from online businesses by including terms in their contracts that allow them to withhold funds and close accounts if the chargeback rate exceeds some very modest amount. They delay initial payments to merchants until chargebacks come in, and then use a chargeback rate that exceeds the contractual terms as a justification for making no payments at all. The cost to a merchant of mounting a legal challenge in an offshore jurisdiction is prohibitive, so effectively the merchant receives no payments in return for any of his customer’s credit card purchases, while the third party processor receives an additional revenue stream until the merchant finally realizes that he’s been scammed.
Because so many third party processors are subsidizing their own high risk web sites, there is a business opportunity for those third party processors who do not: either they can offer more favourable terms in order to grow their own businesses, or else they can take a larger profit margin by offering the same terms as their chargeback encumbered competitors.
To meet the requirements of the e-currency niche we need a new type of third party credit card processor. Let’s define an e-currency third party processor (ETTP) as a business that provides all the functionality of a standard third party processor (STTP), but, in addition, pays each merchant using e-currency, and does not verify a merchant’s details beyond the standard inspection of the contents of the merchant’s site (this is an inspection that all credit card processors perform in order to ensure that the nature of the business is sufficiently low risk, and unlikely to give rise to frequent chargebacks).
The features of “payment in e-currency” and “merchant anonymity” make the ETTP a new niche that is not currently occupied at present, and it’s one that some of the existing e-currency exchangers could readily fill. Let’s look at what an ETTP has to offer for the four parties involved in a web purchase; the:
- E-currency issuer
- E-currency exchanger
What are the advantages of an ETTP to the customer? Well, none, apart from the fact that a merchant who previously did not offer credit card payments now does, which may widen the customer’s choice a little.
What are the advantages of an ETTP to the e-currency issuer? Substantial. Many more merchants would find e-currency attractive simply because it would allow them to get a cheap credit card facility that greatly expands their sales potential, and all these merchants would be paid in e-currency, increasing the e-currency issuer’s transaction volumes. In addition, because many more merchants would now display the e-currency logo, the profile of the e-currency issuer would grow considerably. This high profile could, in time, be used as a stepping stone to migrate customers away from paying by credit cards and into paying directly by e-currency. The e-currency issuer is now playing the Paypal game, but without incurring the Paypal overheads: unlike Paypal the e-currency issuer has no chargebacks to deal with! Given the great advantages that accrue to the e-currency issuer from the existence of ETTPs, the issuer would be wise to assist both merchants and ETTPs in getting the process up and running, and in ensuring its smooth operation.
What are the advantages of an ETTP to the merchant? Some merchants would value the anonymity provided by not having to disclose their true identities. Others, particularly the smaller ones, would value not having the hassle and expense of setting up a business bank account—many small merchants are reluctant to use their personal bank accounts for online business transactions. Setting up a bank account takes days to weeks, whereas setting up an e-currency account takes minutes. The other advantage is that an ETTP would be more competitive than the standard third party payment processors. Transferring money to an e-currency account is far cheaper than transferring it to a bank account, so the ETTPs have a lower cost base than the STTPs. An ETTP wouldn’t have to set a minimum level of purchases before it’s prepared to make a payment to a merchant—a policy that would be particularly attractive to the small business (one of the objectives of the e-currency issuers is to replace the current banking system, and offering better terms than the banks is the best way to achieve this worthy objective).
In addition, those STTPs that are using low-risk businesses to dilute high chargebacks from their own high-risk web sites have inherently higher costs that are reflected in poorer terms and conditions for their low-risk merchants. An unencumbered ETTP can therefore offer even better terms when competing against these STTPs.
What are the advantages to an e-currency exchanger in becoming an ETTP? For a start, much larger business volumes, as the credit card market dwarfs the e-currency market. It’s a new niche, attracting merchants that want anonymity or a lower cost base. It’s more competitive than the traditional STTP, providing greater profits or enabling better terms to quickly build-up a large customer base. It preferentially attracts the small merchant who is likely to stay, at least for some time, as its business grows, leading to high percentage profits on large transaction volumes for the ETTP, before the merchant finally decides to move its business to one of the primary processors.
The risks for the ETTP are no greater than those for the STTP. A payment using e-currency is no more or no less repudiable than a cheque or a bank wire, and therefore e-currency as a method of payment does not add to the ETTP’s risk. Theoretically, verifying the identity of the merchant might help to reduce the risk, but in practice it does not. In practice, all the STTPs have time to do is to have a cursory look at a merchant’s website to determine the nature of its business. Merchants selling goods or services with a high risk of chargebacks—such as merchants offering gambling or adult sites—hide their identities behind personal proxies and their sites behind other low risk businesses, so that the STTP doesn’t realize the true nature of the business until the chargebacks start rolling in. So the degree of identity checking that is possible in practice does not help to lower the STTP’s risk.
The only potential problem for an ETTP is getting a credit card account from a primary or third party processor. Credit card processors are very wary of offering accounts to others in the same line of business to begin with. And Big Brother is not going to encourage any business that makes payouts in e-currency to anonymous individuals. However, as we’ll see in the next section, there is a simple way of packaging an ETTP business that will allow anyone who can get a standard credit card account for routine business purposes to effectively operate as an ETTP, and this repackaged business has a much lower profile than that of being an e-currency exchanger.
There are already businesses that effectively act as ETTPs, but which have no difficulty whatsoever in getting a standard credit card account from a primary or third party processor.
There are four main aspects to an online business:
- Order payment
- Order fulfilment
While traditionally these functions were performed by a single business entity, these days they are often split apart and outsourced. First consider the case of the sales portal. Let’s take the specific example of a sales portal for computer software. Many software programs are written by individuals whose sole interest is in writing software, individuals who have no desire whatsoever to run a business. The sales portal provides a web site that contains details about hundreds of different software programs. Each software program’s author gives a copy of the software plus a description to the sales portal, which places the description on its site. The web user finds the sales portal, pays for the software using the services of the sales portal’s credit card processor, and then the sales portal emails the user a link to download the software from its web site. About once a month the sales portal pays each software author for the number of copies sold less a commission by means of a check or a bank wire. There are a vast number of web sites that sell products that other people produce and it’s very easy for almost all such sites to get a credit card account from a processor. What’s important here is that the processor doesn’t inquire into the arrangements that exist between the sales portal and its suppliers. The credit card processor doesn’t ask, “Do you verify the identities of your suppliers?” It doesn’t say, “You mustn’t pay your suppliers using e-currency”. In this example the software author is responsible for production, while the reseller is responsible for marketing, order payment, and order fulfilment. But the business arrangements are often more complicated than this.
Consider the case of the reseller. The software author may well have his own web site and may well handle the downloading of the software after purchase. He may have a purchase button on his web site that is no more than a link to the payment page associated with his product on the reseller’s site. The description of the product on the reseller’s site may be very brief, and contain a link to the author’s site, so that potential customers can find out more information about the software. In this case the software author is responsible for production and order fulfilment, the reseller for order payment. Both contribute towards the marketing.
Now what would happen if the reseller simply deleted all the marketing information about the software he resells from its web site? The software author could still sell his products because the link from his site to the associated payment page on the reseller’s site would be intact. In this case the software author would be responsible for production, marketing, and order fulfilment, and the reseller would be responsible for order payment. If the reseller didn’t verify the merchant’s details and paid him using e-currency then he would be acting as an ETTP.
We now have a simple method for the ETTP to disguise the real nature of its business and to overcome any difficulties it might have in getting an account from a credit card processor. All the ETTP has to do is to pose as a reseller. The reseller’s site could operate on the department store model and sell a wide variety of goods and services, or it could specialize by selling just a particular category of goods and services. Payment by e-currency might be mandatory or just an option that sits alongside the traditional cheque and bank wire. The reseller could provide generic slots into which each merchant could insert a brief description of the goods and services for sale, together with a link to the merchant’s site for more details. If properly setup, the reseller would have to expend no effort in terms of maintaining this marketing information—the merchant would simply log in and modify his section of the site as appropriate.
The only thing the reseller would have to do—as with all credit card processors—is to assess the likelihood that a particular merchant is engaged in a business that will incur significant chargebacks. This could be done by a quick visit to the merchant’s site. The reseller could pick and choose those merchants that sell goods and services with a low risk of chargeback, and could limit initial sales volumes, require deposits, or lengthen initial payment periods to limit his exposure until he can confirm that chargebacks are no greater than expected. The reseller would have little difficulty in getting an account from a credit card processor as when the processor visits the reseller’s web site it would see a portfolio consisting of a wide variety of low risk products for sale, which is exactly the mix needed to keep chargebacks low and to minimize chargeback fluctuations. And the processor will not inquire as to how the reseller pays his suppliers or what steps he may or may not take to verify their identities.
Setting up as an ETTP reseller is a low profile and low risk method of acting as an ETTP. We’d like to see large numbers of individuals take up the challenge, with many small ETTP reseller sites scattered across the web. The vast number of reseller sites that already exist would make it impractical for Big Brother to identify and close down those ETTPs that act as resellers.
Now as e-currency issuers would benefit greatly from the existence of ETTPs, the wise e-currency issuers should take steps to make it easy to setup and run such a business. One of the chief shortcomings of the e-currency issuers to date has been a failure to appreciate that the success of their businesses is directly dependent on the success of the e-currency exchangers. We’d expect the e-currency issuers to help the e-currency exchangers to become ETTPs. In particular, we’d expect the e-currency issuers to:
(1) Provide information to prospective ETTPs that shows them how to get accounts from the credit card processors.
(2) Provide, for free, template web sites that an ETTP can customize by simply slotting in the details of its chosen credit card processor. The template would contain appropriate scripts for managing and paying merchants—using the issuer’s own e-currency, of course!
(3) Provide a supply of candidate merchants who are interested in using an ETTP. Users of the e-currency who would like to find an ETTP reseller could indicate this in their e-currency configuration settings, and ETTP resellers could register their interest in finding more merchants with the e-currency issuer. Then the interested parties could be introduced to one another in some suitable manner.
For a little effort an e-currency issuer should be able to ensure that with a very modest number of clicks anyone can set themselves up as an ETTP reseller for zero, or minimal, outlay.
Now that our e-currency issuers have helped to launch a number of ETTPs, many more merchants are using their e-currencies, and their brands are becoming well known. They’ve done what’s needed as far as the merchant end of the business is concerned. But from the customers’ perspective their e-currency logos are still just a means of paying by credit card. It’s time to get web customers to start using these e-currencies directly.
It’s coming up to Christmas. Grandpa used to send his grandchildren some money each year in the form of a gift voucher, but then they started complaining that they couldn’t spend it on the things they wanted to buy. Simply enclosing some cash with a card doesn’t seem quite right. So what about giving his grandchildren some gold in the form of a funded e-currency account instead? Ideally grandpa would be able to go to an e-card site, select a card, select an e-currency, select a funding amount, type in the email address of the recipient, pay with his credit card, and that would be that. However, while his credit card can be used to pay for the e-card it can’t be used to pay for the funded e-currency account.
Why can’t the e-currency issuers avail of simple marketing opportunities like this? After all, grandpa could buy a funded Paypal account with his credit card. The problem is that an e-currency exchanger would have to be involved somewhere behind the scenes, and this e-currency exchanger wouldn’t know whether grandpa had stolen the card details that he had entered. If so, there would be nothing to prevent grandpa from accessing the newly funded account and transferring his ill-gotten gold elsewhere. But grandpa can’t reasonably be expected to set up his own e-currency account and then fund it, just for the purpose of sending a gift to his grandchildren—this is just not how real-world Christmas shopping works!
How can we get around this problem? Well just as the ETTP gets around the problem by deferring the payments it makes to its merchants so too can the e-currency exchangers get around the problem by deferring the date until which funds placed in an account can be used or by restricting the purposes for which the funds can be used, or both. Well, they could if the e-currency issuers were to get their collective fingers out and make opening a funded e-currency account as simple as making a credit card payment: we live in a world of chargebacks, and until the e-currency issuers start from “where the world is” then they have no hope of moving the world to “where they want it to be”!
Let’s expand the concept of an e-currency account and distinguish between the concepts of reserved funds and free funds. The total amount of free funds in an e-currency account could be used in any manner the account owner wishes. The total reserved funds would be broken down into a list of separate amounts each of which had against it one or more of the following:
- An expiry date and chargeback e-currency account number
- A transfer tag
Prior to the expiry date the owner of the chargeback account number could transfer all or part of the reserved fund to the designated chargeback account. After the expiry date the reserved amount would be added to the free funds. To implement this functionality would not require much extra effort on the part of the e-currency issuer. On the e-currency payment form all that would be required is a few additional fields. If these were left blank—the default—then the payment would go into the account’s free funds. Very little change would be required to the e-currency issuer’s database; all that’s needed is the addition of the expiry date to the transaction history record. The processing overhead would not be large. Reserved funds could be indexed by expiry date, and once a day a script could look up all accounts that have reserved funds expiring on that particular day, and update the accounts by marking expired reserved funds as free funds.
A transfer tag is a reference to a set of e-currency accounts. Reserved funds with a transfer tag attached could only be transferred to one or more of the accounts belonging to the referenced set. If the reserved fund also had an expiry date, then the funds could be transferred to another account before the expiry date, provided that the expiry date and chargeback account were also transferred, creating a reserved fund in the recipients account—the original payee could still get his funds back before the expiry date as access to the reserved funds is controlled by the e-currency issuer who can be relied upon to enforce the rules. Again, this functionality would require little overhead to implement, just an additional lookup whenever a transfer of reserved funds is made to ensure the destination account belongs to the appropriate set of accounts.
A secondary market could be established in reserved funds, providing e-currency account holders with a means to automatically convert them to free funds for a commission: just as the debts of companies are sold based on the likelihood that they will repay the loan on the due date, so too could the chargeback entitlements of ETTPs be sold based on the likelihood that no chargeback would come it by the expiry date. The more care the ETTP took in selecting his merchants, the fewer the chargebacks, and the smaller the commission required by operators in the secondary market. To make the secondary market work effectively, a risk category would need to be assigned to the reserved funds by the ETTP when the funds are first created. If an ETTP had not processed a particular credit card before then the risk would be high; if it had frequently processed the same card with no chargebacks, then the risk would be low—the reserved fund would be almost as good as gold! So the commission charged in the secondary market would depend not only on the ETTP but also on the risk category assigned to the reserved funds by the ETTP. While the volumes of e-currency exchanged at present are relatively small, once instant credit payments were accepted the ETTP market would soon become large enough to encourage the development of a secondary market.
Reserved funds decrease the risk of using e-currencies and therefore expand the number of uses to which e-currencies can be put. Quite apart from increasing transaction volumes there existence would be effective in counteracting some of the negative publicity that e-currencies generate.
The existence of reserved funds would allow e-currency exchangers to accept credit cards without verifying customer details in cases where the transferred funds were not needed immediately. For example, grandpa could purchase his funded e-currency account with a credit card, as the e-card merchant could simply transfer its customers to an e-currency exchanger’s payment page. Provided grandpa got his Christmas gift well in advance, the funds would be available to be spent on Christmas day, as the e-currency exchanger would have had sufficient time to process any chargeback that might have come in against the transaction. If not, then the recipient could always convert the reserved funds into free funds by selling them on the secondary market. This mechanism is open to some abuse, but might well work for small payments.
A safer method would be to include a tag along with the deferred payment. If the funds can only be spent with one or more of a designated set of merchants then the risk of fraud falls still further. Instead of grandpa buying a particular gift from one of the merchants served by a particular ETTP, he could buy a funded e-currency account with a deferred payment date and a tag that only allowed the funds to be spent with one of the ETTP’s merchants—the expiry date would get transferred to the merchant account when a purchase was made from the reserved funds, so from the ETTP’s point of view the situation is exactly the same as if the purchase had been made directly.
While reserved funds may add some complexity to the structure of the e-currency issuer’s database, they offer the prize of being able to create and fund an e-currency account using a credit card for immediate payment. Gold that can be spent in a flexible manner is always an attractive idea for the last minute present, and the fact that there may be a delay before it can be spent would only be a minor drawback for most givers—as long as the giver has to do no more than click on a button and fill in his credit card details that is! Most individuals who have been gifted funds in an e-currency account are likely to make the effort to spend them. And some of those who receive such a gift will conclude that it’s quite a good gift to give someone else, generating even more business for the e-currency issuers and exchangers.
To simplify the process of e-currency exchange for e-currency users the e-currency issuers need to take a more proactive part in the process. The issuers need to design a standard set of forms that allow users to fund an e-currency account using various methods. These forms would be made freely available to the e-currency exchangers who could include them on their web sites in addition, or as an alternative, to their current interfaces. Those exchangers who implemented the standard interface would provide the e-currency issuers with suitable links, and, provided that the e-currency issuers were satisfied with the exchanger’s reliability, the e-currency issuers would list them as preferred exchangers. Being listed as a preferred exchanger on both the e-currency issuers’ sites and in the gold directories would clearly be highly prized by exchangers and almost all of the more reliable exchangers would be likely to comply (while it would be best if the different e-currency issuers got together and thrashed out a common standard, even if each of the big three set their own standards that, in itself, would be a vast improvement).
The great advantage of standardization is a single well-documented user interface for making e-currency exchange: paying by a credit card or a bank wire would always have the same fields in the same place, and the exchanger’s terms of business would be presented in a consistent fashion. The exchangers could still compete amongst themselves by offering different terms, but the e-currency user would always see the same easy-to-use interface, and not the ragbag of disparate, poorly designed specimens that greet him at present.
Now, shopping carts that allow users who have an e-currency account to pay by e-currency already exist, but this functionality is no more than preaching to the converted. What we need to provide is an easy way to migrate customers away from the use of credit cards as a method of payment for purchases and towards credit cards as a method of funding e-currency accounts from which payments for purchases are subsequently made. During this transition period there are four different activities that a merchant’s customer needs to perform:
- Pay for goods and services using a credit card (MR)
- Create a new e-currency account (EI)
- Fund an e-currency account (EE)
- Pay for goods and services using an e-currency account (EI)
The problem is that these activities involve visiting three different web sites: the merchant (MR), the e-currency issuer (EI), and the e-currency exchanger (EE), and this toing and froing is far too complex for most web users. We need to ensure that the web user need never be aware that he is visiting the web sites of the e-currency issuer and the e-currency exchanger. The key to success is a single, uniform interface that can be included as an add-on to any shopping cart that allows payments to be made by means of e-currency.
The web user is familiar with the structure of shopping carts. There is a page where he enters his credit card details. Where this page is part of the merchant’s credit card processor’s site—such as WorldPay—the user is automatically transferred to and from the site in a seamless manner. What we need from an e-currency shopping cart is a similar set of seamless transfers between the sites of the merchant, the e-currency issuer, and the e-currency exchanger.
Let’s take a simple example. Suppose at the end of the payment’s section of a shopping cart, after the customer has already entered his personal and credit card details, he sees something along the following lines:
In addition to paying for the selected products would you like to:
Use your credit card details to create and fund an e-currency account:
Exchanger: XXXXX (change if preferred)
Use your credit card details to fund an existing e-currency account:
Exchanger: XXXXX (change if preferred)
The objective here is one of marketing and ease of use. Paying by credit card is the most common financial activity that the average web user undertakes. If the user has the option of performing e-currency transactions at the same time, using the same form and the same details that have already been entered for a credit card transaction, then this helps to place e-currencies on a par with credit cards as a method of payment.
The default value for the exchanger might be selected at random by the shopping cart from amongst the e-currency issuer’s preferred exchangers, so that the first time user of e-currency wouldn’t have to make a choice. The experienced user could select a particular exchanger that he likes to do business with. The “continue” button would initiate the sequence of payment and account creation processes. The payment for the selected products would be authorized in the background using the merchant’s credit card payment processor (which may or may not be an ETTP). A confirmation page would appear briefly.
Then, if the user had selected the “create and fund” option, he would be automatically transferred to the e-currency issuer’s site, with all the personal information copied across from the merchant’s shopping cart. All that the user would have to do to create an e-currency account would be to enter a password and any other security information that may be needed and then press “continue” (the user could, of course, change the information copied across if required). Information, such as an account PIN, would then be sent to the email address copied across from the shopping cart.
The user would then be transferred to the standardized credit card payment interface page on the selected exchanger’s site with all the credit card information copied across from the shopping cart and the new e-currency account number copied across from the e-currency issuer’s site. The user would just have to press “continue” and the newly created account would be funded with the appropriate amount (a link on the exchanger’s payment page would allow the user to select some other funding method offered by the exchanger if preferred). If the user selected the “fund” option then the first step would be skipped. And that’s it.
The user would have to make very few decisions, would not have to select, to navigate to, and to repeatedly enter the same information on multiple sites, and as the entire account creation and funding process would be automated the user need never be aware that he has left the shopping cart and the merchant’s site. For a new user the e-currency exchanger would, of course, have to place restrictions on the funds using the reserved fund mechanism, restrictions that the user could lift immediately by going through the exchanger’s verification process. The key objective here is to make the user do as little work as possible to create and fund an e-currency account. If any work needs to be done, then it should be deferred until the user comes to make the first spend from that funded e-currency account.
The simple example in the previous section illustrates how the account creation and funding process might be streamlined. But account creation is still conditional—even though account creation and funding is easy, the user still has to be interested in creating an e-currency account in the first place. What we need to do is to make the process automatic, so that every user who makes a credit card purchase automatically gets an e-currency account, and, unbeknownst to him, effectively uses this account to pay for his purchases.
Let’s say that an e-currency issuer comes to an agreement with an ETTP, so that whenever the ETTP is used by one of its merchants to process a credit card payment, a “virtual” e-currency account is automatically used as a step in the payment process. From the user’s perspective he pays by credit card in the normal manner, but in the background the ETTP and e-currency issuer work together to automatically pass the transaction through the user’s virtual e-currency account, creating that account automatically if it does not already exist. Instead of the e-currency issuer placing a deferred payment directly into the merchant’s e-currency account as a result of the credit card payment, the e-currency issuer first places it into the web user’s virtual e-currency account as a debit (charging up the account), then places a credit into the web user’s virtual e-currency account for the same amount (so that the account balance returns to zero), and finally places the amount into the merchant’s (non-virtual) e-currency account as a debit. Financially, the result is the same as a single debit to the merchant’s account.
How does the e-currency issuer know which virtual e-currency account to use since the user is never asked to enter an e-currency account name, even if he has one? The answer is to generate the virtual e-currency account name from the details of the user’s credit card. The card number is authorised based on features such as name, address, and expiry date. The e-currency exchanger can generate a unique virtual account name from a hash of the concatenation of card number, name, address, and expiry date. If the account doesn’t already exist it is created by the e-currency issuer. This provides a mechanism for automatically creating and passing transactions through a virtual e-currency account. The naming convention can ensure that virtual accounts never have the same number as a real one. Even if two credit cards hashed to the same value—the probability is infinitesimally small—it would have no real financial impact since virtual e-currency accounts would always have a zero balance. The privacy of the user is not compromised since the e-currency exchanger does not pass the user’s credit card details to the e-currency issuer, but only a hash from which the original details cannot be recovered.
Note that this e-currency account has no password, but then neither does a credit card, so the user is no worse off, particularly as at this stage he never uses his virtual e-currency account directly. The ETTP could suggest that for additional security the user might wish to add a password to his credit card to help prevent credit card fraud. The password would become the virtual e-currency account password, which is first created and subsequently entered during the shopping cart checkout procedure by an automatic transfer to the e-currency issuer’s site, just as a user might be transferred to Visa’s site if using the optional “Verified by Visa”. The e-currency issuer doesn’t know the user’s credit card details and the ETTP doesn’t know the user’s virtual e-currency account password, enhancing the user’s security. What we’re trying to do here is to mirror credit card functionality as much as possible while generating all the information needed to operate an e-currency account behind the scenes.
What’s the advantage of all this accounting? Well, the ETTP would need to send the user a confirmatory email that gives details of his spend every time he pays by credit card, and this would provide an excellent marketing opportunity to encourage the user to convert his virtual e-currency account—the one that he didn’t know he possessed—into a real e-currency account. We are not doing anything at this stage that requires the user’s permission. We are just offering the user the opportunity to activate and use some additional functionality.
The confirmatory email could explain that the virtual e-currency account is charged up by the user’s credit card and then used to pay the merchant. We want the user to get used to the idea that (1) he already has an e-currency account, and that (2) he is already using that e-currency account to pay for goods and services. The email can point out to the user that the charging of the e-currency account (like paying into a bank account) and making payments to a merchant (like making payments from a bank account) can be done independently, and that this functionality can be activated with a single mouse click, and would then be available during the shopping cart checkout procedure and from the e-currency issuer’s web site.
Now our objective is nearly achieved. The e-currency issuer has stacked all the “cards” in his favour, for all the hard work of setting up an account has already been done automatically. He can let the user log into his virtual e-currency account and view his transaction history, familiarizing the user with the e-currency site’s functionality (once the user sets up a password). All the e-currency issuer has to do is to provide some incentive or discount to get the user to start using the e-currency account like a bank account from which payments can be made directly to merchants, bypassing the use of credit cards altogether. Alternative and cheaper account funding methods, such as bank wires, could be promoted as a cost saving feature. It is only at this stage that the user needs to sign up to the e-currency issuer’s T&Cs, because it is only at this stage that his “virtual” e-currency account becomes a “real” e-currency account that can possess a non-zero balance.
Now for the end game. If the e-currency issuer makes an effort to promote the use of ETTPs, then sooner or later most web users will make a credit card purchase from a merchant who uses one of the e-currency issuer’s ETTPs. As a result most web users will automatically end up with virtual e-currency accounts, and those web users will only have to make a single click to convert their virtual e-currency accounts into real ones. Q.E.D.