STS’ G8 payment acceptance application has integrations to a variety of different Payment Service Providers (PSP, also called a switch or gateway) using protocols that those providers have defined. For some projects, it is better for the PSP to integrate to a new protocol, rather than G8 integrate to the PSP: for example, it may be the PSP’s preferred method of operation, or because the PSP is entering the card present market from card-not-present and doesn’t have their own protocol defined. For this reason, STS have also defined a PSP protocol that is independent of the PSP, called the G8 EFT protocol.
The G8 EFT protocol supports G8’s full feature set, including “validation data” requests, online and offline authorisation, online-only, online-capable and offline-only terminal types, settlement notifications and trickle-fed notifications, custom data transfer, and so on.
Overview
The G8 EFT protocol is defined in the G8 EFT Protocol Specification, included as part of the G8 SDK and available on request from STS. The protocol consists of four request/response exchanges of XML messages, transported either over HTTP(S) or a lightweight TCP/IP-based protocol.
The G8 EFT protocol is G8’s default EFT driver – you must specify at least the URL (or hostname and port) for the server. It is also possible to configure more complicated retry and failover behaviours either for all messages or for individual message types: for example, authorisation messages can be routed via a backup server to maintain level-of-service, but store-and-forwarded settlement messages can be sent to a single specific host.
Online and offline operation
The G8 EFT protocol supports online-only, offline with online capability, and offline-only operation, depending on the requirements of the merchant, PSP or acquirer. Whether authorisation occurs online or not, settlement data will be sent to the PSP immediately if possible, but can be securely stored offline in the event of service interruption.
In common with most chip-and-PIN (EMV) terminals, G8 can operate in an “offline with online capability” mode, which allows transactions to be accepted offline unless card or terminal risk management requires online authorisation. In this case, G8 is able to approve transactions below the acquirer’s floor limit entirely offline, and can also authorise most transactions offline in the event of a failure at the PSP, acquirer, Scheme network or issuer. Further, G8 is able to securely store each transaction in case the PSP is temporarily offline at the end of a transaction.
When used with online-only authorisation, G8 can still store settlement data offline to be sent later to account for brief service interruptions, but will always require connectivity at the time of authorisation.
Finally, G8 is able to operate fully offline: in this case, settlement data will be sent when there is a network connection available and sending is invoked by the POS.
The messages
The G8 EFT protocol consists of four request/response exchanges: validation data, authorisation, reversal and settlement notification. In all cases, G8 sends a request message to the PSP, and the PSP is expected to respond appropriately.
The validation data request/response pair is primarily used for magnetic stripe and keyed entry transactions. It is not used at all for contactless transactions, and can be enabled or disabled for contact ICC transactions. If the PSP does not support validation data requests, or the solution is offline-only, or for any other reason, validation data requests can be disabled and G8 will use offline IIN ranges instead. The validation data request includes the initial card details read during the transaction: magnetic stripe track 2 data, a keyed PAN and expiry date or the PAN, expiry date and Track 2 Equivalent Data read from an EMV card. The PSP is expected to look up the card’s account number and respond with card details. For magnetic stripe transactions, the PSP is also expected to parse the track 2 data to determine the PAN and expiry date in the first place, and to evaluate the service code to check whether the card has a chip. For keyed transactions, the PSP must supply information about additional keyed data required: the start date, issue number, CVV length.
The authorisation request/response pair are used for online authorisation of the card. In modern systems, authorisation requests occur for all magnetic stripe and keyed transactions, and for EMV and contactless transactions where required. G8 can operate as an offline-only terminal, and in that case, no authorisation requests are ever sent.
Reversals are sent by G8 if an authorisation request was sent previously, and the transaction was subsequently not approved, except for the case where the transaction was declined online. This might happen due to an EMV card declining or a signature being rejected, but might also happen due to an error such as being unable to print receipts. G8 does not guarantee that it will send reversals, however: if a reversal message could not be sent, G8 will retry as often as it is configured to, but will not re-attempt messages indefinitely. G8 does ensure that settlement messages are sent if an authorisation request had been sent previously.
Settlement messages are sent by G8 when it has completed a transaction, printed receipts and has a final result. Settlement messages will be sent for all transactions where an authorisation request was sent (barring catastrophic hardware failure, of course!). In the event of an offline-authorised transaction, the settlement message may be the first and only message regarding that transaction to be sent.
Configuration
Configuration for G8 EFT is stored in comms.properties. Basic configuration consists of the following properties:
driver = g8eft
g8eft.applicationProtocol = http
g8eft.host = https://psp.example/g8eft-endpoint
This configures G8 to use the G8 EFT protocol over HTTP(S), connecting to a specific endpoint on the server called psp.example.
In addition to this, timeouts for connection and response, SSL/TLS support and encryption schemes can be supported. It is also possible to disable validation data requests and use G8’s build-in IIN range tables instead. These options are all described in the G8 Configuration Guide.
Store and forward
When G8 cannot contact the PSP, or does not receive a positive response, it will store settlement data to be sent again later. When storing this data, G8 encrypts the sensitive cardholder data using one of the RSA public keys configured in encryption.properties. Because G8 only has access to public keys, it is not possible for any entity to decrypt the encrypted data using the data available on a G8 instance. Thus, G8 stores sensitive cardholder data safely in a PCI-compliant manner, while ensuring that transactions can continue to be conducted without any online capability.
Host selection strategies
G8 has an advanced system for choosing the host to which to send messages, and for configuring retries and failover between those hosts. For example, it is possible to configure validation requests to be sent online to host A, with host B as a backup; authorisation requests to be sent to host B unless it does not respond for a specified number of times, when host C will be used instead; and to send settlement messages to host D only.