Securing Merchant Environments Is Good, Securing the Credit Card Itself Is Better 

Download Article Article in Digital Form

The advent of the Payment Card Industry Data Security Standard (PCI DSS) resulted in many organizations mandating its use. However, in many initiatives, the regulatory compliance projects face difficulties in funds allocation because it is easier to justify and calculate the projected cash benefits for projects that deliver products or services than for projects of regulatory compliance deliverables such as those related to PCI DSS.

One of the important factors that impact the cost and time in PCI DSS compliance projects is the lack of a realistic definition of scope of work. A major challenge to the project sponsors and managers is defining the gap between where the organization stands on PCI DSS requirements and the amount of work required for it to become compliant. Spending more effort on the planning phase can help to control the cost and time spent in the later phases of the project.

There is no doubt that the reliance on credit cards as a method of payment has increased, and the necessity of providing security, integrity and availability around the credit card environment is continuously pressing as the number of merchants and service providers, processes, stores, and transmissions of credit card data is projected to increase in the future. In 2011, IT research firm Gartner’s survey of 77 US retailers revealed that PCI compliance continues to be aggressively enforced by the card brands and spending with credit cards has continued to increase since 2008.1 A survey conducted by Federal Reserve Bank of Boston in 2010 found that 72.2 percent of consumers had used a credit card in 2009.2 On the other side, the number of credit card holders has increased in the US from 159 million in 2000, to 164 million in 2003 and 176 million in 2008,3 and in 2012 the estimated number of credit card holders in the US is 181 million.4 Visa made US $6.3 trillion worth of transactions (payments and cash transactions) over the four quarters ending 30 September 2012.5

The challenges of bringing a PCI environment into a new compliance system include, but are not limited to, the following:

  • Sensitivity of the credit card information
  • Strictness of the compliance requirements
  • Zero tolerance of breach
  • Different organizational structures, culture and management styles among credit card clients
  • Implementation of the right technology
  • Embracing changes in the established business processes, policies and procedures
  • Maintaining compliance (sustainability)

The Smart Credit Card Solution

The current approach to securing credit card holder information focuses on securing the credit card client’s (merchant’s) environment in compliance with industry standards to protect card information from theft and fraud.6 The proposed Smart Credit Card (SCC) approach looks to secure the credit card holder information from a different perspective.

SCC intends to eliminate the risk at its source: the credit card. This entails replacing the current credit card with one with more features and intelligence. This proposed credit card will resemble a small, ultrathin calculator with a smart chip that contains all the credit card holder information. It also contains a minimal processing capability to generate a random and temporary credit card number (TCCN) at each transaction. The random numbers are derived from the unique and individual credit card for each cardholder based on a strong algorithm. Each cardholder will have a unique set of temporary numbers, generated randomly on usage. To use the SCC, the user needs to enter a password on the credit card itself, preventing misuse of the credit card in the case of loss.

Figure 1The SCC, which weighs no more than and is similar in size to a current card, has the following technical features (figure 1):

  • A seven-segment display capable of displaying 16 or 32 digits
  • A smart chip containing the cardholder’s information
  • Two touch buttons: request for confirmation (RC) and correction (CORR)
  • Touch buttons from numbers zero to nine
  • A unique number not necessarily printed on the card

