SoftPOS transforms an NFC-enabled smartphone or tablet into a payment acceptance device, allowing merchants to accept contactless card and mobile-wallet payments without relying on a traditional payment terminal.

But what actually happens after a customer taps a card or smartphone?

The transaction involves multiple layers, including the NFC interface, EMV kernel, SoftPOS application, payment backend, acquirer, payment switch, card network, issuer, and settlement systems.

Complete SoftPOS Architecture

Putting the major components together:

                    CUSTOMER
                       │
                       │ NFC TAP
                       ▼
              ┌─────────────────┐
              │ Smartphone NFC  │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │ EMV Contactless │
              │     Kernel      │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │ SoftPOS App     │
              └────────┬────────┘
                       │
                 Secure Channel
                       │
                       ▼
              ┌─────────────────┐
              │ Payment Backend │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │ Acquirer / PSP  │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │ Payment Switch  │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │  Card Network   │
              └────────┬────────┘
                       │
                       ▼
              ┌─────────────────┐
              │     Issuer      │
              └────────┬────────┘
                       │
                 AUTH RESPONSE
                       │
                       ▼
                SoftPOS App
                       │
                       ▼
                Transaction
                   Result

Understanding this complete SoftPOS transaction flow is important for banks, fintechs, payment service providers, acquirers, OEMs, and technology providers building or integrating Tap-to-Phone solutions.

This guide explains the SoftPOS payment journey—from the initial NFC tap through EMV processing, authorization, response handling, clearing, and settlement.

SoftPOS, also known as Tap to Phone or Tap on Phone, is a payment acceptance technology that enables a compatible mobile device to accept contactless payments using its built-in NFC capability.

Unlike traditional POS terminals, SoftPOS does not require a dedicated card reader for contactless acceptance.

A typical SoftPOS solution consists of:

• NFC interface
• SoftPOS application
• EMV contactless kernel
• Secure mobile environment
• Payment gateway or backend
• Acquirer integration
• Payment switch
• Card network connectivity
• Issuer authorization
• Transaction and settlement systems

The simplified architecture is:

Customer
   │
   │ Contactless Card / Mobile Wallet
   ▼
NFC Interface
   │
   ▼
EMV Contactless Kernel
   │
   ▼
SoftPOS Application
   │
   ▼
Payment Backend
   │
   ▼
Acquirer / Payment Processor
   │
   ▼
Payment Switch
   │
   ▼
Card Network
   │
   ▼
Issuer

The transaction response then travels back through the payment infrastructure to the SoftPOS application.

SoftPOS Transaction Flow at a Glance

The complete SoftPOS transaction can be represented as:

Customer
   │
   │ Tap Card / Mobile Wallet
   ▼
┌──────────────────────────────┐
│ NFC Interface                │
│ Smartphone / Tablet          │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ EMV Contactless Kernel       │
│ Application Selection        │
│ Card Authentication          │
│ Risk Management              │
│ Cryptogram Generation        │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ SoftPOS Application          │
│ Transaction Orchestration    │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│ Payment Backend              │
└──────────────┬───────────────┘
               │
               ▼
        Acquirer / Processor
               │
               ▼
          Payment Switch
               │
               ▼
          Card Network
               │
               ▼
             Issuer
               │
               ▼
       Authorization Response
               │
               ▼
        SoftPOS Application
               │
               ▼
        Transaction Result

1. Merchant Initiates the Transaction

The transaction begins when the merchant enters or selects the amount in the SoftPOS application.

For example:

Transaction Amount
        ↓
₹1,500
        ↓
Tap Card / Phone

The application switches the NFC interface into the appropriate contactless transaction mode.

At this point, the SoftPOS application prepares the transaction context and waits for the customer’s contactless card or mobile wallet.

2.NFC Detects the Customer’s Card or Device

When the customer taps a contactless card or NFC-enabled mobile wallet against the smartphone, the phone’s NFC interface detects the payment device.

NFC provides the communication channel between the payment device and the SoftPOS solution.

The NFC layer handles the exchange of low-level data, while the EMV kernel processes the payment logic.

A useful distinction is:

NFC carries the communication.
The EMV kernel processes the transaction logic.

The NFC interaction can be simplified as:

Contactless Card / Wallet
          │
          │ NFC
          ▼
   Smartphone NFC
          │
          ▼
   EMV Contactless
       Kernel

3. EMV Application Selection

After the card or wallet is detected, the EMV kernel begins processing the transaction.

A payment card can support one or more payment applications.

The kernel uses the available application identifiers and transaction configuration to determine the appropriate payment application.

This stage is important in multi-scheme environments where a solution may support different payment networks.

The simplified sequence is:

Card / Wallet
     │
     ▼
Application Information
     │
     ▼
Application Selection
     │
     ▼
Selected Payment Application

4. EMV Kernel Processes the Transaction

The EMV contactless kernel is one of the most important components in a SoftPOS architecture.

The kernel manages the EMV transaction logic between the payment device and the SoftPOS application.

Depending on the transaction and scheme requirements, the kernel handles functions such as:

• Application selection
• Data exchange
• Card authentication
• Terminal risk management
• Cardholder verification
• Processing restrictions
• Terminal action analysis
• Transaction processing
• Cryptogram generation
• Transaction outcome

The relationship can be visualized as:

NFC
 │
 ▼
EMV Kernel
 │
 ├── Application Selection
 ├── Data Processing
 ├── Authentication
 ├── Risk Management
 ├── CVM Processing
 └── Cryptogram Generation
 │
 ▼
SoftPOS Application

A certified EMV kernel therefore plays a central role in ensuring that the SoftPOS transaction follows the required payment scheme logic.

5. EMV Data Exchange Takes Place

The SoftPOS device and the payment card exchange EMV data through NFC.

The communication involves APDU-based exchanges between the terminal and card.

Depending on the transaction, the exchanged information can include EMV tags and transaction data required for processing.

Important EMV concepts can include:

• Application Identifier (AID)
• Application data
• Terminal verification results
• Transaction status information
• Application transaction counter
• Cryptographic data
• Card authentication information
• The flow can be simplified as:

SoftPOS Terminal
      │
      │ EMV APDU
      ▼
Payment Card
      │
      │ EMV Response
      ▼
SoftPOS Terminal

The EMV kernel interprets these exchanges according to the applicable payment specifications.

6. Card Authentication and Risk Management

The transaction then moves through several security and risk-management processes.

Depending on the transaction, the EMV environment may perform card authentication and terminal-side risk checks.

These mechanisms help determine whether the transaction can proceed and whether additional verification is required.

The transaction may involve:

• Card authentication
• Terminal risk management
• Processing restrictions
• Cardholder verification
• Transaction limits
• Offline/online decisioning

For online transactions, the card generates transaction-specific cryptographic information that can subsequently be validated during authorization.

7. Cardholder Verification

Cardholder verification depends on the transaction, card, payment scheme, amount, and applicable rules.

For many contactless transactions, the customer may not be asked to enter a PIN.

In other scenarios, additional verification may be required.

For a SoftPOS solution, the supported cardholder verification methods must align with the applicable certification and security requirements.

A simplified flow is:

Transaction
    │
    ▼
CVM Required?
   / \
 Yes  No
  │    │
  ▼    ▼
Verification
  │
  └──────► Continue Transaction

For supported SoftPOS implementations, PIN-related functionality requires appropriate security controls and certification.

8. EMV Transaction Cryptogram Is Generated

One of the key security mechanisms in an EMV transaction is the transaction cryptogram.

The transaction data is processed to generate cryptographic information that helps the issuer validate the transaction.

Conceptually:

Transaction Data
       +
Card Data
       +
Transaction Counter
       +
Cryptographic Keys
       │
       ▼
Transaction Cryptogram

The resulting cryptographic information becomes part of the authorization data sent through the payment infrastructure.

The issuer can use this information as part of its transaction validation and authorization process.

9. SoftPOS Application Creates the Authorization Request

Once the EMV kernel completes the required processing, the SoftPOS application receives the transaction result and relevant payment data.

The application then prepares the transaction for backend processing.

The flow becomes:

EMV Kernel
    │
    ▼
Transaction Data
    │
    ▼
SoftPOS Application
    │
    ▼
Secure Backend
    │
    ▼
Authorization Request

Depending on the implementation, the backend may transform and map transaction information into the format required by the acquirer or processor.

10. Transaction Travels to the Acquirer

The acquirer or acquiring processor acts as the merchant-side entry point into the payment network.

The authorization request is transmitted from the SoftPOS backend to the appropriate acquiring infrastructure.

The acquirer may perform functions such as:

• Merchant identification
• Transaction validation
• Message transformation
• Routing
• Risk checks
• Connection to payment networks

A simplified architecture is:

SoftPOS
   │
   ▼
SoftPOS Backend
   │
   ▼
Acquirer / Processor
   │
   ▼
Payment Network

The exact architecture varies depending on the payment provider and market.

11. Payment Switch Routes the Transaction

A payment switch routes the transaction to the appropriate destination.

For example:

SoftPOS Backend
       │
       ▼
Acquirer
       │
       ▼
Payment Switch
       │
       ├────► Network A
       ├────► Network B
       └────► Network C

The switch may perform transaction routing, message transformation, validation, and connectivity functions.

Payment messaging may also involve transaction identifiers and fields required for downstream processing.

12. Card Network Routes the Request to the Issuer

The card network receives the transaction and routes it toward the card issuer.

The overall path becomes:

SoftPOS
   ↓
Backend
   ↓
Acquirer
   ↓
Payment Switch
   ↓
Card Network
   ↓
Issuer

The issuer is the financial institution that issued the customer’s payment card.

13. Issuer Performs Authorization

The issuer receives the authorization request and evaluates the transaction.

Issuer-side processing can include:

• Card status validation
• Cryptogram validation
• Account checks
• Transaction risk assessment
• Available balance or credit checks
• Fraud controls
• Transaction limits
• Other issuer-specific authorization rules

The issuer then returns an authorization result.

Conceptually:

Authorization Request
        │
        ▼
      Issuer
        │
   ┌────┴────┐
   │         │
Approve    Decline
   │         │
   └────┬────┘
        ▼
Authorization Response

14. Authorization Response Travels Back

The response follows the reverse path back toward the merchant.

Issuer
   │
   ▼
Card Network
   │
   ▼
Payment Switch
   │
   ▼
Acquirer
   │
   ▼
SoftPOS Backend
   │
   ▼
SoftPOS Application

The application then displays the appropriate transaction status to the merchant.

For example:

Payment Approved
       ✓

or:

Payment Declined
       ✕

15. SoftPOS Displays the Transaction Result

The final transaction state should be clearly communicated to the merchant and, where appropriate, the customer.

A successful transaction may trigger:

• Success notification

• Receipt generation

• Transaction reference

• Merchant confirmation

• Backend transaction update

The application should also handle uncertain states carefully.

For example, if the issuer approved the transaction but the response was lost due to a connectivity problem, the SoftPOS application should not simply assume that the transaction failed.

This is why robust transaction-state management is essential.

SoftPOS Transaction State Management

A production SoftPOS solution should maintain a clear transaction state machine.

A simplified model is:

CREATED
   │
   ▼
WAITING_FOR_CARD
   │
   ▼
KERNEL_RUNNING
   │
   ▼
ONLINE_REQUEST
   │
   ▼
AUTH_PENDING
   │
   ├──────────────► DECLINED
   │
   ▼
APPROVED
   │
   ▼
COMPLETED

Exceptional conditions can include:

KERNEL_RUNNING
      │
      └──► TRY_AGAIN

ONLINE_REQUEST
      │
      └──► REVERSAL_PENDING

A reliable implementation should account for:

• Duplicate transaction attempts
• Network interruptions
• Card removal
• Application interruption
• Authorization timeouts
• Reversals
• Retry handling
• Reconciliation
• Idempotency

For example, if authorization may have succeeded but the response was not received, a reversal mechanism may be required before retrying the transaction.

What Happens After Authorization?

Authorization is not the same as settlement.

This distinction is important when explaining the complete SoftPOS payment flow.

Authorization

Authorization determines whether the transaction is approved or declined.

Clearing

Clearing involves exchanging and processing transaction records between payment participants.

Settlement

Settlement is the process through which funds are ultimately transferred between the relevant financial institutions.

The simplified lifecycle is:

Payment
   │
   ▼
Authorization
   │
   ▼
Clearing
   │
   ▼
Settlement

Therefore, a successful tap does not mean that the complete financial lifecycle ends at the authorization response.

SoftPOS Settlement Flow

After transactions are authorized, clearing and settlement processes take place according to the applicable payment ecosystem.

A simplified model is:

Merchant
   │
   ▼
Acquirer
   │
   ▼
Card Network / Payment System
   │
   ▼
Issuer
   │
   ▼
Settlement
   │
   ▼
Merchant Account

The actual settlement process varies according to the payment scheme, acquirer, processor, geography, and transaction type.

Security Considerations in SoftPOS

Because SoftPOS runs payment acceptance functionality on a general-purpose mobile device, security must be considered across the complete solution.

Important areas include:

Application Integrity

The solution should detect unauthorized application modification or repackaging using appropriate integrity and signature controls.

Secure Communication

Communication between the mobile application and backend should use appropriate transport security and, where required by the architecture, additional message-level protections.

Key Protection

Sensitive cryptographic keys should be protected using appropriate platform security mechanisms.

Android Keystore and hardware-backed security capabilities may be used where supported.

Anti-Tampering

A SoftPOS implementation should consider threats such as:

• Debugging

• Hooking

• Application modification

• Runtime manipulation

• Rooted or compromised devices

• Network interception

Transaction Security

EMV cryptographic controls, issuer-side validation, transaction counters, and appropriate authentication mechanisms contribute to transaction security.

Why the EMV Kernel Is Critical to SoftPOS

The EMV kernel is not simply an NFC communication component.

It is responsible for implementing important parts of the EMV transaction process.

A SoftPOS solution therefore requires careful integration between:

NFC Layer
    ↓
EMV Kernel
    ↓
Payment Application
    ↓
Backend
    ↓
Acquirer

For multi-scheme deployments, each supported payment scheme may have its own certification and integration requirements.

This makes EMV kernel selection, integration, testing, and certification important parts of a SoftPOS development program.

SoftPOS Certification and Compliance

EMV Level 2

Covers the payment kernel responsible for EMV transaction processing.

Level 3 / Acquirer Certification

Validates the integration between the payment application, acquirer, host, and applicable payment network.

PCI MPoC

Mobile payment acceptance solutions can also involve PCI requirements applicable to the mobile acceptance environment.

PCI DSS

Backend environments that store, process, or transmit applicable payment account data may require PCI DSS controls.

The exact certification path depends on the product architecture, payment schemes, geography, and implementation model.

SoftPOS vs Traditional POS

SoftPOS can therefore provide a software-centric approach to contactless payment acceptance while still requiring robust payment infrastructure and certification.

SoftPOS and Terminal Management

Large-scale SoftPOS deployments also require centralized management.

A Terminal Management System or equivalent platform can help manage:

• Application versions
• Configuration
• Payment parameters
• Certificates
• Security settings
• Device status
• Remote updates
• Transaction monitoring
• Merchant/device association

A simplified architecture is:

                 TMS / Management Platform
                         │
              ┌──────────┼──────────┐
              │          │          │
              ▼          ▼          ▼
           Device 1   Device 2   Device 3
              │          │          │
              ▼          ▼          ▼
           SoftPOS    SoftPOS    SoftPOS
              │          │          │
              └──────────┼──────────┘
                         ▼
                  Payment Backend

This becomes particularly important when deploying SoftPOS across a large merchant fleet.

