Acquiring focuses on the steps carried out between merchants and banks for processing credit and debit transactions, either through traditional card-based transactions or mobile payments.

The following sections cover these acquiring topics:

When users enter their card personal identification number (PIN) on a device (such as an ATM or payment terminal), the device encrypts the PIN and then sends it to an HSM in the bank data center, along with the account or card number and the PVV or offset (depending on the method). The HSM then decrypts the PIN that the user entered, takes the account or card number, the bank PIN Verification (PVK), and the PVV or offset and derives the actual PIN. Then, it compares that PIN value to what the user entered and approves or declines the transaction.

The data structure for an encrypted PIN is called a PIN block. PINs are typically four characters, but you cannot encrypt only four characters with the DES algorithm. Because you need at least an 8-byte block of data, the payment industry created the concept of PIN blocks.

Embedded in a PIN block are the length of the PIN, the PIN itself, and padding. Then, all of that data is XORed with a portion of the account number. The result is the clear value of the PIN block. The clear PIN block value is then encrypted with a PIN Encryption Key (PEK).

Different standards exist for PIN blocks, and we currently support ISO format 0 and ISO format 3. The new ISO format 4 standard supports an AES PIN encryption key, but AES pin blocks were previously not supported because of issues with AES requiring a 16-byte block of data to encrypt.

This section contains PIN translation and verification commands for Excrypt, Standard, and International command sets:

When you insert (or dip) an EMV card at a terminal, the terminal performs a few validations, such as the type of product (such as debit or credit) and the cardholder verification method (such as chip and PIN or chip and signature). After validations, the terminal requests an Authorization Request Cryptogram (ARQC) from the integrated circuit chip (ICC) of the card.

The following workflow describes the ARQ validation and ARPC generation process:

This section contains EMV validation commands for Excrypt, Standard, and International command sets:

Mobile payments use a combination of specialty hardware and a mobile wallet (such as Google Pay, Apple Pay, Samsung Pay, and so on). Users hold their mobile devices up to the contactless payment terminal. This enables the two devices to communicate over a specific radio frequency, passing encrypted payment information back and forth to complete the transaction. The funds then leave the user's digital wallet and enter the business point of sale system.

Tokenization is another critical piece in enabling mobile transactions and payments. When you set up a mobile wallet, details are sent to your issuing bank. The bank replaces these details with a token, a set of randomly generated numbers. This keeps your account details completely encrypted and protected from fraud.

This section contains mobile payment acceptance commands for Excrypt command set:

Card issuers and banks use card verification values (CVV) to determine when someone uses a forged card in a card-notpresent transaction. Using the card expiration date, PAN data, and PIN, an HSM can cryptographically validate CVV (in its many forms, including CVC, CID, CSC, CVC2, and CVV2) and determine if the card data presented is authentic for online or contact-free payments.

CVC accelerates the process of verifying card data in card-present transactions. The magnetic strips contain the CVC, and card-reading point-of-sale terminals process these codes anytime a card is inserted.

CVV and CVC2 are commonly referenced for card-not-present transactions and are used interchangeably. They are usually in the form of a three or four-digit code on the back of the card, and they are often used in place of CVC for card-not-present transactions.

In online transactions, CVV validation is one of two ways of verifying if cards are authentic (the other method is XML-based authentication). Storage of CVVs in any database is expressly prohibited, but businesses need to have access to the card's public key to decrypt and verify transactions. To secure the CVV, the process uses HSMs to validate and encrypt it.

This section contains CVV validation commands for Excrypt, Standard, and International command sets:

Message Authentication Code (MAC), also referred to as tags, authenticates messages. In other words, MAC ensures that the message came from the stated sender (its authenticity) and has not been changed. The MAC value protects message data integrity by enabling verifiers (who also possess the secret key) to detect any changes to the message content, thus preventing man-in-the-middle attacks and fraudulent hosts or ATMs.

Currently, MACing is not very common in the U.S. for payment transactions. However, in Canada, a government-owned interbank network, Interac, forces participating banks to MAC all payment transactions.

This section contains MAC generation and validation commands for Excrypt, Standard, and International command sets:

We all depend on encryption keys in one way or another. While few people outside the payments industry are aware of this, anytime you present your payment card at a Point of Sale (POS) terminal or use an Automated Teller Machines (ATM), an encryption key quickly goes to work to encrypt the PIN or the primary account number (PAN) associated with your card. This encryption obscures the data and protects against information theft as the transaction goes back to the card issuer for validation. For this process to work, an encryption key must be securely loaded into that endpoint device, such as an ATM, a POS terminal, or even a commercial off-the-shelf device used for payment acceptance.

You load the encryption key onto those devices manually through a process known as direct key injection. For POS terminals and PIN entry devices, this involves bringing the devices to a key injection facility where key administrators manually inject each device. This can be time-consuming and expensive. It requires the upfront cost of maintaining a validated Payment Card Industry (PCI) Level-3 key injection facility (KIF), and the operational costs of shipping devices to the KIF anytime you need to rekey them. For larger devices, like ATMs and gas station payment terminals, key administrators often have to travel to each device in the field to load the necessary encryption keys. For organizations with widespread ATM or POS networks, this can be a significant operational expense with a high susceptibility to human error.

While the direct injection model is sufficient for many organizations, others find a remote key loading (RKL) solution more cost-effective and efficient. With RKL, a remote key server establishes a secure, PKI-authenticated connection with each device and remotely distributes encryption keys without needing physical access to the device. The ability to remotely rekey the device in the field without extended downtime is a powerful time-and-money saver for many organizations.

