Steps in making a credit card purchase using the SET protocol:

1. The buyer indicates that they are interested in making a credit a card purchase.
2. The merchant's system generates and sends the buyer an invoice for the purchase.
   • This process is not currently specified in the SET protocols. As it stands, the protocol only details what happens once the buyer's software responds to this invoice.
   • The buyer is running software similar to the CyberCash Wallet which will handle the acceptance of the invoice and the transmission of the buyer's credit card data to the merchant. This software may be built into the buyer's WWW browser.
3. The buyer selects a VISA or MasterCard credit card for payment from the ones they can use with their SET payment software.
4. The buyer's software initiates the payment process by sending a request to the merchant's software for both their encryption public key and the public key of the payment gateway (acquiring bank's system) that the merchant uses. The request indicates the type of credit card the buyer will use, as a merchant may use different payment gateways for different types of cards (probably not).
   • The buyer's software needs both the merchant's and payment gateway's (acquiring bank) public keys before it can send credit card data to the merchant.
5. The merchant's software generates a response to the request and replies back to the buyer's software. This response includes:
   • A unique transaction identifier generated by the merchant's system
   • The certificate for the merchant's public key
   • The certificate for the payment gateway's public key
     • Note - a certificate is an authenticated version of a public key. The certificate can be linked backed to the entity that issued it. By issuing the certificate, the issuing entity ,or certificate authority, is stating that this public key actually does belong to the party claimed within the certificate.
6. The buyer's software then verifies the merchant's and payment's gateways
   • Please read the SET business specification for information about this verification process.
7. The buyer's software generates two packets of information to send back to the merchant, the Order Information packet (OI), and the Purchase Instructions (PI) packet. Each packet is encrypted separately. The PI is encrypted with the payment gateway's public key since the merchant is not meant to have access to it.
   • The OI is data meant for the merchant to see. It contains the transaction identifier, brand of card being used, and the transaction date. The merchant does not get to see a copy of the buyer's credit card number.
   • The PI is data meant for the acquiring bank to use when processing the transaction. It is tunneled through the merchant to the payment gateway. By tunneled through, I mean that the merchant does not decrypt the packet and process it, but passes it to the payment gateway untouched. The PI includes:
     • Credit card number and expiration date
     • Purchase amount agreed to by the buyer
     • Description of the order
   • A precise definition of what information is contained in these and other packets and messages used in the SET protocol can be found in the SET technical specification.
8. The buyer's software transmits the OI and PI to the merchant.
9. The merchant's software checks the message from the buyer with the OI and PI for any tampering. If no tampering is found, the software starts the process of requesting authorization from the merchant's acquiring bank.
10. The merchant's software generates an authorization request for the credit card payment request. Included in this request is the transaction identifier that the merchant generated at the beginning of the payment process.
11. The merchant sends to the payment gateway of their acquiring bank a message encrypted using the payment gateway's public key. This message includes the following:
    • The authorization request
    • The PI packet sent from the buyer
    • The merchant's certificate authority with their public key
12. The payment gateway then decrypts the message and its various components such as the PI from the buyer. It checks the various parts of the message for any tampering. These checks include:
    • Making sure the transaction identifier in the authorization matches the one in the buyer's PI packet.
    • The merchant has not tried to tamper with the data in the buyer's PI packet.
13. The payment gateway then sends a request for payment authorization to the buyer's credit card issuer through customary bankcard channels, i.e.. the same as the acquiring bank would request authorization for any typical credit card transaction.
14. The issuing bank sends back an approval or denial response and code to the payment gateway in response to the authorization request. This happens over regular bankcard networks.
15. The payment gateway generates an authorization response message to be sent back to the merchant. This message includes:
    • The issuing bank's response
    • An optional capture token to be used by the merchant when requesting capture of the sale later on (May be used by the acquiring bank to find the original authorization request from their records.)
16. The payment gateway encrypts and sends the authorization response message back to the merchant's software.
17. The merchant's software decrypts the authorization notice from the payment gateway. It examines the notice to find out if the request was approved or not. It then stores the authorization response and capture token sent by the payment gateway for later use when capturing the sale.
18. If the transaction is approved, the merchant's software then creates a purchase response message which is sent to the buyer's software. This message informs the buyer that payment was accepted and that the product or service that they purchased will be delivered.
19. The buyer's software processes the purchase response message and informs the buyer that payment was accepted.
20. At a later time, the merchant's software generates a capture request message to send to the payment gateway. This request includes the capture token (optional), transaction ID, and authorization information. The sequence of events surrounding the capture are very similar to steps 13 - 15 of the authorization process.

It is important to remember that steps 4 through 19 of this process will happen in a matter of seconds. This is the sequence of events surrounding a "normal" credit card transaction. These transactions can vary depending on the circumstances. SET allows for variations such as performing the authorization and capture at the same time for merchants that require real time processing.

The SET protocol provides the following advantages and disadvantages over other payment systems:

Advantages:

• Eliminates the need for a third party to monitor Internet credit card transactions. This will lower the cost of doing credit card business over the Internet.
• Strong encryption and authentication scheme to be used.
• Merchant does not have access to the buyer's credit card number.
• Merchants do not have a waiting period for receiving payment, as with First Virtual. The merchant's bank account gets credited within in the usual time frame for credit card transactions.
• Is backed by MasterCard and Visa.

Disadvantages:

• It is not ready for use yet. The SET protocol was just released for public comment in February 1996.
• Buyers and merchants will need to install software which allows SET transactions processing. Acquiring banks will either need to contract with a company to run a SET Internet gateway for them, or install a SET Internet gateway themselves.
• Merchants will need to have an account with an acquiring bank or card processor that is set up to accept SET transactions.

With MasterCard and Visa putting their weight behind SET, it should probably become the dominant method of doing credit card transactions over the Internet. Companies are already starting to develop software to process SET transactions for buyers, merchants and acquiring banks. In PCWEEK ONLINE, an article mentioned that IBM will be unveiling their NetCommerce system, which will include software for buyers, merchants, and banks to process SET transactions.