Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

Understanding Internet Payment Protocols
May 3, 1999
Existing Payment Systems Electronic payments generally are representative of real-world exchanges. Payment protocols provide an electronic counterpart to paper-based methods of exchanging goods. In fact, if done right, electronic purchases should be far more secure than other purchases since traditional, paper-based methods display complete and unencrypted credit-card numbers.

Our aforementioned spearhead-for-an-antelope analogy became more complicated by the Middle Ages. By then, two payment concepts--bills and coins--had evolved, obtaining their value from government institutions. Both parties involved in a transaction must have faith in the currency's value. In contrast, notational checks, purchase orders and credit cards represent a commitment to exchange cash and exhibit no fundamental value. Over time, our basic buyer-and-seller model has grown to include more modern trading roles, such as consumer, merchant, payment agent and delivery agent.

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.

Page 1 | 2 | 3 | Next Page