RKL allows organizations to manage keys for an entire infrastructure by sending cryptographically secure key exchanges from a centralized location. Better yet, you can rekey devices instantaneously with minimal downtime, eliminating the costs of maintaining an injection facility and manual injection.

Successful remote key loading (RKL) operations require collaboration and standardized communication protocols between the device manufacturer and the RKL provider. Trust at both ends of the key exchange is the backbone of RKL, with the RKL provider on one side and the field-level device on the other. A certificate authority establishes this trust, providing the endpoint terminal and the RKL platform with a digital certificate. This certificate is a private key in the public key infrastructure (PKI) that facilitates secure key exchanges. The manufacturer must ensure that their devices have this certificate before deployment.

Furthermore, the endpoint devices and the RKL provider must use the same communication and encryption protocols, which furthers the manufacturer’s role in the process. While the most common and accepted encryption standard for RKL is TR-34, which was developed by ASC X9, there are many others in use depending on manufacturers, geographic location, and other factors. RKL providers need to be accommodating in their platform design to enable integration with multiple manufacturers.

Millions of people use ATMs to withdraw cash every year. In 2016, the United States Federal Reserve noted that 91% of Americans have credit, debit, or other bank accounts, and three-quarters of them use ATMs for cash withdrawals. With so many people depending on ATMs functioning properly, security is a major concern. ATMs rely on network protection and PIN encryption techniques to keep the customer PINs safe.

Compliance and security mandates require you to rotate the encryption keys that encrypt and validate PINs regularly. Before remote key loading became a viable option, keyholders had to visit each ATM in person to rotate keys across the network. As the number of ATMs grew, this process became cumbersome and increasingly infeasible.

Furthermore, Payment Card Industry Data Security Standard (PCI DSS) regulations require all PINs to be encrypted upon capture at the terminal. RKL provides a secure, efficient, and cost-effective method for loading and managing ATM encryption keys across entire ATM networks.

POS terminals have double the encryption work. Like ATMs, they encrypt PINs for debit card transactions, but many merchants also require encryption of the primary account numbers, commonly known as PANs, which are the account numbers associated with credit card payments. While PCI DSS regulations do not require PAN encryption, it's rapidly becoming the norm in the payments landscape. Recent years have seen high-profile data breaches traced back to a lack of PAN encryption. PAN encryption works similarly to PIN encryption, but the technology surrounding PAN encryption is typically called Point-to-Point Encryption (P2PE). Like PIN encryption, P2PE encrypts the PAN at the moment of capture in the POS device.

The encryption mechanisms behind PIN and PAN encryption differ slightly on the payment processing end, but they are the same for RKL. Both processes require reliable access to encryption keys. Most POS terminals have at least two key slots, with separate keys for PIN and PAN encryption.

This section contains RKL commands for the Excrypt command sets:

An ATM network, or interbank network, is a computer network that enables you to use ATM cards issued by a financial institution that is a member of the network to perform ATM transactions through ATMs that belong to another member of the network.

Every active ATM has a PIN Encryption Key (PEK), Master Key, and Key Encryption Key (KEK) loaded on it through Remote Key Loading (RKL). To do this, the payment application on the backend sends a request to an HSM to generate a random KEK, encrypt it under the ATM public key or certificate, and send it to the ATM. The ATM then decrypts the KEK by using the private key associated with the public key or certificate that encrypts it. This key management scheme is called Master/Session.

On the ATM, the KEK (or Master key) encrypts a randomly generated Working Key (or Session key). In this case, the session key is the PIN Encryption Key (PEK).

The PEK is changed out regularly. In some cases, once a day or once every 1,000 transactions. The KEK is changed out less frequently (such as annually or once in the life of the ATM).

Suppose an IBC Bank customer goes to a Chase Bank ATM and inserts their IBC debit card in the card reader. They enter their PIN, which the ATM encrypts under its PEK and sends to First Data Corporation. First Data hosts their STAR Network, which provides debit acceptance at more than two million retail POS, ATM, and Online outlets for nearly a third of all U.S. debit cards.

Because First Data also has a relationship with IBC, they know that the IBC processor is Visa Debit Processing Services (DPS) and therefore initiate the following process:

PIN translation plays a crucial role in all ATM foreign transactions. Between each of the hops in the preceding example, a PIN translation takes place by using the TPIN Excrypt command. Each involved entity has its own PIN Encryption Key (PEK). In addition, between each link in the network chain, a shared PEK is established between the two entities. For example, the process looks like this:

To reiterate, each link in the chain must establish a shared key for PIN translation to occur.

The PCI Security Standards Council established the point-to-point encryption (P2PE) standard in 2012. It stipulates that cardholder information should be encrypted immediately after the card is used with the merchant's point-of-sale terminal and not be decrypted until the payment processor has processed it.

PCI-DSS does not require P2PE encryption. PCI states that if you have a network where clear cardholder data is transmitted, you are within the scope of DSS-compliance requirements. Because of this, when companies started encrypting cardholder data, they correctly assumed that they no longer fell within the scope of DSS. However, PCI caught wind of this and considered that if these companies were encrypting cardholder data, they would need to securely manage encryption keys. Thus, they created the PCI-P2PE security standard, making its requirements even more stringent than PCI-DSS.

In reality, there are primarily two types of companies that deploy P2PE in their payment processing transactions:

This section contains P2PE commands for Excrypt, Standard, and International command sets: