Part 2 of a 9-part series on payment security - from card issuance to disputes.

In Part 1, we looked at where cardholder data is born - the issuance stage, where a card's PAN, name, CVV, and expiry first come together and pass through bureaus, files, and physical logistics. Now the card is in the customer's hands, and its life as a payment instrument begins.

That begins the moment of payment initiation - the tap, swipe, insert, or scan that kicks off every transaction. It is the first point at which live cardholder data enters the digital payment flow in real time, and it happens not in a controlled data centre but out in the wild: on terminals, mobile devices, and IoT hardware spread across thousands of merchant locations. That distribution is exactly what makes initiation such a high-value, hard-to-defend target.

This blog maps the payment initiation stage to its specific threats, the security controls that mitigate them, and the compliance frameworks that govern it.

Where Payment Initiation Sits in the Lifecycle

A quick reminder of the nine stages this series covers:

1. Card Issuance: KYC, embossing, personalisation, and distribution

2. Payment Initiation: Card tap/swipe/QR, PAN capture, encryption, and packet construction (this post)

3. Authorisation Request: Merchant to gateway to acquirer to network to issuer

4. Issuer Decision & Response: Fraud checks, HSM cryptogram validation, approve/decline

5. Capture / Completion: Locking funds after fulfilment

6. Clearing: Encrypted clearing files exchanged and validated

7. Reconciliation & Reporting: Matching settlements, posting to the GL, generating reports

8. Settlement / Funding: Treasury netting, ACH/camt.054 files, merchant funding

9. Disputes & Chargebacks: Cardholder disputes, evidence, and resolution

If issuance is about protecting data at rest in production systems, initiation is about protecting data the instant it is captured at the edge - and getting it safely into the authorisation flow.

Stage 2: Payment Initiation - Capturing Data at the Edge

Payment initiation is the bridge between the physical card and the digital authorisation network. It is where sensitive data is read from the card, protected, and packaged for transmission. Everything that follows in the lifecycle depends on this step being done securely, because a weakness here exposes raw cardholder data at the very point of capture.

How the Payment Initiation Flow Works

The initiation process typically unfolds in five steps:

1. Customer presents the card. The customer taps, swipes, inserts, or scans a QR/NFC code at the point of interaction.

2. The device reads the data. The SDK or POS firmware reads the PAN and transaction details.

3. Sensitive fields are protected. The device or app encrypts or tokenizes the sensitive data.

4. The authorisation packet is built. A message is assembled in the relevant format - ISO 8583 for card rails, ISO 20022 for UPI.

5. The packet is sent onward. The authorisation request is transmitted to the gateway or acquirer.

Much of the initiation process depends on hardware and software at the edge - terminals, mobile SDKs, embedded firmware, and QR payloads. Unlike the controlled environments later in the lifecycle, this stage runs on a sprawling, heterogeneous, and physically exposed fleet of devices. That shapes the threat landscape considerably.

The Threats: Where Payment Initiation Goes Wrong

Because initiation captures live cardholder data on widely distributed, often third-party hardware and software, its risk profile centres on the edge. The most significant threats include:

• Rogue firmware on POS and IoT devices: Compromised or tampered firmware can silently capture or redirect card data at the point of read.

• POS malware and RAM scraping: Malware resident on terminals can harvest cardholder data from memory before it is encrypted.

• Insecure SDKs with hardcoded keys: Payment SDKs that embed credentials or keys hand attackers the means to decrypt or impersonate.

• Malicious QR redirects: Tampered or spoofed QR codes can divert customers to fraudulent payment destinations.

• PCI scope creep from third-party SDKs: Every embedded SDK that touches payment data pulls more of the environment into PCI scope, often invisibly.

The common thread: at initiation, the attack surface is physically distributed and software-dense. A single vulnerable SDK or compromised firmware image can affect every device that runs it, turning a localised flaw into a fleet-wide exposure.

The Security Controls: What It Takes to Secure Payment Initiation

Mitigating these threats requires controls that reach down to the firmware and SDK level, validate payloads, and continuously watch the edge. Effective controls at this stage include:

• IoT security testing which includes firmware and embedded systems and hardware testing to find tampering, weak key storage, and exploitable defects in the devices themselves.

