Modern payment terminal architectures increasingly rely on standardized protocols to reduce integration costs, ensure interoperability, and simplify expansion across markets. Historically, SmartPOS systems relied on proprietary JSON schemas or acquirer-specific interfaces to transport EMV data to the host. While these custom designs can accelerate early development, they introduce long-term drawbacks: vendor lock-in, increased certification overhead, and difficulties scaling. The nexo protocol family—grounded in ISO 20022—addresses these challenges by providing an open, interoperable, and EMV-native communication model.

This article explains where Nexo belongs within a SmartPOS system, how it integrates with EMV components, and how it maps to legacy ISO 8583 switching infrastructures.

1. Nexo Within the SmartPOS Architecture

A typical SmartPOS terminal consists of three distinct integration boundaries:

1. SmartPOS Application → Embedded Payment SDK
2. Embedded Payment SDK → SmartPOS Application
3. SmartPOS Application → Acquirer Host

These boundaries differ significantly in certification scope and permitted protocols.

1.1 SmartPOS Application → Embedded Payment SDK

Nexo is not applicable at this boundary.

This interface lies strictly inside the PCI PTS approval boundary, where all EMV L1/L2 processing, card interaction, cryptographic PIN handling, and Secure Element operations occur. The interaction model is defined entirely by the terminal manufacturer’s Embedded Payment SDK, which exposes proprietary, security-certified APIs. Insertion of third-party protocols—such as Nexo—into this internal interface would violate the device’s certified security model.

1.2 Embedded Payment SDK → SmartPOS Application (Callbacks)

Not a Nexo interface.

This boundary returns non-sensitive EMV outputs—AIDs, EMV tags, CVM results, scheme preferences, and transaction outcome data—through manufacturer-defined callbacks. The interface is proprietary and not standardized. Nexo does not play a role here.

1.3 SmartPOS Application → Acquirer Host

This is the correct and recommended placement for the Nexo Acquirer Protocol (CAPE).

The Nexo Acquirer Protocol (CAPE) defines the full lifecycle of online card payment processing between the terminal and the acquirer host, including:

• Authorization (ARQC → ARPC)
• Refunds and reversals
• Pre-authorizations and completions
• Advice messages (e.g., offline uploads, retry flows)
• Batch transfer and reconciliation
• Optional Terminal Management functions

Nexo provides a modern, structured, and EMV-native alternative to ISO 8583, supporting both XML and JSON encodings while preserving alignment with the ISO 20022 data model.

1.4 Nexo in SoftPOS Architectures

The same architectural rules apply to SoftPOS (Tap-to-Phone) solutions:

• The SoftPOS SDK / MPoC kernel on the mobile device plays the role of the Embedded Payment SDK. It owns EMV processing, card interaction, and PIN entry within its certified security boundary and exposes proprietary APIs to the merchant application. Nexo is not used inside this boundary.
• The SoftPOS application (or its backend) acts as the POI when talking to the acquirer or PSP. At this boundary, using Nexo Acquirer Protocol (CAPE) instead of a proprietary JSON or raw ISO 8583 interface provides the same benefits as on SmartPOS: interoperability, vendor independence, and a consistent EMV-rich data model.
• In practice, implementations either run a Nexo client in the app (mobile app → acquirer over TLS) or use a cloud Nexo client where the app sends a thin JSON/REST payload to a backend that speaks Nexo to the acquirer.

In other words, Nexo is a strong fit for SoftPOS as the POI ↔ acquirer protocol, not as an internal protocol between the merchant app and the SoftPOS SDK.

2. Nexo Message Lifecycle

The following sequence illustrates the end-to-end lifecycle of a Nexo online authorization, including optional reversal and advice flows, and highlights where the acquirer host typically maps Nexo into legacy ISO 8583 formats for communication with schemes and issuers.

3. Nexo → ISO 8583 Mapping for Acquirer Hosts

Because many acquirers still interface with schemes and issuers using ISO 8583, a Nexo-to-ISO translation layer is typically required. This preserves backward compatibility while enabling the terminal channel to adopt ISO 20022-compliant structures.

3.1 Message-Level Mapping

3.2 Field-Level Mapping

4. Strategic Rationale for Nexo Adoption

The use of Nexo at the SmartPOS Application → Acquirer Host boundary introduces several long-term advantages:

• Interoperability and Vendor Independence: Eliminates acquirer-specific integration and reduces vendor lock-in.
• Cross-Border Consistency: Harmonizes integration across regions previously fragmented by domestic protocols.
• Rich EMV Data Models: ISO 20022 structures enable enhanced analytics, improved risk scoring, and better reconciliation.
• Security and Compliance: Nexo naturally enforces a clean separation between the Sales System and the Payment System, supporting PCI DSS scoping principles.
• Future-Proofing: Facilitates adoption of modern payment experiences, tokenization, and digital wallet support.

5. Summary

Nexo is not applicable inside the SmartPOS device boundary, where the Embedded Payment SDK and EMV kernel handle secure card-present operations.

However, for the SmartPOS Application → Acquirer Host interface, the Nexo Acquirer Protocol is the correct and recommended choice, aligning the terminal channel with modern ISO 20022 standards. The acquirer typically implements a Nexo ↔ ISO 8583 translation layer, enabling immediate compatibility with existing scheme interfaces while supporting a long-term migration strategy toward ISO 20022.