Secure Electronic Transaction (SET)

Credit cards and checks are complementary payment systems in todayís marketplace. Each caters to specific commercial payments needs, although there are overlapping areas where either payment mechanism could be used.

The Secure Electronic Transaction (SET) protocol specifications were defined by the credit card industry to facilitate credit card purchases over the Internet. The objective is to allow a cardholder to pay for items or services purchased from an Internet-based merchant with a transaction protocol that is more secure than the traditional “card-present” point-of-sale transaction. SET designers have sought to make over-the-Internet purchases safer for cardholders and to lower risks for financial institutions and merchants associated with current Mail-Order/Telephone-Order (MOTO) transactions.


SET and eCheck actually have much in common. Their similarities are summarized below.

  • Designed to augment and enhance the existing payments infrastructure for credit cards and checks.
  • Uses gateway systems to map the new electronic transactions into the existing payments infrastructure to minimize impact on mature systems and reduce initial deployment costs. Both SET and eCheck can be more tightly integrated into their respective infrastructures as these underlying systems evolve.
  • Supports co-existence with traditional plastic or paper transactions while working with in-place accounts.
  • Insures that the new electronic transactions do not introduce further risks for current plastic or paper transactions. In particular, protect account numbers and other account information from inappropriate disclosures.
  • Employs modern cryptographic technologies, including public key digital signatures and certificates, to protect privacy and provide strong authentication of all parties.
  • Deploys a hierarchical trust model for certificate authorities.
  • Improves security and safety over traditional plastic/paper transactions.
  • Inherits the legal and regulatory framework of the respective payments environments.
  • Substantially reduces potential for fraud and abuse.

Both SET and eCheck are recently defined specifications; they are best considered “pre-emergent,” even though there are active market trials for each. The SET specifications were published first, and currently there are numerous SET market trials being conducted around the world. 


Despite their similarities, SET and eCheck are fundamentally different transaction systems because the underlying payment infrastructures supporting credit cards and checks are fundamentally different. Since the characteristics of credit card and check payments are described in depth elsewhere, this short summary paper will address only major differences between SET and eCheck as electronic payment transactions.

eCheck was designed to be a direct analogue of the paper check. SET implements a distinctly new type of transaction into the credit card payment system while maintaining the current transaction model between the merchant and their bank. Consequently, echecks should be analyzed with respect to how well they emulate the paper check, and SET transactions should be considered in terms of a new approach to implementing a traditional credit card payment. These different approaches follow directly from the SET and eCheck design objectives and the need to leverage their respective infrastructures to best advantage.

Transaction Model

In the US Financial Industry, credit card transactions are considered to be “on-line,” and checks are considered to be “off-line,” payment instruments. While SET transactions could be used in an off-line manner, and echecks could be used to conduct an on-line payment, SET and eCheck are optimized for the on-line and off-line models respectively. On the Internet, web browsing or shopping is an “on-line” experience for the user, while email is the most popular “off-line” application. SET will usually be used in a web context, echecks will largely be exchanged via email. Both on-line and off-line payment transaction models are essential to broad adoption of electronic commerce.

    Figure 1: SET Transaction Flow. Arrows 1 & 2 are the initial setup phase. 3 is the purchase request. 4 & 5 are the authorization request and response. 6 is the purchase response to cardholder. 7 & 8 are the payment capture request and response. Messages a & b are not part of SET, but represent the actual account credits and debits.

SET transactions involve the cardholder (payer), Internet merchant (payee), and a “payment gateway” system that connects into the existing credit card network for purchase authorization. All three of these parties communicate with each other in real-time during the SET transaction, although the cardholder typically communicates with the payment gateway through the merchant. This is illustrated in Figure 1.

In contrast, eCheck transactions involve a direct transfer of the eCheck from payer to payee, followed later by a deposit of the eCheck to the payee’s bank of choice (ref. Figure 2). Since the eCheck transfers are independent (payer-to-payee, payee-to-bank), there is no requirement that these transfers utilize the same communications methods. Each independent transfer is also unidirectional, allowing tremendous freedom of choice for the style of communications employed. Interactive dialogues (e.g., web sessions) or discontinuous dialogues (e.g., email) can be used over any type of network, not just the Internet. An eCheck could even be put onto a floppy diskette and sent through the mail. This versatility will facilitate use of echecks in parts of the world where communications services are limited or costly. It also simplifies integration with other forms of electronic commerce, such as EDI or bill presentment.

    Figure 2: eCheck Transaction Flow. The eCheck is sent directly from Payer to Payee as shown by arrow 1. The Payee then deposits to their bank (arrow 2). Clearing and settle-ment takes place within the current bank pay-ments infra-structure (arrows a & b), but out-side of the eCheck dialogue.