Frequently Asked Questions About SoftPOS

What is SoftPOS?

SoftPOS is a software-based payment acceptance solution that uses a compatible mobile device’s NFC capability and an EMV-certified payment kernel to accept contactless payments.

How does a SoftPOS transaction work?

A typical transaction starts when a customer taps a card or mobile wallet. NFC communicates with the device, the EMV kernel processes the payment application and transaction data, and the SoftPOS application sends the transaction through the payment backend, acquirer, payment network, and issuer for authorization.

What is the role of an EMV kernel in SoftPOS?

The EMV kernel manages key parts of the EMV transaction, including application selection, data processing, authentication, risk management, cardholder verification, and cryptogram generation.

Does SoftPOS use NFC?

Yes. NFC provides the wireless communication interface between the customer’s contactless card or mobile wallet and the SoftPOS device.

What is the difference between SoftPOS and mPOS?

SoftPOS uses the mobile device’s own NFC capability and software to accept contactless payments. Traditional mPOS solutions commonly use an external payment reader connected to the mobile device.

Is authorization the same as settlement?

No. Authorization determines whether a transaction is approved or declined. Clearing and settlement are subsequent processes through which transaction records are processed and funds are ultimately transferred.

Can SoftPOS support multiple payment schemes?

Yes, depending on the solution architecture. Multi-scheme SoftPOS implementations require the appropriate certified kernels, integrations, testing, and scheme/acquirer certifications.

Can SoftPOS accept PIN transactions?

PIN support depends on the device, implementation, applicable certification, and payment environment. A SoftPOS solution must use appropriate security controls and certification for supported PIN functionality.

What happens if the network fails during a SoftPOS transaction?

The application should maintain a clear transaction state and distinguish between a transaction that definitely failed and one where authorization status is uncertain. Depending on the situation, timeout handling, reversal, retry, and reconciliation processes may be required.

Complete SoftPOS Transaction Flow

The complete journey can be summarized as:

NFC TAP
   │
   ▼
NFC Interface
   │
   ▼
EMV Contactless Kernel
   │
   ├── Application Selection
   ├── EMV Data Exchange
   ├── Authentication
   ├── Risk Management
   ├── CVM
   └── Cryptogram Generation
   │
   ▼
SoftPOS Application
   │
   ▼
Payment Backend
   │
   ▼
Acquirer / Processor
   │
   ▼
Payment Switch
   │
   ▼
Card Network
   │
   ▼
Issuer
   │
   ▼
Authorization Response
   │
   ▼
SoftPOS Application
   │
   ▼
Transaction Result
   │
   ▼
Clearing
   │
   ▼
Settlement

The complete SoftPOS ecosystem therefore involves much more than simply reading an NFC card.

NFC provides the communication channel. The EMV kernel executes payment logic. The SoftPOS application orchestrates the transaction. The backend connects the mobile experience to payment infrastructure. The acquirer, switch, network, and issuer process and authorize the transaction. Clearing and settlement complete the financial lifecycle.

For banks, fintechs, PSPs, acquirers, and OEMs planning a SoftPOS deployment, each layer needs to be considered during architecture, security, certification, integration, and production rollout.

Build and Integrate SoftPOS Payment Solutions With EazyPayTech

EazyPayTech supports payment technology initiatives involving EMV kernels, SoftPOS, payment application development, certification, payment integration, and secure payment infrastructure.

Our capabilities include:

• EMV Contactless Kernel
• SoftPOS / Tap on Phone solutions
• EMV L1/L2/L3 certification support
• Payment application integration
• Android POS solutions
• Terminal Management Systems
• PCI and payment security consulting
• RuPay and NCMC payment solutions
• Payment technology consulting and training

Whether you are a bank, fintech, PSP, acquirer, payment processor, or OEM, the right SoftPOS architecture can help you move from NFC acceptance to a complete, scalable payment ecosystem.

Explore SoftPOS, EMV, and payment technology solutions with EazyPayTech.

Contact EazyPayTech to discuss your SoftPOS or EMV payment project.