SoftPOS solution: concept and implementation tips for businesses

SoftPOS solutions are becoming increasingly popular among both buyers and sellers (particularly, those from SME segment). In our articles we wrote a lot about contactless payments , mobile and in-app processing techniques. However, we never specifically described the SoftPOS technology and phases of its implementation. In this guide we will try to address these issues. It will be helpful to the following categories of readers.

1) Individual merchants and SMEs that want to implement SoftPOS solutions instead of (or in addition to) payment terminals.
2) Managers or product owners of large SaaS platforms that need to add SoftPOS functionality to their omnichannel offerings.

First, we will briefly outline the historical background and the concept of software POS or point of sale systems. Then we will move on to specific conceptual approaches to and phases of SoftPOS solution implementation.

Readers, already familiar with the concept of SoftPOS and the history of its emergence, can skip the respective introductory sections. They can jump right to the section titled “White-label versus on-premises SoftPOS solutions”. It is starting from this section that we go deeper into technical details.

Initially, the major option for people who wanted to accept credit card payments, was to use payment terminals. Several decades ago, most cards were swiped cards. Then, invention of silicon integrated circuit gradually led to emergence of contact EMV payments. In fact, integrated circuit-based technologies provided the basis for introduction and usage of EMV compliant POS terminals worldwide. A bit later, significant advances in implementation of NFC technologies provided opportunities for contactless payments. Finally, as smartphones and tablets became more affordable and widely used, various card readers also became popular.

Nowadays, NFC contactless payments are as relevant as ever. Post-pandemic reality calls for growing contactless payment penetration and increase of contactless payment limits on consumer cards. More consumers prefer to pay for products and services using their smartphones or wearables. So, more businesses want to be able to smoothly accept such payments.

At the same time, payment terminal fulfillment and management is often a challenge for merchants and software platforms. The merchant has to deal with such issues as logistics and the cost of initial provisioning and maintenance of the terminal. These issues make it more difficult for micro-merchants and some SMEs to accept cards. Plus, these issues slow down the penetration of credit card payments. Consequently, the concept of SoftPOS becomes more and more popular, especially in developing countries.

From the merchant’s perspective, the concept is as follows.

Let us assume, you are a small-size merchant that needs to accept card payments at a low cost. You can achieve this goal by turning your phone or tablet into a POS system without purchasing any additional hardware.

For this purpose, your smartphone (or other device, such as a tablet or a wearable) should be equipped with an NFC circuit. The circuit makes it possible for the device to read payment data from other devices or NFC contactless payment cards.

Now, SoftPOS, is, essentially, a software application that you download and install on an NFC-enabled device. The app uses the NFC circuit of the phone to accept contactless payments. Thus, it turns the phone into a contactless payment terminal.

No wonder, such handheld point of sale system solutions are becoming more and more popular.

Hardware-free

The main advantage of SoftPOS technology is that it requires no additional hardware or dongles. Thus, you can accept contactless payments using a smartphone or a tablet. There is no need to implement special POS terminals at all. So, the terminal-free solution works perfectly if you need high mobility.

However, it absolutely doesn’t mean that SoftPOS and terminal solutions are mutually exclusive. In fact, Android-powered terminals and SoftPOS solutions can complement each other within a unified omni-channel offering. We will provide a more detailed explanation in one of the next sections.

Amount limitations

Just like other types of NFC contactless payments, SoftPOS transactions are subject to contactless transaction limits. These limits might concern transaction amounts, payment frequency, or any potential deviations from regular customer or merchant behavior.

So, in some cases, in order to make or accept payments, you need to be able to input PIN. PIN entry is, basically, an additional security measure. Initially, SoftPOS systems did not allow PIN entry. However, presently, the new PIN on Glass technology is becoming available. This technology allows you to input PIN onto glass surface of the smartphone screen. So, the solution makes it possible for merchants to process higher-amount and more frequent payments (requiring the input of PIN) through SoftPOS.

Still, it is important to realize that some higher-amount contactless transactions might not come through due to security reasons.

Now we move on to technical side of SoftPOS solution implementation.

In terms of implementation, a SoftPOS solution is similar to a payment gateway. Essentially, SoftPOS is a special app or software product. So, you can either build such innovative point of sale systems from scratch, or use white label offerings.

A white label SoftPOS solution takes less time to implement, it involves less responsibilities and requirements, and provides less control. Although upfront costs are low, recurring costs (such as transaction and monthly subscription fees) might be higher than in the case of an in-house solution.

Your own custom solution provides more control and does not involve software fees and transaction costs (outside of interchange). However, it requires huge upfront costs, takes more time to implement, and is associated with higher liability level.

In either case (white label or custom solution) it is important to analyze all the critical aspects in advance. Otherwise, you might face unpleasant surprises in the future, as you use the solution. Plus, you need to plan your budget and estimated and expected point of sale system costs.

If you are building a custom solution in-house, you should clearly understand all the phases, components, and aspects of the process. Moreover, if you choose to use a white label SoftPOS solution, you should understand them as well. Reason: even if the solution is built by a third party, there should be no blind spots for you in the development process. Otherwise, you might experience unexpected technical issues further down the road.

Now let us outline the key aspects and components of the implementation process.

Acquiring partnership

Acquiring partnership first!

Just like in the case of a payment gateway solution, the first important aspect is your acquiring partnership. At this phase you select an acquirer and its respective processor. You should clearly define the acquiring bank that will issue merchant accounts and perform initial merchant background verification. The acquirer needs to support card-present processing and EMV certification of third-party devices/terminal solutions.

Are you interacting with the acquirer through a third-party or white label service provider? Well, then you should verify whether the acquirer can underwrite merchants that want to accept payments through SoftPOS.

Selection of a suitable acquiring/processing partner takes 1 to 3 months.

PIN Encryption Strategy Definition

In order to be able to use PIN on a device, this device should be injected with a special encryption key. The key ensures protection of the PIN (through encryption) when it is transmitted to the processor during transaction submission.

One of the key aspects of a SoftPOS solution is the key injection mechanism. So, it is critical to determine, how to organize the injection process. It will largely depend on the algorithms, which supports the libraries installed on the device and is, at the same time, supported by the provider. It means that you should analyze these issues once you choose the acquiring/processing partner.

Thus, PIN encryption strategy defines how PINs are encrypted and how encryption keys are injected. One of subsequent sections covers key injection mechanisms.

At this phase you need to determine

1) which encryption schemes for PIN block handling the processor supports;
2) how the processor delivers the keys: BDK (base derivation key) and ZPK (zone PIN key).

In order to clarify these issues, you need to initiate conversations with the technical team of the processor.

Definition of your PIN encryption strategy takes up to 3 weeks.

EMV Toolkit Selection

In order for a device (such as a payment terminal or phone) to be able to process card-present transactions using EMV protocol, the EMV kernel of this device should be certified by the processor. In order to perform EMV certification, you need an EMV toolkit. Some processors would allow using any toolkit of your choice. Others require their clients to use some particular toolkit (which may cost you a lot).

So, at this phase you need to discuss an EMV certification process and clarify EMV toolkit requirements. If necessary, you should also obtain a toolkit license quote. Particular toolkit selection will depend on your choice of acquirer or processor and specifications it provides.

The toolkit selection phase, usually, takes up to 2 weeks.

Processor Specification Review

The purpose of this phase is to obtain processor specification and make sure that all the functionality you need is supported. Processor specification is also the starting point for code development.

So, at this phase developers need to review integration specifications they obtain from the acquirer/processor. This phase is the right time for cost estimation. You should clarify any relevant questions with the client and the processor (also with client’s assistance).

Specification review takes up to 2 weeks.

Processor Integration

Now, that you have reviewed and clarified the specifications, you can start the integration process. At this point your team performs most of development work to integrate the gateway with the processor as well as implement any card brand specific requirements into the SoftPOS application.

Keep in mind, that you can proceed with this phase only after other major phases, such as key injection and kernel development are completed.

The integration phase, usually, takes 6 to 8 weeks.

EMV Certification

This is the final phase of establishing an acquirer/processor partnership. At this phase you need to certify EMV logic with the processor using an EMV toolkit. You should complete certification process step by step, according to the test cases provided by the processor.

You are required to send EMV certification results to card brands (Visa/MC) to receive final approval.

Certification process takes 6 to 8 weeks to complete.

EMV Kernel

Kernel Strategy Definition

Kernel is the software that interacts with peripheral devices of the terminal/phone. That is why if you are using a payment terminal, it is, usually, the terminal manufacturer that develops and certifies the kernel. In case of SoftPOS usage, the process is significantly simplified as NFC access is standardized at Android OS level. So, the kernel (i.e., the software to interact with NFC circuit) can be developed by a third party.

Conceptual EMV kernel strategies are as follows. You can use a licensed third-party EMV kernel or build your own kernel in-house and certify it. Besides that, a kernel can be either embedded or cloud based. Particular strategy primarily depends on the desired timeframe, as well as short term development costs and long-term licensing/transactional costs.

If you develop the EMV kernel in-house, then you also have to go through level 2 certification of this kernel. Licensing a kernel (instead of building it) involves lower upfront costs and is less labor-intensive (no development and certification effort). On the other hand, if you license one, you will likely have to pay maintenance and support annually or even per-device.

EMV kernel strategy definition might take 2 to 3 weeks.

Kernel Licensing

If you decide to license the EMV kernel, you have to find an appropriate vendor. Besides that, you need tocheck whether the kernel supports all the required functionality and is level 2 certified with all of the cardbrands that you want to support. Then, you have to negotiate the kernel usage price and terms with the licensor.

Licensing procedure takes up to 3 weeks.

Kernel Development

If you choose to develop your own kernel, then you need to carry out all corresponding works. Keep in mind, that you have to implement the logic for all desired brands.

Development of your own EMV kernel from scratch in-house, roughly, takes 3 to 4 months, assuming your team has appropriate experience. If your team starts from scratch, the process might take up to a year.

Kernel Level 2 Certification

Again, if you choose the in-house development option, then you need to certify the newly developed kernel with the relevant card brands. That is, you need to obtain level 2 SOWs in order to be able to proceed with level 3 processor certifications.

Kernel certification takes 6 to 8 weeks and requires the EMV toolkit discussed in the respective section.

Attestation

Attestation Service Strategy Definition

Attestation logic is another mechanism, allowing to ensure the security of the device used to accept payments. Malware installed on the device might allow the owner (or fraudsters) to steal cardholder data. That is, fraudsters might steal PINs or card numbers when the SoftPOS app processes these data.

To prevent these scenarios, the phone has to go through a regular series of checks, called attestation. Attestation certifies, whether it is safe to use the device for transaction processing and cardholder data transfers. Attestation logic is installed on the phone itself. Attestation results are sent to a special attestation server or service. Potentially, the service provider might be the same company as the payment gateway provider. However, sometimes gateway and attestation logic originate from two different companies. In this case the attestation service operates on a separate server of the respective vendor.

The gateway has to ensure that attestation checks are performed at least once every 30 minutes. So, every time a transaction comes through, the service needs to verify that the latest positive attestation result is no older than 30 minutes. If no such result is available, then there is no guarantee that it is safe to process transactions through the phone, so it is blocked.

The choice of the strategy for attestation service is similar to kernel strategies. That is, you can either license an attestation service or build one in-house and go through respective audit procedures. The strategy primarily depends on the desired timeframe and longer-term costs.

Attestation strategy definition takes 2 to 3 weeks.

Attestation Service Licensing

If you choose licensed attestation service, then you need to find an appropriate vendor. Then you should check whether the service is level 2 certified and supports all the required functions. Finally, you should negotiate the price and terms of the service provision with your chosen vendor. Often EMV kernel vendors provide both the kernel and the attestation service as a unified package.

Licensing process takes 2 to 3 weeks.

Attestation Logic Development (Application and Server)

Attestation logic has two key components.

One component is an app installed on the SoftPOS “terminal”. Among other things, it verifies, that

• the SoftPOS terminal is not rooted,
• the SoftPOS app was downloaded from an official app market,
• debug mode is not on,
• no traffic-sniffing apps are installed on the phone etc.

Another component is installed on the server. It performs the function of attestation data repository. That is, it registers and accumulates the results of regular attestations. This repository allows third parties, such as gateways, to verify the availability of “fresh” attestation results for a particular device.

If you choose development option, then you build an attestation app, as well as attestation results repository on the server end.

On the SoftPOS “terminal” (i.e., phone) end you need to develop logic, necessary to assess and attest a phone running a SoftPOS, following CpOC recommendations. The result of the attestation has to be subsequently transmitted to an attestation server.

On the server’s end, you need to build the logic necessary to receive and store attestation information from a phone. Again, your gateway and attestation service provider might be the same entity. In this case, if you develop your own TMS solution, then you don’t have to build an attestation service as a standalone application. Most probably, you will be able to incorporate it into the gateway’s existing processing logic.

Attestation logic development takes approximately 8 weeks.

Encryption key injection

Injection Strategy Definition

As we said, in order for the customers to input PINs through smartphones or other devices, these devices should be injected with encryption keys. Encryption methods can be rather complex and call for usage of special hardware security modules (HSM). Here are some common questions regarding key injection you should be able to answer.

• Who is going to inject the keys (and how)?
• Does this entity support your target encryption and injection methods?
• Does it have (or can it obtain) the encryption keys from your target acquirer/processor?

In case of a SoftPOS solution implementation, key injection mechanisms involving physical hardware are inapplicable. So, remote injection is the only option. A remote key injection service can be either licensed or built on-premises and audited.

If you develop a custom solution, then you can implement the most suitable key injection mechanism in-house as part of the development process. In this case, keep in mind, that an in-house solution has to go through special audit procedures. The other option is to license the service of some white label key injection solution provider. In this case you need to verify that

• it will support all your target algorithms and key lengths, and
• be able to inject the keys, issued by your target acquirer/processor.

Particular strategy primarily depends on the desired timeframe and per unit injection cost.

Key injection strategy development, usually, takes up to 3 weeks.

Remote Injection Service Licensing

If you select licensing (white label) option, then you need to find an appropriate vendor. This vendor has to support encryption algorithms that would accommodate:

1) processor requirements (ZPK algorithm) and
2) EMV kernel requirements (IPEK derivation algorithm and delivery format, as well as KEK algorithm).

Once you find the licensor, you have to negotiate the price and conditions of injection service usage with it.

Licensing process takes up to 3 weeks.

HSM Selection

If you choose to develop injection logic in-house, then you need to select an appropriate HSM solution.

Both hosted and on-premises solutions are acceptable, however, you need to verify support for

1) ZPK algorithm,
2) IPEK derivation algorithm and delivery format,
3) KEK algorithm

according to the requirements of the processor and the kernel.

The strategy primarily depends on the desired timeframe and HSM hosting or licensing costs. In both on-premises and licensed solution cases, you might need to integrate HSM is into the gateway for processing (PIN translation) and into the TMS for the initial injection. Additional works may be required at the device (SoftPOS) side, if you need to accommodate some new IPEK delivery format.

HSM selection and integration might take up to 6 weeks (depending on the selected strategy and the scope of works).

Deployment and audit

Gateway Selection

In order to implement a SoftPOS solution, you have to partner with a payment gateway. This gateway should be PCI certified and integrated with your chosen acquirer/processor.

Besides processor connectivity, you need to verify the gateway’s ability to support HSM and attestation service integration. Additionally, you have to consider transaction fees and terminal surcharges (if applicable).

Gateway selection phase, usually, takes up to 3 weeks.

TMS Selection

A SoftPOS system performs almost the same functions as a payment terminal. So, you need to select a TMS for terminal, parameters and EMV configuration management. You also need to confirm its ability to support HSM for remote injection or to integrate with a RKL system. And don’t forget to take terminal provisioning fees into account in your budgets and cost estimates.

TMS selection phase, usually, takes 2 to 3 weeks.

SoftPOS Security Auditor Selection

At this phase you select an auditor to conduct the eventual evaluation of the SoftPOS solution. If you are using a licensed kernel or attestation service, then your licensors had to go through mandatory audit. So, in this case it might be easier to use the same auditor they used to review their respective products.

