Penetration Testing a Fintech Payment Platform: What PCI DSS Requirement 11.4 Puts In Scope

Q: Does PCI DSS require a penetration test for a fintech payment platform?

If the platform stores, processes or transmits cardholder data, or can affect the security of the environment that does, Requirement 11.4 calls for internal and external penetration testing at least every 12 months and after significant change. Whether your platform is in scope depends on your role in the card flow and on what your assessor agrees, so confirm it with them before scoping.

Q: Can a vulnerability scan satisfy the PCI DSS penetration testing requirement?

No. Vulnerability scanning is a separate requirement. A pentest is a manual attempt to exploit weaknesses, chain them and test business logic. Scan output submitted in place of a pentest report is a common reason for a finding at assessment.

Q: What is segmentation testing and why does it belong in the scope?

If you rely on network segmentation to keep systems out of PCI scope, the standard expects that segmentation to be tested, not assumed. The test checks that systems outside the card environment cannot reach it. Service providers face a shorter testing cycle than merchants, so check which applies to you.

Q: What do payment-specific pentests test that a generic web test does not?

Business logic around money movement: race conditions on transfers and balances, object-reference flaws on account and payment identifiers, replay and idempotency handling, refund and reversal abuse, and webhook trust. These are flaws in how the platform behaves, so they usually do not appear in scanner output.

Q: Does the pentest have to be done by a QSA?

Sources describing the standard say the tester must be qualified and organizationally independent of the systems tested, not that they must be a QSA. Check the current wording of the standard and confirm your assessor's expectations before you sign a statement of work.

The short answer

For a fintech that handles card data or sits next to the systems that do, PCI DSS Requirement 11.4 asks for internal and external penetration testing at least every 12 months and after significant change, plus testing of any segmentation you rely on to keep systems out of scope. A useful scope turns that into named assets: the payment APIs, the admin and merchant consoles, the network paths into the card environment, and the segmentation boundary. It also includes the money-movement logic that scanners cannot test. A scan report does not replace any of it.

Who this is for

This is for the CTO, head of security or compliance lead at a payment platform, neobank back end or embedded-finance provider who has been told "we need a PCI pentest" and must turn that into a scope and a quote. It is not the open-banking article: for the PSD2 dedicated interface, read penetration testing a digital bank. For the general scoping method on a different vertical, see scoping a penetration test for a crypto exchange.

What Requirement 11.4 asks for, in plain terms

Secondary guides to the standard agree on the shape, though sub-requirement numbering varies between them, so check the exact wording in the current PCI DSS text and with your assessor.

Element	What it means for scoping
External and internal testing	Test from the internet and from inside the network, not one or the other.
Cadence	At least every 12 months, and after significant change.
Segmentation testing	If segmentation reduces your scope, prove it holds.
Service-provider cycle	Service providers are described as facing a shorter segmentation cycle. Confirm which category you are in.
Independence	The tester must be qualified and organizationally independent of what is tested.
Method	Testing follows a defined methodology and covers application and network layers.
Remediation	Exploitable findings are fixed and retested before the report is evidence.

Step 1: decide your role in the card flow

Scope starts with who you are. A merchant that redirects to a hosted payment page has a different footprint from a platform that merchants use to process card transactions, which may be treated as a service provider and put the whole application in scope. Write down where card data enters, where it is stored or tokenized, and which systems can reach those points. Your assessor decides what is in scope; the pentest scope should match their view, or the report will not close the requirement.

Step 2: name the assets, not "the platform"

List the payment and merchant APIs, the authentication and token endpoints, the admin and support consoles, webhook receivers, the network entry points into the card environment, and the third-party integrations that can call into any of them. Each gets an owner and a test type: external, internal, or both. "Test the platform" is not a scope; a list you can check off is. The same approach shapes a fintech hardening order, where the API and third-party layer comes before the perimeter.

Step 3: test the segmentation you claim

If a network zone is declared out of scope because it is separated from the card environment, the test should try to cross that boundary from the out-of-scope side. State the zones, the claimed rule and the vantage points in the scope. A segmentation claim that was never tested is an assumption, and the assessor will treat it as one.

Step 4: put the money logic in scope

Payment platforms fail in ways that a scanner reports as "no findings". Ask for these to be named test cases:

Race conditions on transfers, top-ups and balance checks, where two requests arrive together.
Object-reference flaws, where changing an account or payment identifier returns someone else's data.
Replay and idempotency handling on payment and payout calls.
Refund, reversal and chargeback paths that can be abused by an authenticated user.
Webhook trust: whether your platform accepts a forged callback as proof of payment.
Role boundaries between merchant users, support staff and administrators.

These are the same class of test as in the casino cashier test matrix, applied to a different money flow.

Step 5: set rules for a live payment system

A pentest against production payment endpoints needs rules of engagement. Agree test accounts and amounts, which actions must never run against real customers, what counts as a stop condition, and who on your side can be reached during testing. Say whether card-network or acquirer rules limit what may be tested, and ask the provider how test transactions are kept apart from real ones.

What the report must let you do

For compliance, the report has to show scope, method, findings and the retest. For engineering, each finding needs a reproduction and a fix direction. Ask in the quote what happens after you fix: what counts as a retest matters because an unretested critical finding leaves the requirement open. And what a real pentest report looks like shows the evidence to expect.

Limitations

This article is a scoping guide, not legal or compliance advice and not a substitute for the PCI DSS text or your assessor. It draws the 11.4 outline from secondary guides, so requirement numbering and details should be verified against the current standard. It states no prices, durations or AnySec-original figures. A pentest also tests a point in time; pair it with ongoing vulnerability assessment between engagements.

What to do next

Write down your role in the card flow, the asset list and the segmentation boundaries, then ask your assessor to confirm them. To turn that into a scoped engagement, request a fixed quote for penetration testing and send the asset list, the segmentation claims and your testing window. Our penetration testing page describes the engagement tiers and how a test runs.

Frequently asked questions

Does PCI DSS require a penetration test for a fintech payment platform? If you handle card data or can affect the systems that do, Requirement 11.4 calls for testing at least every 12 months and after significant change. Confirm scope with your assessor.

Can a vulnerability scan satisfy the PCI DSS penetration testing requirement? No. Scanning is a separate requirement and does not replace a manual pentest.

What is segmentation testing and why does it belong in the scope? It checks that systems you declared out of scope cannot reach the card environment.

What do payment-specific pentests test that a generic web test does not? Money-movement logic: races, object references, replay, refunds and webhook trust.

Does the pentest have to be done by a QSA? Guides describe a qualified, independent tester rather than a QSA. Confirm with your assessor.

Sources and review

Requirement 11.4 outline compiled from secondary guides to PCI DSS v4.0.x, including Strike, Bastion and SoftwareSecured; verify against the PCI Security Standards Council's current document. No AnySec-original numbers, case results or SLA figures are cited. Author: AnySec Engineering. Published 2026-10-15; last reviewed 2026-10-15.