• Application and API penetration testing (CREST-aligned) across the payment apps and interfaces that handle card data.

• QR / UPI payload fuzzing to surface parsing flaws and injection paths in QR and UPI handling.

• Continuous vulnerability assessment scanning to keep pace with newly disclosed weaknesses across the device and app estate.

• Static application security testing (SAST) focused on hardcoded API keys and credential leaks before code ships.

• Supply-chain risk assessments of SDK OEMs to manage the third-party components that drive PCI scope creep.

• CIS / NIST security hardening baselines to lock down device and system configurations.

• Sensitive-data discovery for hunting for plain-text PAN wherever it may be captured or cached.

• EMV kernel and QR reverse engineering to validate how payment logic and payloads actually behave under adversarial conditions.

• Agentic SOC and SOAR-driven monitoring across POS networks for continuous detection and rapid containment.

Together, these controls address the full spread of initiation risk: the firmware, the SDKs, the payloads, the configurations, and the networks at the edge.

The Compliance Frameworks Governing Payment Initiation

Payment initiation is governed by a cluster of standards focused on protecting data at the point of interaction and securing the devices that capture it. Teams operating at this stage typically need to satisfy:

• PCI DSS v4.0 - the foundational standard for protecting cardholder data.

• PCI P2PE v3.1 (Point-to-Point Encryption) - for encrypting cardholder data from the point of capture.

• PCI MPoC v1.0 (Mobile Payments on COTS) - for accepting payments on off-the-shelf mobile devices.

• PCI PTS POI v6.x (PIN Transaction Security / Point of Interaction) - for the security of the payment devices themselves.

• RBI Data Localisation - governing where Indian payment data may be stored and processed.

• NPCI UPI Framework - for UPI-based initiation.

• EMVCo Contactless - for contactless and NFC card interactions.

The takeaway is that initiation security is device- and channel-specific. The right framework depends on how the payment is accepted - encrypted terminal, mobile COTS device, UPI, or contactless, and most real-world environments must satisfy several of these at once.

Why Payment Initiation Deserves Your Attention

Initiation is the moment live cardholder data enters your world, and it does so at the least controlled point in the entire lifecycle - on devices you may not fully own, running software you may not have written, in physical locations you cannot constantly supervise. Encryption and tokenisation at this stage are what shrink everything downstream from a sea of raw PANs to protected, lower-risk data. Get initiation right, and you reduce both your breach exposure and your PCI scope. Get it wrong, and no downstream control can fully recover the data you have already lost at the edge.

How SISA's Solutions Help Address These Threats

Securing payment initiation requires capabilities that reach all the way down to firmware and SDKs while keeping watch over a distributed device fleet. SISA brings these together into an integrated programme purpose-built for the payments ecosystem:

• Firmware and embedded device testing. SISA’s IoT security testing services test POS and IoT firmware for tampering, weak key storage, and exploitable defects, securing the devices where card data is first read.  

• API and application security testing. SISA's CREST-aligned penetration testing probes payment apps, SDKs, and interfaces for exploitable flaws at the point of capture.

• Third party risk management. SISA evaluates SDK OEMs and third-party components to manage the dependencies that silently expand PCI scope.  

• SISA Radar for sensitive-data discovery and classification. SISA Radar hunts for plain-text PAN wherever it is captured or cached, bringing clarity to scope and surfacing exposed data for remediation.

• SISA ProACT Agentic SOC with SOAR-driven response. Continuous monitoring across POS networks, with automated response actions to contain threats at the edge in real time.

• Compliance and certification programmes. From PCI DSS compliance and PCI MPoC to payment data security programs, SISA's assessment and training teams help you meet the device- and channel-specific obligations that govern initiation.  

The result is defence-in-depth tailored to where initiation risk actually lives - in the firmware, the SDKs, the payloads, the configurations, and the networks at the edge, rather than a one-size-fits-all checklist.

In the next part of this series, we follow the packet inward: Authorisation Request - how the transaction travels from merchant to gateway to acquirer to network to issuer in under two seconds, and how to secure the APIs, TLS sessions, and switches that carry it.