But what about ...
Many people say that digital cash must provide anonymity, non-repudiation, offline transactions, etc. I understand that there are many forms of digital money that can do these amazing things. But they are very complicated. I feel that fundamental Internet technologies should be simple. Thus, my Internet payment system is modeled after SMTP and email. It does not even try to do all of the amazing things that we would like to have. Instead, it does only the essentials.
Overview
This section introduces the entities and concepts of the payment system.
iBank
This is an Internet Bank. It is a software program running on a server with a static IP address or dns name. It opens a TCP socket on a standard port and listens for incoming connections. Connections are protected with SSL/TLS or IPSec.
The iBank software maintains a database of accounts. The software performs transactions and queries on the database for clients who connect to the TCP port. The iBank also maintains other data and performs other functions necessary for inter-bank transfers.
User
A 'user' is a person who holds an account at an iBank. The iBank may not know anything about the user. All that matters is that the user has the information necessary to perform transactions using the account. This information is printed on a card, a sheet of paper, or stored electronically in a client.
Client
A 'client' is a software program that communicates with iBanks and other clients to perform transactions. It may be a program running on a cellphone, PDA, PC, or smart card. It may be integrated into a web browser or run as a web application. Big iBanks will offer easy-to-use Client Webapps for their customers to access their accounts and initiate transactions.
Codes
The bank generates a set of random string to go with each account. These strings are called codes. They serve as passwords granting access to various functions of the account. They also hide the identity of the account from other parties.
Types of Codes
- Debit Code: authorizes a transfer out of the associated account, into some other account. After the transaction has completed, the code serves as a transaction identifier and receipt. Most debit codes are single-use.
- Deposit Code: deposits using this code will go into the associated account.
- Master Code: allows access to all functions of the account: activation, deposit, debit, transaction logs, requesting new codes, associate PIN, associate certificate, etc.
- Initializer Code: is a form of deposit code for pre-printed cards. The card is invalid until a deposit is made using this code. The initializer code will be stored on a magnetic stripe or bar code. When you buy the prepaid card in a store, the clerk scans the card at the cash register. The store's computer then adds money to the card using the initializer code.
Single Use
Some codes are usable for only one transaction. Most debit codes are single-use to prevent the double-charging by a merchant. Occasionally it might be useful to have single-use deposit codes. Initializer codes are always single-use.
Value Limits
It is important for debit codes to have value limits. A debit may be of any value up to the limit. This limits overcharging by merchants. A pre-printed card has many debit codes of various small values and a few larger valued codes. For example, a card may have 15 debit codes, all single-use, with maximum values of $0.50, $0.50, $0.50, $0.50, $1, $1, $1, $1, $2, $2, $5, $5, $10, $25, and unlimited.
When using a client to make payments, the client may choose a debit code and then contact the iBank to set an exact value for it. Thus a client can prevent the merchant from overcharging or undercharging.
Code Status
A code is 'valid' if it can be used to perform its designated function. A code which may no longer be used is 'invalid'. For example, a single-use debit code becomes invalid after it is used in a transaction. There is a transaction where a client may invalidate a code intentionally.
Question: What happens to a single-use code if it is used in a failed transaction? Example: a merchant displays a price of $4.00 for a product. The customer sends the merchant a $5.00-limited debit code. The merchant doesn't know the limit of the code and tries to debit $10.00.
MichaelLeonhard: I think that the transaction should fail. The only effect should be that the specified debit code becomes invalid. The system should also record the attempted amount of the debit, the provided deposit code, the merchant's IP address, and the time of the transaction, in milliseconds.
- There are several other possible behaviors. One is that the debit could succeed for the limited amount, in this case $5.00. This would allow merchants to easily cheat customers out of the maximum amount of each debit code.
- Another behavior is that the transaction simply fails with no effects. This would allow merchants to retry transactions with various amounts.
- Please add your comments using the format above. Thanks.