In today’s world, payment cards (credit and debit cards) have become the primary form of payment, replacing cash and checks in traditional retail environments.  Using payment cards at point of sales terminals becomes ever more convenient through contactless payments and mobile phone apps.  The rise of e-commerce has further accelerated the prevalence of payment cards. 

Today’s businesses are expected to accept card payments.  A 2021 report issued by the United States Federal Reserve Bank of San Francisco noted that payment cards are used for more than half of all payments, and this percentage rises every year. Card usage for spending on not-in-person, non-bill payments has increased substantially. Similar trends were noted by the European Central Bank, where cards are the “fastest-growing electronic payment instrument.”

Several technical solutions are available for accepting card payments, but an organization’s choice can have significant business, financial, and legal consequences.

This blog entry explores options for securely handling these card payments while leveraging the opportunities to simultaneously minimize information security risk, reduce compliance burden, and reduce operational costs.

What is payment card data?

Both credit cards and debit cards qualify as “payment cards”. Payment card data consists of:

  • Cardholder data such as the person’s name, primary account number (PAN), and card expiration date
  • Authentication data such as electronic data stored in the magnetic stripe and in a card’s embedded chip, personal identification numbers (PINs) and verification codes printed on cards

It is equally important to understand what does not qualify as payment card data. There are two common methods to transform a payment card account number so that it no longer qualifies as payment card data: 1) truncation via data redaction; and 2) tokenization. Let’s explore each option in detail.

  1. When truncating a primary account number (PAN), the system retains only a portion of the original payment card account number, such as the first 8 and last 4 digits but replaces all other digits with a ‘x’ or another character when the data is stored. A redacted account number looks like this in the database: “1234 5678 xxxx 1234”.  Truncation modifies the data –  the full account number is no longer stored or processed. This is a more robust security control than mere data/field masking, in which the full account number is still stored but the application displays only a portion of it.
  2. Tokenization is the process of exchanging the entire payment card’s primary account number (PAN) for a replacement value. Typically, a tokenization Service Provider stores the actual PAN, and transmits only a substitute value back to the merchant.   Tokens can be used for future/recurring transactions and refunds, but those transactions will only succeed if they’re submitted by the merchant to which the token was issued. That restriction reduces the motivation for unauthorized access to tokens, since they cannot easily be used for fraudulent purchases as with payment card data.

Which global industry standard applies when handling payment card data?

Every company which accepts payment cards for their own revenue or handles payment card data transactions as a Service Provider to other companies is subject to Payment Card Industry Data Security Standards (PCI DSS). This is a global industry standard published by the Payment Card Industry Security Standards Council (PCI SSC). 

PCI DSS contains several hundred detailed requirements encompassing a broad set of information security policies, processes and technical controls across all layers of application architecture and supporting networks. The standard also includes detailed testing procedures for auditors, along with interpretation guidance. 

Achieving and maintaining PCI DSS compliance typically requires planning, sustained diligence and investment in processes, tooling and operational security controls. It is recommended that all companies review the PCI DSS applicability and scoping sections carefully to correctly identify systems in PCI DSS scope and those which could impact the security of the cardholder data environment (CDE). Accurate scoping is critical to PCI DSS compliance.

While complying to these requirements can be challenging, not all PCI DSS requirements apply to all payment acceptance architectures.

How is compliance to PCI DSS validated?

Annual PCI DSS compliance validation (audit) and reporting requirements are defined by the payment brand data protection programs. The major payment brands are American Express, Discover, JCB, MasterCard and Visa. Several payment brand programs define criteria for assigning levels to merchants and Service Providers. Each merchant or Service Provider level has PCI DSS compliance validation and reporting requirements, such as a mandate to perform an annual audit by an external Qualified Security Assessor (QSA) or the option to perform a self-assessment.

What has changed in recent years?

Not only have the PCI DSS requirements expanded – applicability has also broadened. Systems used to be outside PCI DSS scope if they didn’t directly handle the payment card data but only controlled how a customer reached the payment Service Provider (such as via an integration or redirect). Now those applications are in PCI DSS scope, even if they do not process payment card data at any point.  

What are the architecture choices for accepting payment cards?

Various architecture options are described in PCI SSC’s Best Practices for Securing eCommerce Guide, along with the implications of each design. Organizations can select a system architecture which minimizes PCI DSS scope and the number of applicable requirements. See the architecture comparison below which uses the terminology from PCI SSC’s eCommerce Guide:

         Architecture

                                       Description

       PCI DSS Scope & Applicability

Redirect method

or

IFRAME method

System only controls how consumers reach a Service Provider’s web page for providing payment card data but system does not directly process payment card data.

Smallest set of applicable PCI DSS requirements and fewest components are in scope

Direct Post method

or

JavaScript Form method

System provides the payment web page to a consumer. Payment card data is transmitted directly from the consumer’s browser to a Service Provider to be exchanged for a replacement token. System stores only the token.

Most PCI DSS requirements apply to the entire environment

Application Programming Interface (API) method

System collects payment card data and transmits it to a Service Provider for a replacement token. System stores only the token.

Most PCI DSS requirements apply to the entire environment

Other methods

System collects payment card data and stores the payment card account number (PAN).

All PCI DSS requirements apply to the entire cardholder data environment

 

What is the recommended approach to maximize security and minimize risk?

Websites and applications which adopt the redirect or IFRAME architecture incur both the least risk and the smallest compliance burden (in terms of operational controls and audit costs), while still enabling payment card transactions. This can also be the fastest design to implement. It is the gift which keeps on giving.

Oracle offers a variety of software, cloud applications and industry applications which support redirect, IFRAME and the other architectures, to help organizations conduct business according in accordance with their security, compliance and risk management objectives. Learn more about these offerings:

 

What does this mean for merchants/vendors?

1. Organizations should first consider the current industry standards and their security and compliance objectives, as suggested in this post: compliance considerations for using cloud services.

2. Factor in changes made in Payment Card Industry Data Security Standards (PCI DSS) version 4. 

3. Consult your merchant bank (acquiring bank) or PCI DSS Qualified Security Assessor (QSA) for guidance about managing payments and PCI DSS compliance requirements.

 

For more information: