Summary

  • CyberCash version 0.8 sent signed, encrypted card details through the merchant to its server, which dealt with the acquiring bank. The February 1996 RFC says the system was already operational and that its first Internet-Draft had appeared on 8 July 1995.
  • The bank could choose whether the merchant's receipt carried a masked card fragment or the whole number. A separate dispute message let a merchant request card data through the server, with a password and a recorded request.

A sealed message through the shop

A customer could click Pay at a merchant's computer, choose a registered card and send a charge. The merchant handled the message. That did not require the merchant to read the card number. In RFC 1898, the customer's software signed and encrypted the card details and a hash of the invoice; the merchant added its own signed authorization data; CyberCash's server checked both sides before sending the relevant information to the acquiring bank. The bank returned the authorization result along the same chain.

This was a payment bridge into existing banks, not a replacement for them. CyberCash had been founded in August 1994. Its version 0.8 document, first public as a draft in July 1995 and published as an Informational RFC in February 1996, described credit-card payments in operation. Electronic cash remained a future facility. The distinction matters: the card still lived in the bank's authorization machinery, even when the customer met it through a browser.

The protocol made a bold privacy claim and then drew its exceptions in ink. Section 1.2.2 says the merchant normally would not learn the number. It named two routes to disclosure: the merchant's bank could release it, or a dispute could require it. The server, according to the specification, did not keep card numbers permanently; it held them during transactions. The relevant control was therefore not an impenetrable envelope. It was a sequence of decisions about who was allowed to open one.

The bank's checkbox and the merchant's second request

The ordinary merchant response, CM6, exposed the choice. Its card-prefix showed the first two and last four digits. A merchant classed as full-PAN could instead receive card-number. The RFC assigns that choice to the merchant's bank. It also supplied a salted card hash so a merchant could group purchases made on the same card without seeing the number. Three pieces of the same transaction served three different purposes: identification of a charge, recognition of a repeat card, and possession of the complete credential.

The exception had its own message pair. For a disputed charge, a merchant could retain the customer's original encrypted message and send a CD1 card-data request to CyberCash. A separate password authorized this unusual action. The server could answer with a CD2 containing the card data. The specification says the request would be recorded and excessive requests could be flagged. It offers the mechanism; it gives no audit showing how often merchants used it or how often monitoring stopped misuse. That missing operational record would change an assessment of how well the control worked.

CyberCash's designers had to let a shop resolve charges without handing every shop every customer's card number at checkout. They placed discretion at the acquiring bank and the payment server. The shop's window looked like commerce; the access policy was elsewhere. The bank could open the envelope in the routine receipt, and the server could open it later when the merchant asked under a recorded exception.

Sources