Auditor selection phase, usually, takes up to 4 weeks.

SoftPOS Development

Development phase is the most-labor intensive, but a relatively straightforward process, as most SoftPOS solutions are basic Android applications. Although, in January 2022 Apple was reported to be working on its own SoftPOS solution. According to the news, it will allow Apple customers to accept payments through their iPhones.

At this phase, you need to develop the core logic for SoftPOS system. This logic includes kernel integration, gateway integration, TMS integration, attestation service integration, injection logic and payment logic implementation. The process also includes development of all necessary UI screens. You might also develop an integration API for embedded and external POS systems.

If you are using a licensed open-source gateway product, then you will need to add the logic necessary for SoftPOS operation to the gateway and the TMS. At the very minimum this logic involves device provisioning with IPEK injection and PIN translation/PAN decryption at the processing time. You also need to incorporate attestation service and support for digital signatures into all processing flows used by the SoftPOS.

Development phase, roughly, takes up to 6 months.

SMS Gateway Integration

In order to perform device provisioning and remote key injection, you need to implement two-factor authorization mechanism. That is, beside username and password, the customer will need some other factor, such as SMS or e-mail confirmation. So, you might need to integrate with some messaging/SMS gateway or e-mail service to enable sending of this second factor.

SMS gateway integration sub-phase takes up to 6 weeks.

Deployment Procedure Definition

Deployment procedure concerns two key aspects: hardware (SoftPOS devices or terminals) and software (SoftPOS app).

If you are going to deploy SoftPOS “terminals”, you need to develop some fulfillment strategy. That is, you need to define, how the payment-accepting devices will get to SoftPOS solution users. Devices are usually purchased and shipped to your office or fulfillment center wholesale. From this point they are shipped to end users (all at once, or group-by-group). So, the strategy involves taking care of these issues.

Deployment of the SoftPOS app also requires a clear strategy. That is, you have to define, how the SoftPOS app gets to app marketplaces, how it is certified, and how users can purchase it. Similarly, you need to take care of timely updates of the server and the SoftPOS app.

So, at this phase you also define procedures for ZPK, BDK, and RSA keys provisioning as well as for the app deployment to the AppStore and implement appropriate scripts.

The deployment procedure takes up to 4 weeks.

Audit Materials Preparation and Audit

First, you need to prepare the documentation required for audit process, including relevant diagrams. The documentation needs to cover definitions of security assets, keys, encryption mechanism, fraud protection and obfuscation procedures, attestation process, etc.

Then, the auditing company performs the formal audit of your SoftPOS application. It reviews all documentation and source code. If necessary, you have to perform required remediation works.

After the audit, you need to send its results to card brands (Visa/MC) for final approval.

Both documentation preparation and the audit phase itself take up to 6 weeks each.

As of now, software POS solutions work only on Android-based phones and tablets supporting NFC. So, if you want to accept payments using SoftPOS technology, you have to use only the equipment supporting Android OS.

The good news is that recently many Android-based terminals have appeared on the market. The software developed to operate within Android-based terminals, such as Sunmi, can be adopted to operate as a SoftPOS app. In the latter case, the smartphone becomes a payment terminal.

Although EMV Kernel for SoftPOS and terminals might be different, all other basic aspects would be the same. So, it might be convenient to support both SoftPOS solution and Android-powered terminals, especially if you are already working with them. It might be also handy to work/partner with systems that support both Android terminals and SoftPOS, especially in situations that require contact card-present transactions.

If a SoftPOS solution is suitable, you can use it in addition to terminals, but only one integration will be required for both solutions. This is especially convenient, when platform (such as MPOS) is itself an Android-based app, capable of supporting both solutions.

Conclusion

We have outlined the key phases of SoftPOS solution development. The process is somewhat similar to payment gateway implementation.

If you want to implement a SoftPOS solution for your merchants, contact us for more information regarding our SoftPOS offering and watch our short video guide! We have our own licensable SoftPOS product. Besides that, our omnichannel payment technology UniPay Gateway supports various other payment terminal solutions. So, our experts should be able to help you with your particular SoftPOS implementation use case.