G8 is STS’ payment application, which allows merchants and POS developers to accept payments from any one of many different types of card reader. G8’s simple but powerful interface hides the complexity of dealing with different card reader manufacturers, models and payment gateways, so that POS developers only need to integrate a single time, while offering maximum choice.

Point-to-Point Encryption (P2PE) is the concept of encrypting payment card data within a secure element and decrypting it at another secure element. For example, encrypted within a tamper-resistant card reader and decrypted in an HSM located within a gateway’s secure data centre).

The Payment Card Industry Council’s Point-to-Point Encryption standards (PCI-P2PE) are a set of requirements for designing and certifying a P2PE system. The second version of these standards is now applicable. They provides strict requirements for the protection of card data such as the Primary Account Number (PAN) and magnetic stripe data, including the design of card readers, their handling during delivery and in the field, and of software and hardware systems at the gateway. In return, components between the card reader and the gateway may be considered outside of PCI-DSS scope.

P2PE necessarily means that much of the payments processing has to take place within the card reader on a particular implementation of the payment application. This means that POS developers traditionally have to integrate afresh to a new interface, or at least a modified interface, and lose some flexibility of implementation – for example, it is not possible to use STS’ flexible Emvelink EMV Kernel with a P2PE device. STS has added support for a number of P2PE systems to G8, hiding this cost and complexity from POS developers.

Ingenico’s PCI-P2PE offering is called Ingenico OnGuard. It uses a form of format-preserving encryption to try to reduce the amount of work required to transition from existing Ingenico integrations. Format-preserving encryption means that, for example, the PAN still looks like a valid PAN, with the correct leading 6 and trailing 4 digits for printing on a receipt, and a valid Luhn check digit. However, the payment systems between the card reader and the gateway still need to be modified to transfer additional data such as the Key Serial Number, which is an identifier and counter that is required to decrypt the data. Also, the encrypted form of the PAN can not be used as an identifier, as a PAN might have been, since the same PAN would never be encrypted to the same value twice.

G8’s API offers greater choice as it presents a more abstract view of taking payments to the POS. This means that G8 does not need to leverage the format-preserving encryption used in OnGuard. Existing integrations to G8 are protected from changes by G8’s abstracted payments API and consistent configuration format, and can continue to use G8-generated receipt data and so on, without even knowing that there is no longer a plaintext PAN or magnetic stripe data available.

Considerations for payment gateways

Because the payment gateway is the decryption endpoint, its software must necessarily be modified to support OnGuard data. G8 does not send a plaintext PAN, expiry date, Track 2 Equivalent, Track 1 or Track 2 data in any requests. Instead, the following OnGuard specific fields are sent:

• Encrypted PAN – The encrypted Primary Account Number. This is present in all request messages.
• Encrypted Expiry Date – The encrypted Expiration Date. This is present in all request messages.
• Encrypted Track 2 Equivalent Data – For ICC transactions where the card also includes Track 2 Equivalent Data.
• Encrypted Track 1 Data – Included in authorisation requests for magnetic stripe and contactless magnetic stripe data (MSD) transactions where the card includes Track 1 Data.
• Encrypted Track 2 Data – Included in authorisation requests for magnetic stripe and contactless MSD transactions.
• Key Serial Number – An identifier that allows the decryption appliance to select the key needed to decrypt the fields above. This is present in all request messages.

Note that the format-preserved Encrypted Track 2 Equivalent, Track 1 and Track 2 Data fields cannot be decomposed into a PAN and expiry date and subsequently decrypted. G8 provides a separated PAN and Expiry Date field sourced from the card reader in settlement notification messages.

Additionally, G8 sends the following fields for all requests, whether P2PE is enabled or not, so that gateways that don’t require the whole PAN when doing local processing, such as IIN-range lookup, can do so using a single code path:

• Application PAN Redacted – The PAN, with at most only the first 6 and last 4 digits visible. Other digits are replaced by asterisks. Depending on the underlying P2PE system, more digits may be redacted.
• Redacted Track 2 Data – Track 2 data, with at most the first 6 and last 4 digits of the PAN and the expiry date visible. Other digits are replaced by asterisks.

