STS’ G8 products are designed to be used in many different environments. This article examines G8’s capability in offline-only environments, where there is no possibility to perform online authorisation, and limited connectivity for sending settlement files; for example, on board aircraft, trains or buses, or in unconnected, unattended terminals like vending machines or car park terminals.
G8 is also usable in situations with limited or transitory connectivity for online authorisations, such that it can authorise transactions offline after trying and failing to get online authorisation. Though it is not the main subject of this article, many of the same concepts apply.
Overview
Offline processing is covered by many different rules from different sources (EMV, the Schemes) as well as the merchant’s preferences towards transaction flow and risk. If merchants follow Scheme and EMV rules for both chip cards and magnetic stripe cards then they do not take on much risk, but may be forced to reject cards that could otherwise have been used. MasterCard does have some specific rules that allow a merchant to accept some cards even if EMV processing would have declined them but some cards will still be rejected; if the merchant wishes to reject fewer cards, then they must do so with the cooperation of their acquirer, and generally have to take on the risk for fraudulent transactions.
Configuring G8 for offline processing therefore covers many different aspects of transaction processing: the transaction flow, EMV configuration, EFT configuration, BIN range and blacklist file and the settlement process. These aspects are examined in more detail below.
EFT system
The G8 EFT system consists of a number of different drivers that allow transaction data to be sent to different PSPs (Payment Service Providers, or Processors) for processing. While the communication protocol is different for all of these drivers, they are configured in the same way to support offline authorisation. They can also all store settlement data locally to be sent to the PSP when possible (see Settlement, below).
Offline-only systems can still use any of the G8 EFT drivers. Offline-only drivers such as apacs29sts.fileOnly cannot support online authorisation. Other drivers that can support online authorisation should be configured with an invalid host (for example, a hostname defined by the relevant standards to be invalid, such as “eft.invalid”) for validation and authorisation; this will cause them to fall back to offline processing magnetic stripe transactions.
An EMV kernel configured as an offline-only Terminal Type will never request online authorisation, and transactions will be authorised offline according to EMV and scheme rules: see EMV configuration, below, for more details.
If the merchant is accepting magnetic stripe transactions, they need to configure G8’s offline BIN ranges and blacklist. There are a number of trade-offs between fraud risk, unnecessarily rejected transactions and PCI compliance that have to be balanced by the integrator on behalf of the merchant. See Offline magnetic stripe authorisation.
EMV configuration
Configuration for offline-authorised EMV transactions is configured in terminal.emv.properties, whether you are using the Emvelink EMV Kernel or another kernel such as Ingenico RAM. Details may be found in the Emvelink Configuration Guide. Typically the basic configuration options will be provided by the acquirer: there will be specific settings for Terminal Type (21) and Terminal Action Codes and Floor Limits, as well as the usual settings for Certificate Authority keys. The EMV Kernel manufacturer will have specific EMV L2 approvals, and you must choose the Terminal Type and Terminal Capabilities from those approved kernel configurations.
MasterCard “on-board” processing
For deployment scenarios that count as “on-board”, the terminal can be configured to accept certain EMV cards that would otherwise be rejected. On-board terminals are those used on trains or buses or in similar scenarios. You must consult your acquirer before activating this setting. The on-board rules allow the terminal to accept a MasterCard card as long as PIN verification was successful, and the transaction was approved by the terminal but declined by the card. Typically this applies to cards that have internal counters that indicate that they have done too many offline authorisations and now require an online authorisation.
On-board processing actually applies to both online-capable and offline-only terminals, though the rules do differ slightly. On-board rules are activated in the same way whether the terminal is online-capable or offline-only.
On-board processing is activated by setting byte 1 bit 1 of tag DF54 (Payment System Specific Settings) in terminal.emv.properties. Consult the Emvelink Configuration Manual for more details.
Accepting more cards
Most modern EMV cards have internal counters that ensure that they gain online authorisation regularly, to allow the Schemes and issuers to manage fraud more effectively; generally, once some limit has passed, these cards will request online authorisation and will decline if it could not be achieved. Some cards, such as Maestro or Visa Debit cards always require online authorisation. In an offline-only environment, these cards will always be declined, which may be frustrating for the cardholder, and may lead to loss of sales for the merchant.
Generally merchants do not take on liability for transactions that were accepted according to the Scheme rules, even if those transactions turn out to be fraudulent. Some merchants may wish to take on liability for accepting fraudulent transactions, in return for being able to accept these cards. Examples of this may be the ability to accept all cards that have passed Data Authentication and Cardholder Verification (i.e. those that are cryptographically shown to be secure, and for which the cardholder knows the PIN), or just cards below some limit, or by forcing a voice-referral for particular cards, or some combination. G8 supports all of these possibilities; consult the Emvelink Configuration Manual or contact STS Support for more details.
Contactless configuration
Offline-only contactless configuration is straightforward: an appropriate certified kernel configuration must be chosen, and touchlink.emv.properties must be configured with parameters received from the acquirer. As there is no possibility of performing online authorisation, more transactions than usual will fall-forward to full EMV processing.
Offline magnetic stripe authorisation
In EMV-enabled regions of the world, Scheme rules require that all magnetic-stripe transactions are authorised online. Authorising magnetic stripe transactions in an offline-only environment typically requires that the merchant takes on liability for all magnetic-stripe transactions approved offline. Additionally, Scheme rules or merchants may require that EMV-capable cards cannot be accepted using magnetic stripe.
Configuration for offline processing of magnetic stripe transactions is therefore almost entirely driven by the merchant’s appetite for fraud risk versus lost sales.
If the merchant does wish to accept magnetic stripe transactions, there are two primary configuration files that they can use to manage risk: offline BIN (IIN) range files, and a card blacklist (also known as hotcard or exception file).
Fallback
It is typical for offline-only terminals to disallow fallback – that is, to prevent cards that have an EMV chip from being accepted in “fallback” or “downgraded” mode, using the track 2 data. This is configured in G8’s tender.properties; consult the G8 Configuration Guide for more details.
BIN ranges
In online-capable scenarios, G8’s offline BIN range file is typically very simple, just providing different information for different card schemes; all transactions will be authorised online anyway. In offline-only terminals, the offline BIN range file is likely to be very detailed, with several thousand entries, based on up-to-date BIN range files from the acquirer or another provider. These files allow the merchant to accept only cards that are in ranges that are in active use by issuers.
G8’s binary BIN range format allows extremely large BIN range tables to be configured and used even on low-powered devices. The BIN range file is not loaded into memory, but is efficiently queried on disk; this means that G8 does not use much RAM for the BIN range file, but still performs lookups in fractions of a second.
Offline BIN range files are typically generated by first creating a (human-readable) “BIN-range feed-in file” and a “profile file”. The profile file defines various card profiles (i.e. MasterCard, Maestro or Visa cards). The feed-in file defines all of the configured BIN ranges, and indicates which profile each range applies to. Before use in G8, the feed-in file must be converted into the binary format using a tool provided with the G8 SDK. See the “G8 Configuration Manual” for more details.
The BIN range file may be used in conjunction with the hotcard file to reject individual cards.
Blacklist/hotcard/exception file
Blacklist files are distributed by various providers with varying numbers of listed cards. The most detailed files may contain around 3 million entries. Additionally, there is a PCI-DSS-compliance angle to blacklist files, as the card numbers listed in them are actually real card numbers, and therefore count as sensitive authentication data.
G8 has a binary file format that allows such large files to be stored and queried efficiently on disk, without using large amounts of RAM and without storing plaintext card numbers. The blacklist file is an oracle, constructed by storing only hashed card numbers; when a card is looked up, it is first hashed, and then the hash is searched-for in the file. If the hash is present, then the card is on the blacklist; the hash algorithm ensures that the likelihood of collisions and false-positives are negligible.
There is a security trade-off between speed of access and file security. In order that the fast lookup can be performed, all PANs in a single blacklist file have the same salt. This means that each file is susceptible to certain recovery techniques. Therefore, we recommend that you use an extremely large salt, and that the PANs are randomly distributed across multiple files each with a different salt. The trade-off is that the processing time to determine that a card is not on the blacklist will scale linearly with both the salt length and the number of files, but only logarithmically with the size of each file. Integrators should ensure that they tailor the salt size and the number of files to the capabilities of the deployment environment, whilst maintaining a reasonable barrier to recovery of all PANs in the file.
Settlement
In an offline-only scenario, settlement data must still be transmitted to the PSP when possible. This process may take a number of forms:
The apacs29sts.fileOnly driver writes an APACS 29STS-formatted file that the integrator’s systems must process and transmit.
Other EFT drivers will transmit data when triggered
Online-capable EFT drivers can constantly attempt to transmit data, such that settlement data will automatically be sent when connectivity is established
To trigger file creation or a transmission process, the integrator must use the Settlement API. The Settlement API allows the process to be triggered, and the result of that process to be examined. The API will report if there are any errors in stored files or the transmission process (for whatever reason).
PCI-DSS
Most G8 drivers store settlement card data encrypted using a public key (or using a symmetric key itself encrypted using a public key). The private-key counterpart is stored remotely by the EFT server, and is never downloaded to G8. This means that the card data cannot be recovered using information held by G8. G8 only stores the data required for authorisation, and does not store sensitive authentication data after authorisation.
Track 2 data can be stored encrypted if the EFT server supports a process whereby magnetic stripe cards are authorised post-hoc before being settled; this technique is used to reduce the number of chargebacks a merchant may receive for fraudulent transactions, meaning that the merchant’s costs are reduced to just the lost goods or services. The use of this must be balanced against the risks of storing track data.
Conclusion
STS’ G8 EFT client provides an integrator or merchant with the tools required to accept transactions in offline-only deployments, supporting all the major card brands. It supports MasterCard rules to allow merchants to accept transactions in on-board scenarios, and allows merchants to balance their exposure to risk against rejection of legitimate cards according to scheme rules. Merchants can continue to benefit from G8’s support for multiple card readers, multiple PSPs, P2PE, plugins and other features.