- Introduction
- The SET Scene
- Details of a Purchase Request
- SET in Practice
From the author of
From the author of
From the author of
Details of a Purchase Request
To get some feel for the complexity of SET, let's look at one of the most common transaction types: the purchase request. Before the purchase request exchange begins, the cardholder has completed browsing, selecting, and ordering. The end of this preliminary phase occurs when the merchant sends a completed order form to the customer. All of the preceding occurs without the use of SET.
The purchase request exchange consists of four messages:
- Initiate Request
- Initiate Response
- Purchase Request
- Purchase Response
To send SET messages to the merchant, the cardholder must have a copy of the certificates of the merchant and the payment gateway. The customer requests the certificates in the Initiate Request message, sent to the merchant. This message includes the brand of the credit card that the customer is using. The message also includes an ID assigned to this request/response pair by the customer.
The merchant generates a response and signs it with its private key. The response includes a transaction ID for this purchase transaction. In addition to the signed response, the Initiate Response message includes the merchant's certificate and the payment gateway's certificate.
The cardholder verifies the merchant and gateway certificates by means of their respective CA signatures and then creates the order information (OI) and payment information (PI). The transaction ID assigned by the merchant is placed in both the OI and PI. The OI doesn't contain explicit order data such as the number and price of items. Rather, it contains an order reference generated in the exchange between merchant and customer during the shopping phase before the first SET message.
Next, the cardholder prepares the Purchase Request message (see Figure 6).
){kind=link}
Figure 6 Cardholder sends purchase request.
For this purpose, the cardholder generates a one-time DES encryption key, known as a session key. The message includes the following:
Purchase-related information. This information will be forwarded to the payment gateway by the merchant and consists of the PI and a dual signature. The dual signature is a signature that covers both the PI and the OI. It's constructed in such a way that both the merchant and the payment gateway can verify the signature, even though the merchant only sees the OI and the payment gateway only sees the PI. Both the PI and the dual signature are encrypted using the one-time session key. Finally, the session key is encrypted with the public key of the payment gateway and added to the message; only the payment gateway will be able to decrypt and read the session key and therefore only the payment gateway will be able to recover the PI.
Order-related information. This information is needed by the merchant and consists of the OI and the dual signature. The merchant uses the dual signature to verify that the OI is valid.
Cardholder certificate. This contains the cardholder's public key. It's needed by both the merchant and the payment gateway.
When the merchant receives the Purchase Request message, it performs the following actions:
Verifies the cardholder certificates by means of its CA signatures.
Verifies the dual signature using the customer's public signature key. This ensures that the order has not been tampered with in transit and that it was signed using the cardholder's private signature key.
Processes the order and forwards the payment information to the payment gateway for authorization.
Sends a purchase response to the cardholder.
The Purchase Response message includes a response block that acknowledges the order and references the corresponding transaction number. This block is signed by the merchant using its private signature key. The block and its signature are sent to the customer, along with the merchant's signature certificate.
When the cardholder software receives the Purchase Response message, it verifies the merchant's certificate and then verifies the signature on the response block. Finally, it takes some action based on the response, such as displaying a message to the user or updating a database with the status of the order.