Money transactions will have two processes based on business requirements: standard (STD) and request for confirmation (RC). The STD process is for a regular money transaction through a merchant point-of-sale (POS) device. This transaction is only for one-time use and for a specific amount of money. The steps for an STD transaction are:

  1. Merchant calculates the amount of purchase and requests payment from buyer.
  2. Buyer presents the SCC and enters the password on the card for activation.
  3. By default, the SCC is activated to the STD process unless the buyer selects the RC option.
  4. The SCC automatically generates a temporary credit card number (TCCN); this number is derived from the holder’s unique credit card number using a strong algorithm.
  5. Once the credit card is inserted in the merchant’s POS device, the TCCN number is tagged for the dedicated buyer, merchant and acquiring bank. This number cannot be used for another transaction in case of theft as it expires after one use. The possibility that the SCC generates a used number for a particular cardholder must be no more than three in one million transactions; this ratio is based on the Six Sigma best practice objective of quality that strives for near-perfection.
  6. The amount of the sale is either manually entered or the product bar code scanned and automatically transmitted by the cash register.
  7. The merchant transmits the buyer credit card data and sale amount with a request for authorization to the acquiring bank.
  8. The transaction process concludes with the regular activities of verification and authorization of the credit card payment process, which is not limited to, but includes the following main steps:
    • The acquiring bank sends the authorization request to the card-issuing bank.
    • The issuing-bank sends approval to the acquiring bank and forwards it to the merchant’s POS.
    • Buyer signature is obtained on a sale slip print-out from the merchant POS.
    • The sales draft is interchanged between the acquiring bank and the card-issuing bank.
    • The amount of sale is deposited to the merchant’s bank account by the acquiring bank.

The RC process is designed to satisfy the business requirement of confirmation of money transactions. It is appropriate to use with credit card number provisions for purchases made over the phone, when filling out an electronic application or filling out a paper application. It can also be used with a merchant’s POS device. The steps for an RC transaction are:

  1. The amount is either known, entered by the buyer in the online or paper application, or it is communicated over the phone by the merchant. In case of using a POS device, it is manually entered or automatically transmitted by the cash register.
  2. The buyer enters the password on the SCC for activation.
  3. The buyer presses the RC button. This automatically generates a temporary credit card number (TCCN) that is derived from the unique credit card number of the cardholder using a strong algorithm. The number is tagged with the request for confirmation, which will put the transaction on hold for 72 hours for the buyer’s confirmation. The 72 hours start from the date and time of purchase.
  4. If the buyer requires multiple transactions, the buyer should enter the required number of transactions immediately after pressing the RC button. For example, if the buyer presses RC followed by the number 12, this means the buyer authorizes the merchant to draw money 12 times using the same TCCN. Confirmation from the buyer is necessary for each request whenever it is due.
  5. Based on the purchase method, the buyer communicates the TCCN that shows up on the SCC display screen to the merchant either verbally over the phone, by writing it down in the online or paper application, or by sliding the SCC into the merchant’s POS device. The money transaction will not be completed until the buyer confirms the purchase or the 72-hour period has elapsed.
  6. To complete a transaction, the confirmation request is sent to the buyer as:
    • A text message sent to the buyer’s registered mobile phone. The buyer needs to reply to the message with “yes” to confirm or “no” to decline.
    • A message sent to the buyer’s online bank account. The request will be listed in a queue waiting for the buyer’s confirmation for each request.
    • A phone call to the buyer’s bank using the bank’s interactive voice response (IVR) system to confirm the transaction

The buyer can also go to the bank and personally ask the teller to confirm the pending requests. The buyer must provide confirmation within 72 hours from the purchase date and time; otherwise, the transaction will automatically proceed and the buyer will have all responsibility in the case of false representation.

The buyer’s confirmation for each purchase is important for two reasons:

  1. Helps to prevent illegitimate transactions
  2. Declines unauthorized purchase of any commodity or service
The SCC solution benefits include:
  • Significantly reduces fraud-related activities due to the utilization of the TCCN concept and the RC feature
  • Is easy and quick to use
  • Allows merchants to focus on implementing their overall security strategy for the whole environment without the need to address the security of the cardholder data environment, as the latter is being handled by the SCC
  • Helps businesses avoid penalties and the risk of not being PCI-compliant
  • Saves merchants and service providers from the cost of PCI compliance projects and the cost of PCI sustainability—thus allowing them to focus on their core business
  • Enhances business reputation and increases client trust, leading to the increased use of credit cards as the mode of payment

The SCC Solution and the PCI Control Objectives

