SoftPOS and the Reinvention of Merchant Payments

How software is replacing terminals and redefining how merchants get paid

The Merchant Reality

Walk into a modern retail shop and look behind the counter.

You may find:

• a card terminal for Visa and Mastercard (sometimes from multiple banks)
• a QR sticker for wallet payments
• mobile money till number sticker (Kenyans know this too well)
• Sometimes cash still accepted as fallback

What does this mean for the merchant? Unfortunately, they end up managing multiple acceptance channels, inconsistent settlement timelines, and fragmented reconciliation processes. Payments did not evolve through intentional design; they accumulated over time. Every new innovation added another rail without removing the previous one. Merchants became payment operators rather than business owners.

The Merchant Problem

So today I want us to focus on the card terminals, the PDQs or POS used by merchants to acquire or accept payments from users using a debit or credit card.

In our previous paper we followed what happens after that tap. The cryptograms generated inside the card. The BIN lookup that routes the transaction through the card scheme. The issuer that validates balances and returns an authorization in milliseconds.

What we did not question was the object sitting on the counter.

The terminal itself.

For merchants and banks, that device quietly introduces three structural constraints.

The first is the hardware burden.

Banks must purchase terminals from manufacturers, store them in warehouses, configure them, ship them to merchants, and maintain them throughout their lifecycle. Screens crack. Batteries fail. Charging ports wear out. When the device stops working, the merchant’s ability to accept payments stops with it.

A bank managing ten thousand terminals may easily carry millions in cost for hardware before a single transaction is processed.

The global POS terminal market is estimated to exceed 200 million deployed devices worldwide.” — Nilson Report

That is an enormous amount of infrastructure dedicated to a single purpose: reading a card.

The second constraint is connectivity.

Most terminals depend on bank managed SIM cards and dedicated data plans. The bank becomes responsible for network uptime, data costs, and device monitoring. This “closed-loop” dependency makes the bank responsible for the merchant’s uptime.

The third constraint is economic.

Even when everything works perfectly, every card transaction travels through a layered ecosystem of acquirers, schemes, and issuers. Fees accumulate at every step and settlement cycles can still take days before funds reach the merchant.

For small businesses, waiting two or three days for revenue to settle is not merely an inconvenience.

It is a liquidity problem. We will look into this more in our part 2 on how A2A transactions can close this gap

Globally, card merchants wait between one and three days on average before funds settle into their accounts.”— World Bank Payments Report

The irony is difficult to ignore.

In an era where software simplified nearly every operational process, accepting a card payment at the physical checkout still depends on a specialized piece of hardware.

SoftPOS begins by questioning that assumption.

Why the Old Model Exists

Before we rush to declare payment terminals obsolete, it is worth acknowledging an uncomfortable truth: the system merchants struggle with today was not poorly designed. It was brilliantly designed for a different era. To understand why banks built fleets of payment terminals, we need to go back to a time when trust could not live inside software. Early electronic payments required trusted hardware. Networks were unreliable, consumer devices were insecure, and fraud controls were still evolving. A transaction could not depend on an ordinary computer; it needed a controlled environment, something banks could certify, lock down, and physically trust.

Traditional POS Infrastructure Architecture

That environment became the payment terminal. Every PDQ device was essentially a miniature security vault placed on a merchant counter. Inside it lived dedicated hardware engineered for one job only: protecting payment credentials. Secure PIN entry modules ensured cardholders entered sensitive information on trusted surfaces. Cryptographic keys were injected under strict supervision. Tamper detection mechanisms could permanently disable the device if someone attempted to open it. Security was achieved not through intelligence, but through restriction. If the device was trusted, the transaction was trusted.

Standardized hardware created consistency. Banks scaled acceptance by shipping terminals, and expansion meant ordering more devices. For decades, this model worked exceptionally well, a beautiful, chaotic masterpiece of 20th-century engineering. But while payment infrastructure remained anchored to specialized hardware, consumer technology accelerated quietly in parallel. The smartphone, originally built for communication, began accumulating capabilities that payment terminals never anticipated competing with: biometric authentication, embedded secure execution environments (TEE) isolated from the operating system, and constant high-speed connectivity.

And yet, payment acceptance did not change. Banks continue buying hardware. Merchants continue managing devices. The old model has persisted not because it remained optimal, but because entire ecosystems have grown around it. Terminal manufacturers depended on hardware sales, acquirers structured revenue around device deployment, and certification frameworks were written for machines, not software.

The terminal is no longer just a security solution. It has become an institution. The industry has persisted as if trust still requires a physical box.

The Technology Shift

The transition from dedicated hardware to software-defined acceptance is not merely an upgrade; it is a fundamental re-engineering of the trust model. For years, the banking industry has operated under the assumption that a commercial smartphone was too “open” and insecure to handle sensitive cryptographic keys or PIN entries. However, the convergence of mobile hardware security and new global standards has effectively turned the smartphone into a certified security vault.

SoftPOS Payment Flow

Modern mobile chipsets now feature Trusted Execution Environments (TEE) and Hardware Security Modules (HSM) that are physically and logically isolated from the phone’s primary operating system. This technological leap ensures that even if a device is compromised at the Android or iOS level, the payment kernel remains isolated and protected inside the secure execution environment. Security is no longer dependent on a tamper-switch on a plastic box; it is anchored in the silicon of the device itself.

How It Works: The “Card-to-Phone” Experience

At the heart of this shift is the concept of Hardware Liberation. Solution A retains the familiar “Tap to Pay” behavior that customers expect, but it redistributes the trust model. The heavy processing and authorization logic move from a $400 plastic box to the merchant’s mobile device. This is made possible by the PCI MPoC (Mobile Payments on COTS) standard, which creates a secure, software-defined environment for payment capture.

This “Card-to-Phone” experience manifests in the merchant’s daily operation through two distinct architectural options:

Option 1: The “PIN-on-Glass” Experience

This is the most direct replacement for the traditional PDQ terminal. It allows the merchant to accept high-value transactions that require a PIN without needing a physical keypad.

• Initiation: The merchant enters the transaction amount directly into their SoftPOS-enabled business app.
• The Tap: The customer taps their physical credit or debit card against the back of the merchant’s smartphone. The phone’s built-in NFC controller reads the EMV data exactly as a traditional terminal would.
• Authentication: Instead of a physical rubber keypad, a dynamic, scrambled keypad appears on the merchant’s screen.
• Authorization: The customer enters their PIN directly on the merchant’s glass screen. The app encrypts this PIN data immediately within the phone’s secure enclave (TEE) before it ever touches the app’s main memory or the internet, sending it to the acquirer with the same level of security as a legacy terminal.

PIN-on-Glass isn’t just a digital keypad; it’s a security dance. By scrambling the numbers for every transaction, we ensure that a ‘smudge attack’ or a hidden camera can never guess a customer’s code.

Option 2: The “Push-to-App” Experience (Sovereign Auth)

This represents a radical shift in the power dynamic of a payment. It removes the need for the customer to ever touch the merchant’s device to enter sensitive data. Instead, it utilizes the trusted relationship between the customer and their own bank.

• The Handshake: The customer taps their card (or phone) on the merchant’s device. The SoftPOS SDK captures the card’s identity and the transaction amount.
• The Redirect: The scheme identifies the Issuing Bank via the BIN and forwards a specialized “Authentication Request.”
• The Bank Prompt: The Issuing Bank receives the request and — rather than waiting for a PIN from the merchant’s side — immediately initiates a Push Notification to the customer’s own banking app.
• Sovereign Auth: The customer receives a prompt on their own smartphone: “Confirm payment of KES 1,500 to Merchant X?” They authorize the transaction using their own biometrics, it could be FaceID, a fingerprint, or their private mobile banking PIN, directly within their bank’s secure environment.
• The Confirmation: Once the customer approves, the Issuing Bank sends the authorization code back through the network, and the merchant’s app receives a real-time “Success” signal.

Option 2 effectively ‘de-risks’ the merchant’s counter. The bank talks directly to its customer, and the merchant simply receives the ‘Yes’.

Risks and Controls

The liberation of hardware introduces new digital risks that require sophisticated, real-time software-based controls. The primary concern is no longer a physical “tamper-switch,” but rather sophisticated malware or “zero-day” exploits targeting the mobile OS. To counter this, SoftPOS implementations utilize Dynamic Software Attestation.

Every time the app is opened or a payment is initiated, the software performs a real-time “health check” to ensure the device hasn’t been compromised (rooted). If the device’s security posture changes — such as a developer mode being enabled or a suspicious background process starting, the payment functionality is instantly revoked. Furthermore, advanced cryptography ensures that PIN obfuscation prevents pattern-based theft on the screen. Because these devices are mobile, Geofencing controls can also be applied, allowing banks to restrict payment acceptance to specific GPS coordinates to prevent fraud in unauthorized or high-risk regions.

SoftPOS Security Architecture

Strategic Impact and What Leaders Should Do Next

For financial institutions, the shift to software-defined payments represents a massive reallocation of capital. By eliminating the need for physical units, banks can move from a CAPEX-heavy model to an OPEX-efficient strategy. The transition removes millions in hardware liability and replaces it with a scalable software distribution model.

This “Zero-Touch” onboarding means a merchant can download an app and start accepting global payments in minutes, rather than waiting weeks for a technician to deliver a physical box.

For the first time, the cost of onboarding a new merchant can be dropped to nearly zero. This is only possible if we move from shipping plastic to downloading opportunity.

For bank executives and fintech founders, the message is clear: the era of competing on hardware is over. Strategic focus must shift toward SDK Integration and Value-Added Services. Leaders should evaluate their current merchant portfolios to identify segments, such as delivery fleets, micro-merchants, and other retailers, where the physical PDQ is an unnecessary anchor. The goal is to embed payment acceptance directly into the merchant’s business workflow. If the payment is just a feature inside an inventory, invoicing, or CRM app, the merchant stays for the utility, not just the “tap.”

Terminal Distribution vs SoftPOS Distribution

This final shift from physical logistics to digital logic is more than an operational upgrade, it is the spark for a broader explosion in commerce. By turning the smartphone into a certified terminal, we have unlocked a world of endless possibilities, with zero-fee micropayments, instant programmable tax routing, and credit scoring based on today’s live sales rather than last month’s statements. We are no longer limited by how many boxes of PDQs we can ship, but by how fast we can innovate.

But hardware is only the first chain to break. Even with a modern smartphone, the merchant is still often trapped in a 72-hour wait for their own money. In Part 2, we will explore how layering Account-to-Account (A2A) rails onto this liberated hardware finally removes the “Network Toll” and the “T+3” wait, turning a three-day promise into instant cash.