Many multi-lane merchants have been putting off making big decisions on their in-store payments estates, waiting in vain for easier options and a better ROI story to emerge. What are the options when decisions cannot be deferred any longer?

Many large physical world merchants struggle to build POS strategies that generate a positive ROI. One of the main reasons behind this is the serious muddle over how to construct front end architectures for POS and the associated middleware .  Ten years ago, terminal architectures relied primarily on building backwards from the hardware, predominately using the hardware vendor’s solutions.  Hardware, terminal applications, customisation, SDK interfaces and TMS were all delivered as a complete supplier package from players like Verifone and Ingenico. However, designing the next generation of middleware is proving much more complex. 

Enterprise merchants have a number of key pain points with their terminal estates:

1. They resent terminal vendors’ walled gardens and self-created replacement lifecycles which impact capex return. 
2. There are a wide perception that vendors invest too little on innovation, improving the customer journey, providing operational flexibility and delivering integrated commerce. 
3. There are often pressures from sales teams to migrate to the suppliers’ latest and increasingly monolithic end to end products and services. 
4. Many terminal vendors are committing to the Android operating system for payment applications and no longer support Linux, the tried and tested framework for high volume, multi-lane PEDs. 

So, what are the options?  Are large merchants expecting too much from their terminal suppliers? How could they reduce their dependency?  

A) A multi-vendor architecture

Picking multiple best in class services has with many attractions.  Several specialist suppliers can offer highly reliable EPOS interfaces, others have developed well-designed payments applications and are prepared to customise.  At least one major terminal supplier is offering multi-vendor terminal agnostic TMS and others are following.  Also, several offer their own components or partnerships with eComm providers to enable the construction of omnichannel solutions. 

B) Inhouse build

Another option for large merchants (albeit with extensive customisation) is to specify and develop their own payments middleware applications and by this means own the IP and enable decoupling from terminal vendor dependency.  This strategy gives the merchant stronger control over its middleware/payments applications and their future development.  However, multi-vendor or own IP middleware solutions have their downsides.  Should they target Android or Linux devices, or both, and what are the development costs and risks?  Also, major terminal hardware vendors may struggle to provide a TMS for merchant-owned and third-party customised software – thus several TMS services may need to be supported. 

C) Hybrid sourcing

A third approach is a mix and match multi-vendor middleware strategy based on a vision to simplify and standardise the PED payments application features.  Several large merchants have implemented highly complex customised non-payment features within the PED which would be better and more efficiently supported within the EPOS application.  Typical lack of delineation and PED embedded examples would be complex processing for loyalty, giftcards and ID.  Limiting payments applications to standard vendor Android based functionality would also enable the use of a standard TMS and the opportunity to support a wider range of terminal types.  However, unscrambling embedded PED functionality and extending EPOS software can be very complex and costly.  It also complicates the migration to new hardware and software and creates risks that the supermarket business may want to avoid. 

If large merchants want to redesign their legacy middleware architecture, they have limited options.  If they continue to work with the major terminal vendors and implement their end-to-end services, they reduce control and are unable to maximise the life of PED hardware assets.  If they develop their own middleware, they may incur high development costs and struggle to work with the major terminal hardware vendors and their TMS. If they standardise and drop all PED payment application customisation, they could face high risk rewrites of their EPOS software.  In conclusion, there are no easy solutions to work around the challenges for multi-lane merchants as they reassess their payments architecture, and kicking the can down the road is not a sustainable option.

PSE works closely with many large merchants across the globe helping them navigate the challenging world of in-store payments architecture. If you would like to talk to us about how we can help you look at these issues, please get in touch.