The SCC solution has two payment processes. In the STD process, the TCCN is valid for one usage only, and if the TCCN is stored, processed or transmitted, it will require no implementation of PCI compliance security measures.

In the RC process, the TCCN can be used multiple times, and gets stored at the merchant environment, but in the SCC solution, the liability shifts from the merchant to the cardholder by providing the cardholder the ability to confirm each transaction. For a transaction to complete, the cardholder must provide approval within 72 hours of the transaction initiation. The cardholder is legally responsible for any breach. Merchants, service providers and credit card issuers must make sure cardholders are aware of this responsibility.

In the SCC solution, the real work of PCI DSS compliance requirements implementation is mainly focused at the card-issuing bank where the primary account number (PAN) of the cardholder is stored, processed and transmitted. Furthermore, the environment where the encryption keys are stored and the keys used to decrypt the TCCN to identify the actual account number, cardholder name and other required information to complete the transaction must be secured in accordance with PCI DSS requirements.

Alternative Approach: Credit Card with Wireless Interface

The proposed SCC solution provides the technical capabilities to enable the credit card to generate the TCCN by itself. An alternative solution would be adding a wireless feature to the credit card. In this approach, the same steps of the SCC process are followed with the single exception of generating the TCCN remotely and, in case of the RC process of payment, having the confirmation request received on the card itself.

The alternative wireless approach works with the credit card sending a remote request for a TCCN to the card-issuing bank through a wireless connection; the card-issuing bank processes the request, identifies the card holder account, generates a temporary and unique TCCN based on a strong algorithm, and sends a TCCN to the credit card. If the transaction requires confirmation from the cardholder, a request for confirmation is received on the card itself, and the cardholder is given the capability to approve or decline through the credit card. Serious considerations would need to be taken into account when adopting this approach, specifically:

  • Wireless coverage
  • Security
  • Responsiveness


The SCC solution is proposed to provide a different security framework that provides peace of mind to all parties—the merchants, the credit card issuers and the customers (credit card holders). The current PCI compliance implementations focus on securing all merchants’ environments by adding controls to business processes, modifying applications, removing data with credit card information and changing network configurations as needed. The proposed solution adds control at the credit card level. The solution features and components can be summarized as follows:

  • The credit card is changed to include features with more intelligence and processing capabilities.
  • The credit card is protected by password, which can be used by the legitimate holder only.
  • The credit card numbers are dynamic; different transactions use different credit card numbers.
  • The generated TCCN is created randomly by a strong algorithm that uses the unique number given to the cardholder account by the card issuer.
  • In the case of the one-time payment option (STD procedure), once the TCCN is used, it is no longer valid for additional payments.
  • The cardholder always has the option to request confirmation (RC procedure) if there are multiple payments on the same TCCN or if it is required by the cardholder for one reason or another. The cardholder can set the number of payments in advance on the credit card itself.
  • Cardholders have the option to control their own transactions by approving or declining money transactions through different methods.
  • The cardholder confirms the money transactions through one of the following methods: text message, online bank account, using a bank IVR system or in person at the bank.



1 Gartner Survey, “PCI Compliance Activity Shifts Downstream as Aggressive Enforcement Continues,” June 2011
2 Federal Reserve Bank of Boston, “The Survey of Consumer Payment Choice,”, 2010
3 US Census Bureau, 2010
4 Visually Inc., “2012 US Credit Card Usage Statistics,”
5 Visa Inc., “Visa Inc. Corporate Overview,”
6 Javelin Strategy & Research, “Identity Fraud Industry Survey Report,” 2012,

Ali Alaswad, ITIL, PMPG, PMP, is president of Nadine Technology Solutions Inc. With more than 20 years of experience in IT, he has been working in diversified technical domains with a focus on IT standards and compliance and project management. Alaswad has worked in various industries including government, aviation, telecommunications, energy (oil and gas), IT service, retail and health care.

Enjoying this article? To read the most current ISACA Journal articles, become a member or subscribe to the Journal.

The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.

© 2013 ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.