Implementing Electronic Card Payment Systems (Artech House Computer Security Series)

G.3 Access devices for remote card payments

This appendix analyzes the hardware and software configurations of the cardholder and merchant access devices that allow their interaction on the appropriate open network channels.

To support a browsing/ordering channel over the Internet, denoted channel 1 in Figure G.1, the cardholder access device runs a Web browser and the merchant access device runs a Web server. Both access devices must have the adequate hardware for establishing a network connection, together with the appropriate software implementing the TCP/IP protocol stack. Usually, the cardholder access device can be a personal computer or a workstation, while the merchant access device can be a small computer like a PC or workstation, if the number of Web accesses is small, or a powerful mainframe for frequently accessed commercial sites. Their interaction is schematized in Figure G.2.

Figure G.1: Payment card processing in remote transactions.

Figure G.2: Browsing/ ordering channel over the Internet.

In this scenario, the commercial offer of a merchant is represented as Web pages, which are stored on the merchant's Web server. The Web pages can be written with the hypertext markup language (HTML), or with the extended markup language (XML), and the Java Script scripting language. The cardholder's browser makes a content request using the uniform resource locator (URL) address of the concerned Web page. The Web server returns a response that includes the content of this Web page, which is displayed by the cardholder access device. The browser is a client that requests services to the Web server, which provides the appropriate responses, according to the rules of the htypertext transfer protocol (HTTP). Thus, the cardholder can retrieve and display the appropriate commercial offer of the merchant. Not only can the cardholder inform herself about the merchant's offer from the content of a Web page, but if this page also includes an ordering form she can also make her choice and order the desired purchases. To this end the cardholder's browser sends a processing request of the order form to the merchant's Web server. The server processes this request, using, for example, the common gate interface (CGI) technology, and elaborates a processing response informing the cardholder about the completion of her order, and eventually providing a receipt.

• Unique Internet channel device (channel 1 only): If the ordering form retrieved from the merchant's Web page requires information about the cardholder's payment card, the browsing/ordering Internet channel serves also as a payment channel. This is the case when both phases of the cardholder-merchant interaction can be completed using the same channel over the Internet. Both the browsing/ordering phase and the payment phase are completed in the same session. For this payment method, the Web server includes a script that captures the payment card data received from the Web browser and creates an authorization request that is forwarded to the appropriate acquirer, where the merchant is a client. The access devices of both the cardholder and the merchant do not need supplementary software or hardware resources. However, since the established channel must be secured, both the Web browser and the Web server must be cryptographically enabled.

• The ordering form retrieved from the merchant's Web page contains only the information needed for negotiating a common payment method between the consumer and the merchant. Two peer payment applications, running on the cardholder access device and on the merchant access device, respectively, interchange messages according to a dedicated protocol for completing the payment phase. The protocol, including the security measures considered appropriate for safeguarding the interests of the participants , is specific to each payment application. Thus, the two applications establish a secure communication over an insecure channel. We present two possibilities:

  • Dual Internet channel device (channel 1 and channel 1bis): A separate TCP/IP channel over the Internet is established between the two peer payment applications (e.g., channel 1bis in Figure G.1). This is the case when each phase of the cardholder-merchant interaction is completed using a different channel over the same open network. The payment phase is completed in a different session than the browsing/ordering phase. The cardholder can use the same access device like the one used for ordering/browsing (e.g., a PC). The software configuration of the cardholder and merchant access devices must include the adequate software for running the peer payment application on each side. If the payment card is an EMV ¢ chip card, the hardware configuration of the cardholder access device includes a chip card reader, which is EMV level 1 compatible, together with the appropriate software driver.

  • Dual channel/dual network device (channel 1 and channel 3): A separate PP-SMS channel over the GSM network is established between the two peer payment applications (e.g., channel 3 in Figure G.1). This is the case when each phase of the cardholdermerchant interaction is completed using a separate channel over different open networks. The payment phase is completed in a different session than the browsing/ordering phase. In this case the cardholder may have a separate access device, which can be a mobile phone that is different than the one used for browsing (e.g., a PC). The mobile phone is able to establish the PP-SMS channel and to run the mobile payment application. This mobile payment application can reside directly in the SIM or in a separate EMV ¢ chip card, read from the dual slot of the mobile phone. The dual slot is a chip card reader, which is also EMV level 1 compatible. In addition to the Web server, the merchant device also runs the peer payment application, which must be able to communicate with the SMS center. This center is able to establish an SMS channel with the cardholder mobile phone and to intermediate between the cardholder and merchant peer payment applications.

For supporting a browsing/ordering WAP channel, denoted channel 2 in Figure G.1, the cardholder access device is a mobile phone that runs a micro browser, which interprets WAP content referred by an URL and displays this content to the end user . The merchant access device runs an origin server, providing the WAP content. A WAP gateway provided by the GSM operator encodes the requests coming from the micro browser to the origin server and decodes the responses coming from the origin server to the micro browser. An overview of a typical WAP architecture is presented in Figure G.3.

Figure G.3: Browsing/ ordering WAP channel over the GSM network.

The commercial offer of a merchant is represented as WAP pages, which are stored on the merchant's origin server. The WAP pages can be written with the wireless markup language (WML) and the wireless markup language script (WMLScript) scripting language. The cardholder's microbrowser makes a content request using the URL address of the concerned WAP page. The origin server returns a response that includes the content of this WAP page, which is displayed by the cardholder's mobile phone. The WAP page can also include an ordering form, where the cardholder can make her choice on the desired purchases.

• Unique WAP channel device (channel 2 only): If the ordering form retrieved from the merchant's WAP page requires the information about the cardholder's payment card, the browsing/ordering WAP channel (channel 2 in Figure G.1) also serves as a payment channel. This is the case when both the browsing/ordering phase and the payment phase can be completed using the same WAP channel over the GSM network. Both the browsing/ordering phase and the payment phase are completed in the same session. Since the established channel must be secured, the micro browser, the WAP gateway, and the origin server must be cryptographically enabled.

• Dual mobile channel device (channel 2 and channel 3): The ordering form retrieved from the merchant's WAP page contains only the information needed for negotiating a common card payment method between the cardholder and the merchant. Two peer mobile payment applications, running on the cardholder's mobile phone and on the merchant access device, respectively, interchange messages according to a dedicated protocol for completing the payment phase. A separate PP-SMS channel over the GSM network must be established between the two peer payment applications (e.g., channel 3 in Figure G.1). This is the case when each phase of the cardholder-merchant interaction is completed using a different channel over the same GSM network. The payment phase is completed in a different session than the browsing/ordering phase. The mobile payment application can reside directly in the (W)SIM or in a separate EMV ¢ chip card, read from the dual slot of the mobile phone.