Engagement record
- Sector
- Card and transfer payments processing, Saudi Arabia
- Scope
- Application, API and infrastructure
- Focus
- Transaction logic, race conditions, authorisation across customers
- Frameworks
- Mapped to PCI DSS and SAMA expectations
- Outcome
- End-to-end VAPT with remediation guidance and retest
- Confidentiality
- Client not named; findings described by class
Context
Payment platforms rarely fail at the cryptography. They fail at the decimal that rounds the wrong way, the refund claimable twice inside the same millisecond, and the verification step that can be skipped by posting the next request directly.
None of those are malformed requests. Every one is a valid call that the platform was not written to expect in that order, which is why scanners do not find them and why the accounting team usually notices before security does.
Approach
Weight the endpoints that move value
A payment platform has a small number of endpoints that change money and a large number that do not. Effort was weighted accordingly rather than spread evenly across the route list.
Every state transition as a test case
Pending, authorised, captured, settled, refunded and reversed were treated as an attack surface, not a workflow diagram, including transitions attempted out of order and repeated.
Single-packet race testing
Withdrawals, refunds, transfers and limit checks were attacked with parallel requests landing inside the same processing window, with custom tooling written for the platform’s specific flow.
Three-times rule
Every race finding was demonstrated three times before it was written down, to separate a genuine window from timing noise.
Nothing was malformed. Every request was valid. The platform still lost money on each one.Report, business logic section
What was found
Findings are described by class and impact. Reproduction detail stays in the client’s report, a case study that hands a reader a working attack against a former client is a breach, not marketing.
| Class | What it meant |
|---|---|
| Transaction logic | Value-affecting inputs accepted in forms the ledger did not anticipate. |
| Concurrency | Processing windows where two requests both observed the same pre-transaction state. |
| Authorisation | Records reachable across customer boundaries on secondary paths such as reporting and export. |
| Infrastructure | Configuration and exposure findings on the hosting side, reported as paths rather than as an inventory. |
Outcome
Findings were mapped to PCI DSS requirements and SAMA framework expectations at delivery, so the compliance function received them in the structure it already reports against rather than having to translate a technical report.
Remediation guidance was specific to the platform’s stack, and the retest closed each finding only once re-exploitation failed.
Questions
How long does an end-to-end VAPT take for a payments platform?
An end-to-end VAPT on a payments platform runs at the upper end of the five to fifteen working day band we quote for application and API work, because the infrastructure layer is tested alongside them. It takes longer than a web application test of the same size because every state transition is its own test case, so the number of money-moving flows sets the schedule.
What is included in an end-to-end VAPT for a payments platform?
An end-to-end VAPT, meaning vulnerability assessment and penetration testing, covers three layers in one engagement: the application, the API, and the hosting infrastructure. On the payments platform we assessed, that meant transaction logic, concurrency on the money-moving endpoints, and hosting configuration. Delivery adds a proof of concept per finding, a PCI DSS and SAMA mapping, and a retest.
Does a payments penetration test cover refunds and settlement?
A payments penetration test covers the whole transaction lifecycle, not login and checkout alone, and refunds and settlement carry most of the weight because that is where value actually moves. Pending, authorised, captured, settled, refunded and reversed are each treated as attack surface.
What is the difference between a PCI DSS penetration test and a full VAPT?
A PCI DSS penetration test is scoped to the cardholder data environment and its segmentation under requirement 11.4, while a full VAPT asks what an attacker can do to the platform as a whole, so a PCI test can pass without ever asking whether a refund can be claimed twice. On the payments platform we assessed, the findings included transaction logic, concurrency and authorisation across customers.
Do you test the chargeback and dispute workflow for abuse?
Yes, the dispute and chargeback path is tested as part of the transaction lifecycle, because a reversal moves value in the opposite direction and is often the least guarded transition. We attempt it out of order and repeated, against transactions already settled or refunded. On the payments platform we assessed, value-affecting inputs were accepted in forms the ledger did not anticipate.
How do you test idempotency and reconciliation between our ledger and the processor?
Idempotency is tested by replaying the same value-moving request with the same key, in sequence and in parallel, then checking whether the ledger recorded one movement or two. Reconciliation is tested by looking for the gap between the ledger and what the processor confirms. On the payments platform we assessed, we confirmed two requests reading the same pre-transaction state.
How do you test for cross-tenant access between merchants on a payments platform?
Cross-tenant access is tested by requesting one merchant's records from a second merchant's session on every path that returns data, not only the main transaction API, which is why two merchant tenants are provisioned before testing starts. On the payments platform we tested, records were reachable across customer boundaries on reporting and export paths.