ISO8583 host-to-host or POS-to-host?

At first glance it may look like a good idea to reuse an existing POS link to integrate a remote host, but protocol differences assure that the resulting service will have a significantly smaller uptime, slower transactions, higher failure rate, higher support costs and a more complex integration.

In further text we will refer to POS-to-host as P2H and host-to-host as H2H.

Typically, when integrating an acquirer offering only a POS service the question will invariably arise "implementing a H2H link is too expensive, what aspects of a P2H protocol are problematic for a H2H integration and what would we need to change" - this document attempts to illustrate some of the difficulties of this approach.

Key management

• P2H: since terminals live in an untrusted environment, each POS has its own keys, so the host needs to maintain a table of 1000s of keys that need to be rotated multiple times a day
• H2H: the hosts exist in a trusted environment with keys stored inside an HSM module, this means that each host can use just one key and typically key rotation isn't necessary on a daily basis
• Conclusion: key management implementation of a P2H link is much more complex to implement and to maintain in production compared to a H2H link

Encryption & authentication of messages

• P2H: POSes connect through untrusted network from an untrusted location hence full message encryption, MACing, SRED, P2PE - all look like a good idea in spite of their financial and operational costs
• H2H: hosts connect through trusted VPNs between PCI-certified institutions, the VPN itself is the guarantee of the authenticity and security of the messages
• Conclusion: on a P2H link securing encryption & authentication of messages can be a daunting task in terms of technology, certification, external audits etc that are often dependent on the POS type - on the other hand on a H2H protocol this is fully guaranteed simply by the virtue of PCI infrastructure, reimplementing similar mechanisms for a H2H link is a waste of financial, time and development resources that result in a more fragile service

Connection protocols / multiplex vs serial

• P2H: fleets of POS networks connect to a host and they don't support executing multiple transactions at the same time, each transaction means a new connection with its own SSL handshake etc which makes transactions slow
• H2H: two hosts establish a single connection and exchange any number of parallel messages
• Conclusion: these are incompatible connection mechanisms, P2H transactions are inherently slower than H2H transactions since they require a TCP/SSL handshake on every transaction and from experience this results in a higher number of random timeout errors

Quality of service / network administration msgs / 0800s

• P2H: POSes simply send transactions when the client taps his card on the POS - they don't have the a priori awareness if the remote host is up and accepting transactions or not - this means there is no good way for the client to detect if the host is ready
• H2H: hosts must exchange so-called network administration/echo messages (0800s) which serve a dual purpose - to prevent the persistent connections to get cut off by intermediate routers - and to serve as a kind of keep-alive API between the hosts
• Conclusion: using a H2H link you can relatively reliably know if the remote host is alive or dead and depending on this automatically send transactions to a working endpoint - P2H integrations simply fail transactions in this case

Technical reversal & other SAF handling: POS locking

• P2H: if a P2H transaction times out, a POS due to lack of support for concurrent operations must lock the device and prevent further transactions until a technical reversal or other SAF request for the previous transaction can happen, this situation can be further exasperated if the remote bank doesn't respond to the technical reversal for app error reasons (and this is quite common) - this locks POS processing until the problem is resolved manually
• H2H: if a H2H transaction times out the host will continue sending technical reversals in the background and the POS continues to process unimpeded
• Conclusion: PCI hosts often have problems processing technical reversals because they're a result of an exception scenario, this results in a number of locked POSes whose internal SAF memory need to be manually wiped - this "feature" that blocks processing is additional development on a host and this is a scenario that doesn't exist on a H2H link

Technical reversal handling - batch data integrity

POSes can break, beverages can be spilled over them or they can be turned off for other reasons (ie the cashier is logged out and a vacuum cleaner was plugged in instead), this means that we can't trust POSes to implement technical reversals and other SAF messages in a robust way - on the other hand it is quite simple to implement a good host-based SAF mechanism which will be robust for different disaster scenarios.

The fact that technical reversals / SAF can't be processed robustly on a POS has a big impact for the way settlement is done on a P2H link, compared to a H2H link.

Settlement

• P2H: the POS must send a close-day request (ie a 0500 message) at least once a day to reconcile POS and host batch totals. If the totals don't match, the POS needs to re-upload the entire batch (using 0320 messages) and submit another close-day request. Until the remote host doesn't approve the batch upload the POS must be locked and prevented from making further transactions - and this happens all the time on a busy system. This process is now an additional burden on the support personnel to manage and keep the POS network running.
• H2H: the POSes are never locked due to the settlement process, since technical reversals can be trusted on a H2H link - no additional steps are necessary if the remote host supports auto-capture, otherwise a settlement file such as VisaMDC/IPM must be implemented
• Conclusion: trying to re-implement P2H settlement business logic for a H2H link is a useless and technologically daunting task that results in lower POS uptimes and higher support costs