Business logic, tested as a sequence
Scanners test requests. Financial flaws live in sequences: what happens if step three is submitted twice, if step two is skipped, if a confirmation arrives after a cancellation, if two requests arrive at the same instant against the same balance.
Race conditions deserve naming. A balance check followed by a debit, without a lock, is a withdrawal that can be run twice. That is not a vulnerability class a tool recognizes, because every individual request is valid.
- Replaying a step that should only execute once
- Skipping or re-ordering steps in a multi-stage flow
- Concurrent requests against the same balance or limit
- Negative, zero, fractional and oversized amounts where the interface constrains them
- Currency and rounding handling where values convert
- Confirmation and cancellation arriving out of order
- Limits enforced in the client rather than the server
PCI DSS Requirement 11.4 if you touch card data
PCI DSS is explicit where other frameworks are not. Requirement 11.4 requires a documented penetration testing methodology (11.4.1), internal testing (11.4.2) and external testing (11.4.3), at least once every 12 months and also after any significant infrastructure or application upgrade or change.
The numbering changed in version 4, so guidance written for v3.2.1 cites 11.3 instead. Check which version your assessor is working from, and read the requirement text in the PCI Security Standards Council's document library rather than any vendor's summary of it.
Segmentation keeps your scope small
The cardholder data environment is whatever can reach card data. Segmentation is what keeps that set small, and PCI DSS gives segmentation testing its own sub-requirement precisely because the saving depends on the boundary actually holding.
If it does not hold, everything behind it is in scope and your assessment becomes much larger. That makes segmentation testing one of the few security activities with a direct, measurable cost saving.
Third parties and shared infrastructure
Payment flows run through processors, gateways and bank integrations you do not operate. Your authorization covers your systems; it does not authorize testing someone else's.
So those components stay out of scope unless the provider authorizes testing in writing as well. What is in scope is your side of each integration: how you store and transmit credentials, how you validate what comes back, and whether a forged or replayed callback is accepted.