Accepting card payments on board trains, planes and ferries is tricky, because online authorisation of cards can be difficult or impossible with patchy or non-existent communications. To make matters worse, the major card schemes now mandate online authorisation for more types of card transaction. Many card processing systems don’t support offline authorisation at all.

In such situations, on-board merchants may wish to authorise some transactions offline, but the scheme rules are complex, and determining which transactions to accept is also dependent upon a merchant’s risk appetite and whether it is felt to be more important to prevent fraud versus the rejection of legitimate cards and genuine customers.

STS’ G8 payment application includes support for offline authorisation of cards, a feature that has been used by many merchants in a variety of on-board environments for many years. We have previously covered using G8 in offline-only scenarios. However, G8 has recently been updated to support more recent card scheme requirements where terminals are required to be online capable, whether or not communications are generally available when they are in use. This is especially relevant to aeroplane, train and ferry on-board terminals.

This product snippet describes recent changes in G8’s on-board support, as well as summarising all of G8’s features that relate to on-board card payments acceptance.

New features

G8 has recently been updated with the following features:

• Mastercard on-board acceptance rules for online-capable terminals; previously it only supported the subtly different rules for offline-only terminals
• Visa on-board and forced acceptance rules transactions that would otherwise be declined
• Deferred authorisation for EMV, contactless and MSR transactions, even when not specifically supported by the PSP.
• Acceptance of magnetic-stripe only cards, excluding those that require realtime authorisation

Accepting additional transactions

On-board merchants with no network connectivity will find that many legitimate cards are rejected by the standard authorisation rules: Visa requires that all transactions are approved online including EMV chip cards, and Mastercard also require that many cards are authorised online, and in any case EMV cards are capable of declining transactions based on internal counters or other mechanisms to reduce the issuer’s risk. Merchants can therefore choose to accept additional cards at their own risk. The card schemes have various rules about what cards can and cannot be accepted in an on-board environment, and merchants have flexibility within those rules to manage their own risk levels. G8 supports these rules, as described below.

EMV (Chip and PIN)

Mastercard have produced specific rules on what additional EMV transactions may be accepted. They are subtly different for offline-only and online-capable terminals, and G8 supports both. These can be enabled in configuration for any Mastercard cards. Transactions that would not otherwise have been accepted are accepted at the merchant’s risk, but Mastercard’s rules are fairly conservative, in that they effectively require that cardholder verification was successful and that the cards are genuine (checked cryptographically). Although the liability for fraudulent transactions lies with the merchant, transaction costs and chargebacks can be reduced by using Deferred Authorisation as described below.

The Visa Transaction Acceptance Device Guide describes the circumstances where Visa cards may not be accepted even at the merchant’s risk, but these rules do not even require that the card or customer be verified, so the merchant would be exposed to significant risk if they accepted all of the transactions they were allowed to. G8 therefore allows the merchant to tune acceptance of Visa cards, for example by requiring Offline Data Authentication and Cardholder Verification to have been successful. This is accomplished by configuring G8’s Stand-In Processing to accept such Visa cards, and enabling Visa Forced Acceptance for On-Board Transactions; Deferred Authorisation must also be enabled (see below). G8 will submit the card’s ARQC in the deferred authorisation request and the subsequent settlement message.

American Express has long had a stand-in authorisation feature supported by G8. This may continue to be used to accept transactions offline.

Magnetic stripe

Acceptance of magnetic stripe cards offline is always at the merchant’s own risk. Magnetic stripe cards cannot be authenticated, and the cardholder’s identity cannot be verified by the payment process. G8 can authorise transactions offline using a combination of floor limits and service code analysis.

G8 can be configured to make acceptance decisions based on

• Transaction limits
• Allowed service codes – some service codes are not valid for payment
• Whether the service code indicates that the card has a chip (G8 will require that the chip is tried first, and can be configured whether to allow “fallback” to magnetic stripe).
• Whether the service code indicates that the card requires realtime authorisation – that is, some cards must be authorised straight away.
• Blacklists of known bad cards (“hotcard” or “exception” files) that are available from a number of sources; STS’ Secure Blacklist format allows millions of blacklisted cards to be listed with negligible lookup times.
• Detailed IIN (BIN) range files that are available from the acquirer or PSP. STS’ Fast BIN Range format allows extremely detailed sets of BIN ranges with negligible lookup times.

Note that magnetic stripe cards offer no protection from being cloned, so merchants may wish to validate the cardholder by additional means.

Cards authorised in this way can be marked as requiring Deferred Authorisation, to help prevent chargebacks and other charges.

Deferred authorisation

Deferred Authorisation is a process whereby transactions that were authorised offline at the merchant’s risk are authorised before being settled. An authorisation request is sent before settlement; if the transaction is authorised, that authorisation can be used in the settlement file; if the transaction is not authorised, then it might be retried and might eventually be dropped. This process has the advantage of avoiding chargebacks and charges for settling non-authorised transactions, without increasing the merchant’s risk. Force-accepted Visa cards must be authorised by Deferred Authorisation.

Support for Deferred Authorisation is normally provided by the Payment System Provider or switch. The PSP can store transactions requiring deferred authorisation, and can make multiple attempts to authorise them if required, and provide the merchant with status reports.

Some PSPs do not support Deferred Authorisation. In this case, G8 can be configured to perform the Deferred Authorisations itself. This facility is relatively limited, in that there is no way to produce reports or control the process directly. G8 will not currently retry declined transactions – the declined authorisation requests will be stored by the PSP and may be retried through their interfaces instead.

Settlement data

G8 stores settlement data, with sensitive cardholder data encrypted, on disk. The encryption may be part of a P2PE scheme or G8’s encryption feature. G8’s encryption uses standard RSA public key cryptography to encrypt the data; because G8 does not have or need the corresponding private decryption keys, the data cannot be decrypted using information available on the terminal or POS. In a PCI P2PE solution, the card data is encrypted within the terminal, and can only be decrypted at the PSP.

In on-board environments, the POS will typically trigger G8 to send settlement data to the PSP when it is known that there is a network connection available. In environments where intermittent network connections might be available, G8 can be configured to attempt to send settlement data periodically.

Conclusion

STS continues to improve the G8 payment application, distilling 20+ years of payments knowledge into its powerful, simple-to-use systems. G8’s on-board acceptance features have been enhanced to support new requirements for online-capable terminals, and G8’s support for the specific on-board acceptance rules now includes Mastercard’s On-Board Acceptance, Visa’s Forced Acceptance for On-Board Transactions and American Express’ Stand-In. These rules, in combination with Deferred Authorisation, fast blacklist and IIN-range files, custom authorisation rules and other features, allow airlines, rail and ferry operators to balance exposure to risk against rejection of legitimate cards. All merchants can continue to benefit from G8’s support for multiple card readers, multiple PSPs, P2PE, plugins and other features.