If the gateway supports G8’s Validation Data request, then it has to be able to deal with changes in this data, too. G8 assumes that the gateway will not be able to decrypt data during a validation request, due to the time cost of doing so. Therefore, for magnetic stripe transactions, G8 checks the Service Code with the card reader without requiring the gateway’s input. For this reason, the gateway only has to handle IIN-range checking, to ensure that the card is acceptable.

The encryption format and decryption algorithms are proprietary to Ingenico. Gateways must contact Ingenico for details on the software and hardware required to decrypt OnGuard data.

Considerations for POS systems

G8’s API aims to provide an abstract interface that hides the complexity of taking payments. It does this by representing the tender process as a series of events with a final outcome, and by presenting the data such as receipts that is needed by the POS under most circumstances as opaque fields that do not support or require special processing. A typical POS integration to G8 is unlikely to require changes to support OnGuard, as long as the following guidelines are followed:

• Generate receipts from the receipt data supplied by G8 in a receipt printing request, or on the TenderResult object. These receipts are presented as a series of field names, formats and values, without any semantic meaning, that simply need to be merged into other receipt data. Do not use the individual fields on the TenderStatus and TenderResult (such as getPAN()) to build receipts; getRedactedPAN() may be used instead if a printable PAN is required – this will always be present. If these fields are used, be prepared for them to be missing, depending upon the rest of the system.
• Do not use the PAN – doing so would make PCI-DSS compliance harder in the first place, and the PAN is not available with P2PE. If it is necessary to display a PAN, use TenderResult.getRedactedPAN() instead.
• Don’t rely on TenderStatus and TenderResult accessor functions that return card or transaction data. Different kernels and P2PE systems return different subsets of these values.
• Be prepared for new (unknown) error codes. STS have added an EXTERNAL_KERNEL_ERROR code, which is used when the device fails. STS does not add new error codes very often, but the default behaviour for unknown error codes should be for the POS to behave as if a payment was not accepted.

Considerations for system integrators and merchants

STS has invested considerable effort in ensuring that G8’s configuration files will be compatible between different kernels and devices.

The system integrator has to configure G8 to use Ingenico OnGuard in the first place. This is done by configuring tender.properties with the following setting:

p2pe.scheme = onguard

Although typical configurations of G8 are fully supported, the Ingenico device is not quite as flexible as STS’ Emvelink EMV Kernel, so some particularly complicated payments configurations will not be supported. The document “Using Ingenico OnGuard P2PE with G8” which is included in the G8 SDK has details of those configuration options that are restricted or cannot be supported. In particular, some EMV configuration options can be set with different values per AID and per transaction type, while the Ingenico kernel can sometimes only vary these by RID (i.e. Scheme).

PCI-DSS certification

The advantage of using an approved PCI-P2PE solution is that none of the intermediate components need to be checked as part of a PCI-DSS certification subject to the agreement of the QSA. This includes G8, the POS, and the merchant’s networks. G8’s PA-DSS certification is not relevant when using a validated PCI-P2PE solution.

A PCI-P2PE certificate covers the whole of a solution. Many retailers may want a more bespoke solution that uses OnGuard’s P2PE technology without going through the full PCI-P2PE validation process. In this case, intermediate components would be in PCI-DSS scope, but the OnGuard solution and G8’s PA-DSS-compliant status will make PCI-DSS approval significantly easier.

Conclusion

Ingenico’s OnGuard offers many security benefits, and can be used to reduce the cost and time it takes to achieve PCI compliance. However, Ingenico’s proprietary encryption mechanism and API can make migrating from a different system more expensive than necessary, and merchants could be locked in to using Ingenico devices. G8’s easy-to-use, consistent APIs and configuration can help POS providers and gateways to offer OnGuard support by reducing the cost of moving to (or away from) use of Ingenico OnGuard devices.