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

In Part 2, we followed cardholder data to the edge - the tap, swipe, or scan where a live PAN is first captured and packaged into an authorisation request. Now that packet has to travel.  

This is the Authorisation Request, and its defining characteristic is motion across trust boundaries. The data is no longer sitting on a single device; it is in transit, hopping between organisations, protocols, and networks, each handoff a moment where it can be intercepted, replayed, or manipulated.  

As a quick reminder, this series maps each stage of the payment lifecycle to its specific threats, the security controls that mitigate them, and the compliance frameworks that govern it. Having covered where card data is captured, we now turn to how it moves - securely and in real time — to the issuer and back.

Stage 3: Authorisation Request - Securing Data in Motion

The authorisation request is the connective tissue of a payment. In under two seconds, a transaction is routed through a chain of independent parties - merchant, gateway, acquirer, network, issuer - and back. Each link in that chain is operated by a different organisation, runs different software, and exposes different interfaces. The risk here is not concentrated in one system; it lives in the gaps between systems - the APIs, the protocols, the network segments, and the trust assumptions that connect them.

How the Authorisation Request Flow Works

The authorisation process typically unfolds in five steps:

1. Merchant opens a secure channel. The merchant host establishes a TLS connection and sends the authorisation packet to the gateway.

2. Gateway enriches and routes. The gateway adds context - 3DS authentication and risk scoring, and forwards the request to the acquirer switch.

3. Switch relays onward. The switch routes the request through the relevant card or account network.

4. Issuer decides. The issuer host approves or declines the transaction.

5. Response returns. The decision travels back to the merchant, typically in two seconds or less.

The defining security principle here is that every handoff is a trust boundary. Data must be authenticated, encrypted, and integrity-protected at each hop - because a weakness anywhere along the path exposes the whole transaction.

The Threats: Where the Authorisation Request Goes Wrong

Because authorisation depends on APIs, protocols, and network paths spanning multiple organisations, its threats cluster around interception, manipulation, and abuse of the interfaces and trust relationships that connect them. The most significant include:

• API logic flaws (IDOR, broken access control): Flawed authorisation logic in gateway and switch APIs that lets attackers access or alter transactions they should not.

• Man-in-the-middle and replay attacks on ISO 8583: Interception or re-transmission of authorisation messages to forge or duplicate transactions.

• Weak TLS and HSM downgrade attacks: Forcing connections or cryptographic operations down to weaker, breakable configurations.

• Mis-segmented PCI zones: Poorly segmented networks that let an attacker move from a low-trust zone into the cardholder data environment.

• DDoS on acquirer switches: Volumetric attacks that disrupt the switches the entire flow depends on.

• MFA bypass and brute-force on the gateway: Defeating authentication controls to gain unauthorised access to gateway systems.

The common thread: at authorisation, the attacker's goal is to exploit the connections - to sit in the path, weaken the cryptography, or abuse the interfaces that move money between parties.

The Security Controls: What It Takes to Secure the Authorisation Request

Mitigating these threats requires controls focused on network and API security, cryptographic integrity, segmentation, and adversary simulation across the transaction path. Effective controls at this stage include:

• Network and API penetration testing across gateway, UPI, and BNPL interfaces to find exploitable logic and access flaws.

• Firewall and network segmentation review to ensure PCI zones are properly isolated and lateral movement is contained.

• Red-team exercises simulating ISO 8583 and UPI replay and bit-flip attacks to validate in-transit protections.

• Continuous vulnerability assessment scanning on the gateway and switch to keep pace with emerging weaknesses.

• Agentic SOC and SOAR-driven monitoring on the gateway for real-time detection and automated containment.

• TLS validation and downgrade-attack testing to confirm strong, non-negotiable cryptographic configurations.

• MFA bypass and IDOR testing to harden authentication and authorisation logic against abuse.

• Third-party risk assessment for gateway and switch providers, since so much of the path runs on external infrastructure.

• Quantum-crypto readiness assessment to prepare cryptographic protections for the post-quantum era.

• Sensitive-data discovery to hunt for plain-text PAN anywhere along the transaction path.

The Compliance Frameworks Governing the Authorisation Request

Authorisation is governed by standards focused on secure transmission, strong authentication, and the integrity of cryptographic operations. Teams operating at this stage typically need to satisfy:

• PCI DSS v4.0 (Req 4.2 — TLS) - specifically the requirement to protect cardholder data with strong cryptography during transmission over open networks.

• PCI 3DS Core v2.2 - security requirements for the 3-D Secure environment that adds cardholder authentication.

• EMVCo 3DS v2.2 - the underlying specification for modern 3-D Secure authentication flows.

• PCI PIN v3.1 - requirements for the secure management of PINs and the keys that protect them.

• RBI PA-PG Guidelines - regulatory requirements for payment aggregators and payment gateways in India.

• RBI Cross-Border Payments - obligations governing transactions that cross national boundaries.

Why Authorisation Demands Path-First Thinking

Issuance risk is concentrated and initiation risk is distributed across devices, but authorisation risk lives in the connections. The transaction is only as secure as the weakest handoff along a chain of independent parties. You cannot secure this stage by hardening any single system; you have to secure the journey end to end: authenticating every hop, enforcing strong cryptography that cannot be downgraded, segmenting networks so a foothold in one zone does not become access to the cardholder data environment, and assuming an adversary may be sitting somewhere in the path. Authorisation demands path-first thinking.

How SISA's Solutions Help Address These Threats

Securing the authorisation request calls for deep network and API expertise, cryptographic assurance, and the adversary simulation needed to validate protections across a multi-party path. SISA brings these together into an integrated programme built for transactions in motion:

• Network and API security testing. SISA’s security testing team tests gateway, switch, UPI, and BNPL interfaces for IDOR, broken access control, and logic flaws - closing the API gaps that attackers exploit at this stage.  

• Red teaming for in-transit attacks. SISA simulates ISO 8583 and UPI replay, bit-flip, and MITM scenarios to validate whether your in-transit protections actually hold against a determined adversary.

• Network segmentation and firewall review. SISA validates that PCI zones are correctly isolated and that lateral movement into the cardholder data environment is contained.  

• TLS and cryptographic assurance, including quantum readiness. SISA tests for downgrade attacks and weak configurations and assesses readiness for post-quantum cryptography.

• Third-party risk assessment. SISA’s risk and compliance experts evaluate gateway, switch, and aggregator providers, helping you manage the external infrastructure that so much of the path depends on.

• SISA Radar for sensitive-data discovery and classification. SISA Radar hunts for plain-text PAN anywhere along the transaction path, surfacing exposed data and bringing clarity to PCI scope.

• SISA ProACT Agentic SOC. This advanced managed detection and response (MDR) solution offers continuous monitoring across gateways and switches, with automated response to contain threats - including disruption attempts, in real time.

• Compliance and assessment programmes. From PCI DSS Compliance and PCI 3DS Core through PCI PIN and SWIFT, SISA's Qualified Security Assessors (QSAs) help you meet the transmission- and authentication-focused obligations that govern authorisation.  

In the next part of this series, we arrive at the moment of decision: Issuer Decision & Response - how the issuer's switch, fraud engine, and HSM validate the transaction and build an approve-or-decline response, and how to secure the core banking and cryptographic systems at the heart of the flow.

‍