Protection of Sensitive Data

In SET transactions, details about the purchase are strictly between the merchant and the cardholder, and should not be disclosed to the payment gateway or credit card network. However, before the payment is approved, the gateway must insure that the cardholder and merchant both agree not only on theamount, but also on what has been ordered. Both the cardholder and merchant systems compute a hash value for the order document, and each submits this value to the payment gateway. If these values agree, then the payment gateway concludes that the cardholder and merchant have the same order document. The payment gateway cannot deduce anything about the order details from just the hash value.

In the eCheck situation, the payer and payee establish their own dialogue with no third parties involved. It is up to these two principal parties to determine if they agree on the terms of the purchase, typically through exchange of documents such as purchase orders, invoices, or billing statements. If this information is sensitive, then the principal parties will take appropriate measures, such as secure email or secure web sessions, to insure confidentiality. Such exchanges are outside of the eCheck specification, but an eCheck may include one or more attachments that can be digitally signed by the payer when they issue the eCheck. Since this information is of no concern to the banks, an eCheck signature is formed in a special manner that allows any attachment to be removed by the payee without invalidating the signature. This is analogous to a paper check stub that provides information about the details of the payment to the payee, but that the payee will tear off and keep for their records before depositing the check.

Protection of Account Numbers

Because of how their respective payment infrastructures operate, SET and eCheck differ significantly in the way that actual account numbers are protected from disclosure and potential abuse. In the credit card situation, the current payments infrastructure must use the actual credit card account number to authorize the payment. SET therefore encrypts the credit card number at the cardholder’s system so that only the payment gateway can decrypt the number. The merchant, who passes the payment transaction to the gateway, cannot decrypt this number1,  but can decrypt the portions of the transaction they need to see.

Since only the paying bank needs to know the actual checking account number to clear a check, eCheck takes a very different approach to this problem. Each electronic checkbook is assigned a unique eCheck account number that only the bank can map into the real underlying account number. This “blinded” account number is part of the distinguished name in the bank-issued account certificate, so it cannot be modified and is easily verified by anyone who receives or processes an eCheck. When an eCheck is presented to the paying bank, the eCheck account number will be used to look up the corresponding checking account number so that the correct account is debited. An eCheck account number is only meaningful when incorporated into a signed eCheck, where the private signing key is protected by a hardware crypto token (e.g., smartcard). Multiple eCheck account numbers can be issued for a single checking account–each with its own set of account usage restrictions. Revoking an eCheck account number has no impact on the underlying account.

Certificate/Account Revocation

SET and eCheck take different approaches to revocation of digital certificates and/or accounts. Due to the on-line nature of SET transactions, the status of the cardholder and merchant accounts must be checked. Existing mechanisms in the credit card payments infrastructure are used where the merchant’s bank vouches for the status of the merchant, and the card issuer vouches for the status of the credit card account. In addition, it is necessary to confirm the certificate validity for payment gateways and Certificate Authorities (CAs). This is done through background procedures that distribute Certificate Revocation Lists, or CRLs, thereby allowing each gateway or bank to match the serial number of every received certificate against the revocation list. If a match is found, then the corresponding certificate is not valid.

Since checks are a “promise to pay,” the payment is not actually made until the check is accepted by the paying bank. If the paying bank finds reason not to pay a check presented to it, then the check will be returned to the depository bank and eventually to the payee. In the paper world, returns are expensive, and introduce further delays in the clearing system. eChecks will not only reduce the cost and delay of returned items, they will substantially reduce the rate of returns. But there will still be situations where it is appropriate not to pay a check presented. For example, if a “stop payment” order for a particular eCheck has been received, then the paying bank will return the item. This characteristic of the checking system has been exploited by eCheck to handle revocation issues. The paying bank will know if any electronic checking account certificates it has issued have been revoked or closed, and will hence be able to return any echecks signed using such certificates. An important benefit of this approach is that it allows the paying bank to make fine-grained decisions to pay/not pay on a per eCheck item basis, or to implement course controls that would return echecks from a specific eCheck account–either all echecks or just those issued after a particular date/time or serial number. In a similar manner, banks that receive deposits will be able to check the status of each account certificate at the time they verify the endorsement on a deposited eCheck. Certificates for CAs will be revoked using CRLs and standard procedures, similar to the SET case.

1 While this helps to protect the credit card system from merchants that might disclose the credit card numbers of their customers, in practice, account numbers are usually passed back to the merchants anyway.