In our prior post, we went into the gnarly problem that is dealing with existing customers’ legacy devices. Today, we’ll discuss building your ideal forward-looking strategy for both card present, real world transactions.
How your software will be used and where it will run
The first consideration is whether you will run your software on the payment acceptance device or connect the payment device to a separate device running your software.
- Are your customers technicians in the field, meaning they will need a portable device?
- Do you plan to issue devices (or iPhone/Android devices) to each employee of your customer’s that will be taking a payment?
- Do they ring customers up behind a counter in a traditional point-of-sale environment?
- Is there a need for the consumer to interact with the software during the transaction (e.g. a loyalty program or an upsell opportunity)?
The industry refers to a payment device tethered via USB or Bluetooth to a host device that runs your software as semi-integrated. Eliminating one of the two computing devices used by the customer by simply running your software on the payment device itself – we call “Platform-as-a-Service.”
Compliance and pricing
Another important consideration is security, specifically compliance with PCI (an industry standard). Historically, running your software on a payment device required a Level One certification. This works, but it typically takes between 9 and 12 months, which is time consuming. Not to mention it can be quite technical. In more recent times, this problem has been solved by PSPs through shipping physical devices with an embedded software SDK that handles all communication with the secure board that is reading a tap, swipe or dip.
The final top-level consideration should be price. How price sensitive do you expect your customers will be to purchasing or leasing a payment acceptance device? This is often derivative of processing volume. For instance, if you were to process $1M per year through a single device, its price becomes less important than speed, convenience, or capabilities. However, if you are only going to accept $25,000 in a year, paying $5,000 for a POS lane at a grocery store makes no sense.
All of these questions will be highly specific to your industry and customer behavior. Before we started Forward, we did this hundreds of times across varied industry sectors. If you want to talk through what the answers to these questions might be, reach out to discuss your specific market and we can help navigate the hardware platform decision together.
In the meantime, we are big fans of the following two platforms for two different use cases.
Semi-integrated
This platform involves tethering a payment acceptance device to the device that is running your software. We love the Clover platform for these situations for a few reasons. Fiserv-owned Clover has invested 100s of millions in their platform, enabling them to offer multiple form factors for different types of use cases. For the traditional point-of-sale on a counter, they have the Station. For mobile operators, they have the Flex For low cost they offer the Clover Go. For dynamic customer interaction during the transaction, they offer the Clover Mini. Each of these devices requires a single integration to a software layer that abstracts PCI compliance for both your customer and your team.
Platform-as-a-Service
Platform-as-a-service involves running your software application on the payment acceptance device. In this category we love ELO’s latest family of devices that includes register, terminal, mobile and kiosk form factors that each allow your software to be run on the device. To make managing a fleet of deployed devices, ELO has invested in a terminal management system (TMS) and remote key injection (RKI) to make supporting your customers a breeze. Included in the entire family of devices is a PCI-abstracting payment application de-scoping certification from your integration.
As you can see, card present transactions are an integral part of scaling your payments business. At the same time, they are highly complex and littered with sunk cost challenges – you will want to measure twice, cut once – and get this decision right from the start because switching gears mid-stream can be expensive and time consuming.
