Why Payment Infrastructure for POS Systems Is Still Broken

Walk into any coffee shop, retail store, or restaurant and you'll find a point-of-sale terminal. The transaction looks simple: card goes in, receipt comes out. But behind that four-second interaction sits a layer of infrastructure that is, by almost any engineering measure, still fundamentally broken.

I've spent years building and integrating payment systems into POS platforms. The problems I keep running into aren't bugs — they're structural. They stem from decades of accumulated decisions, competing standards, and economic incentives that have never quite aligned. This article is an attempt to document what those structural problems are and why they persist.

The illusion of standardization

The payment industry has produced a remarkable number of standards. EMV for chip cards. ISO 8583 for transaction messaging. PCI DSS for security compliance. TLS for encryption in transit. Tokenization frameworks from every major network. On paper, this looks like a mature, interoperable ecosystem.

In practice, every processor implements these standards differently.

ISO 8583, for example, defines a message format for financial transactions — field positions, data types, response codes. What it does not define is which optional fields a processor will require, how they'll interpret ambiguous values, or what they'll do when a field is populated incorrectly. Each processor extends the standard with proprietary requirements, and those extensions are documented (if at all) in PDFs that are updated irregularly and accessed through partner portals behind NDAs.

The result: integrating with processor A teaches you almost nothing about integrating with processor B. Every integration is effectively bespoke.

What a POS system actually has to do

To understand why this is a serious problem, it helps to trace the full surface area of a POS payment integration.

At the hardware layer, a POS system needs to communicate with payment terminals — physical devices that read cards, handle PIN entry, and manage the cryptographic operations required by EMV. These terminals speak proprietary protocols. Most use some variant of a semi-integrated or cloud-based architecture where the terminal handles card data directly and passes tokens or encrypted payloads to the POS. But the specifics — how connections are established, how transaction state is managed, how timeouts are handled — vary by terminal manufacturer.

At the network layer, the POS needs to route transactions to a payment processor. This means implementing the processor's API: authentication, request formatting, response parsing, retry logic, idempotency handling, and webhook verification. It also means managing credentials — API keys, certificates, device tokens — in a way that is both secure and operationally maintainable.

At the business logic layer, the POS needs to handle partial authorizations, split tenders, voids, refunds, and tip adjustments. Each of these operations has edge cases. What happens when a void request times out? Is the transaction voided or not? How do you safely retry without double-voiding? What's the correct behavior when a customer inserts a card and then removes it mid-transaction?

None of these questions have universal answers. Each processor has its own behavior, and that behavior is rarely documented for the failure cases — only the happy path.

The certification trap

Before a POS system can accept payments in a production environment, it must be certified by each payment processor it integrates with. Certification involves submitting the integration for review, running a test suite provided by the processor, and waiting — sometimes weeks, sometimes months — for approval.

This process serves a legitimate purpose. Payment processors need confidence that integrations handle failure modes correctly, that sensitive data is not being logged or mishandled, and that the cryptographic requirements of EMV are satisfied. The problem is the operational reality of how certification works.

Certifications are typically per-processor and per-terminal model. If you integrate with three processors and support two terminal types, you may be looking at six separate certification processes. Each one requires coordinating with a processor's partner team, scheduling test sessions, and submitting documentation. If a processor updates their API or changes their requirements — which happens — you may need to re-certify.

For a startup or a small ISV, this is a significant barrier. Months of engineering time can disappear into certification queues. And because certifications are point-in-time assessments, they don't guarantee that a processor's behavior in production will match what was tested.

Connectivity is not a solved problem

Cloud-based payment processing created the assumption that connectivity is always available. For POS systems in retail environments, that assumption is frequently wrong.

Network outages happen. Routers fail. ISPs have maintenance windows. A restaurant on a Saturday night does not stop processing transactions because the internet is down — or at least, it shouldn't. But most payment integrations are built against a model where the processor's API is always reachable, and the handling of offline scenarios is an afterthought.

The technical requirements for offline payment acceptance are substantial. The POS needs to make an authorization decision without access to the processor's fraud systems. It needs to queue transactions locally in a format that can be submitted for clearing once connectivity is restored. It needs to handle the case where a queued transaction is declined after the fact, after the customer has already left.

Different processors support different offline models. Some support store-and-forward, where the POS queues transactions and submits them in batch. Others support offline authorization limits, where cards can be approved up to a threshold without a live authorization. Many support neither, and offline handling is entirely the responsibility of the POS vendor.

The absence of a standard offline model means every POS vendor reinvents this logic independently. And the reinventions are often wrong — either overly conservative (refusing too many legitimate transactions) or overly permissive (accepting too much risk).

The reconciliation problem

At the end of each business day, a merchant needs to reconcile their POS records against the funds that actually settled in their bank account. In theory, this is simple: transactions authorized during the day should match the settlement batch. In practice, it frequently doesn't work that way.

Partial settlements occur when a processor declines to settle a transaction that was authorized — often due to mismatched amounts, expired authorizations, or fraud flags triggered after the fact. Duplicate transactions appear when retry logic fires incorrectly. Tip adjustments submitted after authorization create discrepancies if not properly handled during settlement.

Each of these scenarios requires the POS to maintain enough state to identify and explain discrepancies. That state management is complex and largely undocumented. The processor's settlement reports often use internal identifiers that don't map cleanly to the transaction IDs used during authorization. Building a reconciliation system that handles all of this correctly requires detailed knowledge of each processor's settlement behavior — knowledge that is acquired through experience rather than documentation.

Why this hasn't been fixed

The payment industry has strong network effects and high switching costs. Processors have limited incentive to standardize in ways that would make them interchangeable. Terminal manufacturers have limited incentive to expose open APIs when proprietary protocols create lock-in. The certification process, however painful, creates a barrier that reduces competition from less-resourced vendors.

None of this is malicious. It's the natural output of an industry built incrementally over decades, where security requirements are legitimately stringent and where the cost of getting things wrong falls on merchants and consumers. But the consequence is an ecosystem where building reliable payment infrastructure requires navigating a maze of proprietary systems, underdocumented behaviors, and institutional knowledge that exists only inside the companies that have done it before.

The merchants using these systems deserve better. Building toward that requires being honest about what's actually broken.

This is part of an ongoing series on payment infrastructure and POS system design. The next article examines processor fragmentation in more detail — what it costs and what a unified approach might look like.