In today’s frequently changing payments landscape, stakeholders are embracing new technologies to reflect shifting consumer behaviors. One such technology is SoftPOS, a solution which uses Commercial Off-The-Shelf (COTS) devices to accept contactless payments. In fact, 41% of small business owners are investigating the possibility of accepting payments via mobile device.
The process of setting up these solutions for merchants is relatively simple – it is a case of buying a compatible device (or using the one they already have!), downloading an app and enrolling with the back-end system to obtain the valid account credentials. However, for those creating the software, it is not so simple. There is a variety of considerations that developers need to keep in mind when developing these solutions, ranging from the technical to the practical. This blog explores the technical complexities, compliance factors and functional challenges to overcome for those wanting to bring their SoftPOS solutions to market.
Note, we do touch on security here but will go into greater detail in the next and final blog in this series. You can also check out the first two blogs on the ecosystem (chapter 1) and device considerations (chapter 2).
A solid foundation.
SoftPOS solutions allow merchants to accept contactless payments directly on their smartphones or tablets. Today, these solutions can only be implemented on Android devices.
When developing a mobile payment acceptance solution, developers must effectively create two completely different systems that work seamlessly together. There is the back-end system, including the attestation and monitoring server as well as the payment gateway which handles the actual payment transaction. Next, there is the local component (mobile application) which contains the user interface and manages the connection to the backend.
There are multiple software components which must work together to create these systems. Firstly, the payment kernel provides all the necessary processing logic and data that are required to select and process a card application (using NFC technology). This can be included in a software development kit (SDK), which can be provided by a vendor or a payment scheme. There is also the merchant application which uses the card processing kernel/SDK API and the connection to the back-end system and terminal management system. Finally, there are multiple security modules to fulfil the requirements defined by PCI MPoC™, including the connection to the attestation and monitoring server in the back-end system.
For developers new to making payment acceptance apps, creating all of these different components and ensuring that they function effortlessly can create challenges. Difficulties could range from understanding the roles and responsibilities of all of the different actors in the payment ecosystem, to grasping all of the individual components of the transaction flow. Beyond this, there is the issue of anticipating potential problems that could interrupt a transaction. For many, this will be a whole new world of nuanced complexity.
Satisfying multiple requirements.
To ensure that software used to accept SoftPOS payments is secure, functional and interoperable, there are a number of requirements that need to be met. Multiple components of the software for SoftPOS solutions need to be tested:
The functionality of the app.
The compatibility with the mobile device it is running on.
The interoperability and performance.
The terminal user interface.
Primarily, developers must ensure that it is compliant with the payment schemes’ Level 2 requirements. This certification is concerned with the validation of the software that implements the payment functionality and that runs on COTS devices (which can achieve optional EMV®* Level 1 certification) or in the cloud. This software is independent from the hardware and is referred to as a payment kernel for each payment scheme. This is the same certification process that legacy terminal vendors need to achieve, with the requirements that have been adapted to suit SoftPOS solutions.
Additionally, the solution must also achieve compliance with the PCI Mobile Payments on COTS (MPoC™) security and test requirements, which ensure that payment data is protected in both the software application which initiates the transaction, and the independent back-end system. This standard provides merchants with confidence in the security of their solution through a combination of security controls built into the merchant application and ongoing monitoring and integrity checks performed by the back-end systems.
One complicating factor is that each payment scheme has its own specific way of accepting and processing contactless transactions. Developers need to ensure that their apps and embedded kernels are compliant with multiple schemes.
Challenges to overcome.
Getting the testing right to ensure that solutions are best-in-class is fundamental for many reasons. SoftPOS solution providers are not only competing with their peers, they also have to work commonly with the existing platforms and architectures in place for traditional POS providers. Recreating the quick and easy contactless experience that consumers are familiar with is the goal. One particular feature that can be vital to the success of a SoftPOS solution is the speed of transactions. If the payment cannot be made and authorized quickly, the benefits of contactless cannot be realized and ultimately the product will not live up to the merchant’s or the consumer’s expectations.
Another hurdle is that these solutions may not yet support PIN entry, so contactless payment caps can apply in each country or region.
The good news?
Specifications to support PIN entry was released in PCI MPoC™ in 2022. In the meantime, apps in development have to follow the security requirements defined by the schemes. So any apps in development now should have this in their roadmap if not yet implemented.
Finally, SoftPOS solutions without shielding application technologies are potentially vulnerable to attack, and payment processing data can be exposed. SoftPOS solutions cannot benefit from the hardware-backed security foundations that legacy POS devices can.
Therefore, strong security needs to be built in from the first stage of the design process to ensure safe transactions and inspire consumer trust. In the next instalment of this blog series, we will explore the different security options available to solution providers and OEMs wanting to launch their SoftPOS products.
You are not alone though.
With a number of factors to consider, it can be difficult to know where to start when bringing a SoftPOS application to market. Solution providers and app developers cannot be expected to know everything about the market, specifications and evolving requirements, and upskilling can require significant investment in time, headcount and money. You are not alone though. Our experts work daily to stay ahead of the market and have extensive technical expertise in defining, designing, delivering and testing solutions to take the complexity out of compliance.
Learn more about how we can support every stage of the development and deployment of SoftPOS innovations.
Stay tuned for the next instalment in our SoftPOS blog series to learn more about the security consideration and implementation for SoftPOS.
* EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo, LLC.
