Most credit-card transactions within the U.S. economy occur over dial-up lines between merchants and card carriers. In the Internet economy, many sites still rely on these protocols; this is especially true for merchants with existing retail systems in which a Web site acts as a counterpart to brick-and-mortar storefronts.

For data integrity, the protocol relies on time-outs and retransmissions. If an authorization request is not answered for any reason, the client prepares a reversal transaction. The terminal will not send another transaction until the host receives a reversal response. The entire retail POS (point-of-sale) system depends heavily on physical security, while the protocol is rather light in terms of encryption: Instead of encrypting all messages, only certain fields--such as a PIN on debit transactions--are encrypted via the ANSI X3.92 data encryption algorithm. Authentication is limited to carrier-assigned merchant and terminal fields.

At some point, the credit-card transaction is most likely translated to a legacy credit-card protocol. This function is usually fulfilled by the payment module of the site's commerce package or by an intermediary, such as CyberCash. This integration of new and old lets consumers access random commerce sites without any special software. It also lets banks and financial institutions accept Internet-generated transactions using existing systems.

Although it's not necessary to have an intimate knowledge of the link protocol, it's important to understand the fields that make up the authentication messages and responses. The configuration of merchant and store identifiers within the commerce software is usually a one-to-one mapping with bank-assigned fields. In addition, if you are designing a database for order capture, the industry-specific field definitions that extend the authentication messages are an excellent starting point.