What a payment application audit actually covers
The work is not a vendor scorecard. It is an examination of how a live payment application moved money in a named period.
When a payments head in Perak asks us to “audit the gateway,” they often mean two different jobs at once. One is a general security visit. The other is an examination of the application that authorised, captured, and settled a specific book of transactions. We only take the second job, and the distinction matters.
A payment application audit starts from the settlement files (or the merchant statements) for the period named in the letter. We work backwards: which rule produced the capture, which log recorded the void, who could change a refund threshold after freeze, and whether the outbound file matches the application’s own totals.
We do not certify the vendor. We do not score the product against a feature list. We examine whether, for the period under review, the application’s outputs can be tied to source records without an unexplained bridge. If your team posts a late adjustment in a spreadsheet and pastes it into settlement, that adjustment is in scope.
Clients sometimes hope the audit will also redesign the checkout. That is a different engagement, and we will say so. The value of this work is a written view of the application as it actually ran.