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

In Part 4, we reached the issuer's core - the switch, the fraud engine, and the HSM, and saw that the risk there was about protecting authority: the integrity of the decision itself. But an approval is only a promise. The money has not actually been claimed yet.

That happens at Capture / Completion. Once goods are shipped or services delivered, the merchant's order management system triggers a capture request, and the funds authorised earlier are finally locked against the customer's account. It sounds procedural, and that is precisely why it is dangerous. This is the stage where an approval becomes an amount, and where business logic, not cryptography, is the primary line of defence.

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 how a transaction is judged, we now turn to how it is executed — and how attackers manipulate the logic that turns "approved" into "paid."

Stage 4: Capture / Completion: Where Business Logic Becomes the Attack Surface

Capture is where the payment lifecycle passes out of the tightly regulated card infrastructure and into the merchant's own commercial systems - order management, ERP, and the microservices middleware stitching them together. These systems were built for commerce, not adversaries. They are optimised for throughput, integration, and speed of change.

And that is the point. At capture, the attacker does not need to break cryptography or steal a PAN. They need only to convince the system to do something legitimate-looking but wrong: capture twice, capture more, capture for an order that was never fulfilled. The exploit is not in the protocol; it is in the logic.

How the Capture Flow Works

The capture process typically unfolds in five steps:

1. Fulfilment triggers capture. The order management system initiates capture once goods are shipped or services delivered.

2. The capture packet is built. A request is assembled carrying the authorisation code and the amount to be captured.

3. The gateway forwards it. The capture request is routed to the acquirer.

4. Funds are locked. The authorised amount is locked against the customer's account.

5. Acknowledgement is logged. Confirmation is recorded back into the OMS or ERP.

The defining security principle here is transaction integrity. Every capture must map to exactly one authorisation, for exactly the authorised amount, exactly once - and the system must be able to prove it.

The Threats: Where Capture Goes Wrong

Because capture runs on commercial systems and custom APIs rather than hardened payment infrastructure, its threats cluster around abuse of business logic, replay, and the seams between microservices. The most significant include:

• Service-account abuse on OMS and ERP: Over-privileged machine identities used to trigger captures that no human ever authorised.

• Replay and amount-inflation attacks on the capture API: Re-sending or modifying capture requests to claim more than was approved.

• Double-capture via order-hijack replay: Capturing the same authorisation twice by replaying or hijacking an order flow.

• Partial capture fraud: Exploiting partial-capture functionality to claim more than the originally authorised amount.

• Idempotency bypass: Defeating the safeguards meant to ensure a capture request executes only once, no matter how many times it arrives.

• Middleware tampering in the microservices pipeline: Altering requests as they pass between services, where trust is often assumed rather than verified.

The common thread: at capture, the attacker exploits assumptions - that a request arriving twice was meant to arrive twice, that the amount in the packet matches the amount authorised, that a service calling another service must be legitimate. Every unverified assumption is an opening.

The Security Controls: What It Takes to Secure Capture

Mitigating these threats requires controls focused on application logic, API integrity, change control, and adversary simulation against the commercial systems that execute the capture. Effective controls at this stage include:

• Secure code review and API penetration testing across the OMS and microservices, where logic flaws, not protocol weaknesses - are the primary risk.

• Continuous vulnerability assessment scanning to keep pace with weaknesses across a fast-changing commercial stack.

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

• Red teaming simulating double-capture and order-hijack replay scenarios, to prove whether idempotency and amount validation genuinely hold under attack.

• CI/CD change-control hardening - because capture logic changes frequently, and an insecure deployment pipeline lets a subtle logic flaw reach production unnoticed.

Together, these controls address capture risk where it lives - in the application logic, the API contracts, the service-to-service trust boundaries, and the deployment pipeline that keeps changing all of them.

The Compliance Frameworks Governing Capture

Capture is governed by standards that focus on secure development and application-layer security - a marked shift from the cryptography-heavy obligations of earlier stages. Teams operating at this stage typically need to satisfy:

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

• PCI DSS Requirement 6 (Secure Development) - specifically the requirement to develop and maintain secure systems and software.

• PCI S3 v1.2.1 - the Software Security Framework governing the software that handles payment data.

• OWASP API Top 10 - the reference standard for the API vulnerabilities that dominate this stage, including broken object-level authorisation and business-logic abuse.

How SISA's Solutions Help Address These Threats

Securing capture calls for deep application and API security expertise, combined with adversary simulation aimed at business logic and the change-control discipline to keep it secure as it evolves. SISA brings these together into an integrated programme built for the commercial layer of the payment stack:

• Secure code review. SISA reviews OMS, ERP integration, and microservices code for the logic flaws - idempotency gaps, missing amount validation, weak authorisation checks, that define capture risk.

• API penetration testing. SISA tests capture APIs against the OWASP API Top 10, probing for broken object-level authorisation, replay exposure, and business-logic abuse.  

• Red teaming for capture-specific attacks. SISA simulates double-capture, order-hijack replay, and amount-inflation scenarios, validating whether your safeguards hold against an adversary who understands your business logic.

• CI/CD and change-control hardening. SISA hardens the deployment pipeline so that security review is not bypassed by velocity - closing the gap through which most capture logic flaws reach production.

• SISA ProACT Agentic SOC with SOAR-driven response. Continuous monitoring across OMS and middleware, with automated response to contain service-account abuse and anomalous capture activity in real time.  

• Compliance and assessment programmes. From PCI DSS v4.0 and PCI S3 through the OWASP API top 10, SISA's assessors help you meet the secure-development obligations that govern this stage.  

In the next part of this series, we move from individual transactions to bulk data: Clearing - how encrypted clearing files are built, transmitted, and validated between acquirers, networks, and issuers, and how to secure the batch files where cardholder data accumulates in volume.