A payment gateway security audit is a structured review of the technical and compliance controls protecting payment transaction infrastructure. It covers eight domains: PCI DSS scope and SAQ validation, encryption and TLS configuration, API security, access control and authentication, tokenization and card data handling, penetration testing, fraud detection controls, and audit logging. A full audit should be performed before any gateway goes live, annually for PCI DSS compliance, and after any significant architecture change, provider switch, or security incident.
Deloitte finds that as fraud tactics evolve, banks are layering in zero-trust architecture, multi-factor authentication, encryption, and audit controls to keep losses in check. Running a security audit against your payment gateway is how you verify those controls actually work, since PCI DSS compliance alone doesn’t test for tokenization gaps, exposed webhooks, or misconfigured TLS.
Three Types of Payment Gateway Security Audit
Which audit applies depends on where the gateway sits in its lifecycle, a distinction that carries the same weight as choosing the right payment gateway partner did when the integration was first built.
Audit Type | When to Run It | Primary Scope | Who Conducts It |
|---|---|---|---|
Pre-Launch Audit | Before any payment gateway goes live in production | Full 8-domain checklist; emphasis on architecture and compliance readiness | Internal engineering team + external security firm for penetration testing |
Periodic / Annual Audit | Annually for PCI DSS; quarterly vulnerability scans required for all levels | Full checklist; emphasis on drift from baseline, new vulnerabilities, and control effectiveness | QSA (Qualified Security Assessor) for Level 1; SAQ self-assessment for Level 2–4 |
Post-Incident / Triggered Audit | After a breach, significant architecture change, provider migration, or regulatory change | Targeted scope based on incident vector; plus full checklist to identify adjacent exposures | External security firm; QSA review if PCI DSS scope has changed |
Audit Type
Pre-Launch Audit
Periodic / Annual Audit
Post-Incident / Triggered Audit
When to Run It
Before any payment gateway goes live in production
Annually for PCI DSS; quarterly vulnerability scans required for all levels
After a breach, significant architecture change, provider migration, or regulatory change
Primary Scope
Full 8-domain checklist; emphasis on architecture and compliance readiness
Full checklist; emphasis on drift from baseline, new vulnerabilities, and control effectiveness
Targeted scope based on incident vector; plus full checklist to identify adjacent exposures
Who Conducts It
Internal engineering team + external security firm for penetration testing
QSA (Qualified Security Assessor) for Level 1; SAQ self-assessment for Level 2–4
External security firm; QSA review if PCI DSS scope has changed
Payment Gateway Security Audit: Step-by-Step Checklist
SAQ type isn’t a form you fill out after launch, it’s a direct consequence of how your card data flows through your architecture, which means getting it right starts at design time, not audit time. Where that data physically lives matters too: data residency requirements often shape CDE boundaries before a single PCI DSS control gets applied.
If you haven’t mapped your SAQ type against your actual integration model yet, our PCI DSS compliance checklist walks through that mapping in detail.
Audit Domain 1 — PCI DSS Scope and SAQ Validation
Audit Step | ✅ Pass Criteria | ❌ Fail Signal |
|---|---|---|
Confirm the correct PCI DSS SAQ type for your integration model (SAQ-A, SAQ-A-EP, SAQ-D) | SAQ type matches actual card data flow and integration architecture | SAQ-A applied when card data passes through your servers (should be SAQ-D or higher) |
Verify cardholder data environment (CDE) scope is defined and documented | CDE boundaries are documented; all systems that store, process, or transmit card data are identified | CDE is undefined or broader than necessary; scope creep means more systems to secure and audit |
Confirm PCI DSS level based on annual transaction volume | Level 1 (>6M transactions/year): QSA on-site assessment completed annually | Level 1 merchant conducting SAQ self-assessment instead of QSA audit |
Verify that all third-party service providers in scope are PCI DSS compliant | Written confirmation or Attestation of Compliance (AOC) from all third-party providers | No AOC on file for payment processor, tokenization provider, or hosting environment |
Audit Step
Confirm the correct PCI DSS SAQ type for your integration model (SAQ-A, SAQ-A-EP, SAQ-D)
Verify cardholder data environment (CDE) scope is defined and documented
Confirm PCI DSS level based on annual transaction volume
Verify that all third-party service providers in scope are PCI DSS compliant
✅ Pass Criteria
SAQ type matches actual card data flow and integration architecture
CDE boundaries are documented; all systems that store, process, or transmit card data are identified
Level 1 (>6M transactions/year): QSA on-site assessment completed annually
Written confirmation or Attestation of Compliance (AOC) from all third-party providers
❌ Fail Signal
SAQ-A applied when card data passes through your servers (should be SAQ-D or higher)
CDE is undefined or broader than necessary; scope creep means more systems to secure and audit
Level 1 merchant conducting SAQ self-assessment instead of QSA audit
No AOC on file for payment processor, tokenization provider, or hosting environment
Audit Domain 2 — Encryption and TLS Configuration
Encryption at rest and in transit is where cipher suite choices and key management design get locked in long before a security review ever touches the system, so this domain mostly audits decisions your engineering team has already made.
Audit Step | ✅ Pass Criteria | ❌ Fail Signal |
|---|---|---|
Verify TLS version: only TLS 1.2 or TLS 1.3 in use on all payment endpoints | TLS 1.3 preferred; TLS 1.2 acceptable; SSLv3, TLS 1.0, TLS 1.1 disabled | Any legacy SSL or TLS 1.0/1.1 endpoints discovered — PCI DSS non-compliant as of 2018 |
Confirm encryption of cardholder data at rest (AES-256 minimum) | AES-256 or equivalent applied to all stored card data; encryption keys managed separately from encrypted data | Card data stored in plaintext; encryption keys co-located with encrypted data |
Verify TLS certificate validity, issuer, and expiry monitoring | Valid certificate from trusted CA; automated expiry alerts configured; no self-signed certificates on production endpoints | Expired or self-signed certificates in production; no automated renewal in place |
Check cipher suite configuration: disable weak ciphers (RC4, DES, 3DES) | Only strong cipher suites enabled; verified via SSL Labs or equivalent scan | Weak or deprecated cipher suites active on payment endpoints |
Audit Step
Verify TLS version: only TLS 1.2 or TLS 1.3 in use on all payment endpoints
Confirm encryption of cardholder data at rest (AES-256 minimum)
Verify TLS certificate validity, issuer, and expiry monitoring
Check cipher suite configuration: disable weak ciphers (RC4, DES, 3DES)
✅ Pass Criteria
TLS 1.3 preferred; TLS 1.2 acceptable; SSLv3, TLS 1.0, TLS 1.1 disabled
AES-256 or equivalent applied to all stored card data; encryption keys managed separately from encrypted data
Valid certificate from trusted CA; automated expiry alerts configured; no self-signed certificates on production endpoints
Only strong cipher suites enabled; verified via SSL Labs or equivalent scan
❌ Fail Signal
Any legacy SSL or TLS 1.0/1.1 endpoints discovered — PCI DSS non-compliant as of 2018
Card data stored in plaintext; encryption keys co-located with encrypted data
Expired or self-signed certificates in production; no automated renewal in place
Weak or deprecated cipher suites active on payment endpoints
Audit Domain 3 — API Security
Rate limiting, schema validation, and error handling are engineering decisions made at the API design stage, and this is where an audit reveals whether those decisions held up under real traffic.
Audit Step | ✅ Pass Criteria | ❌ Fail Signal |
|---|---|---|
Verify API authentication: all payment API calls require valid API keys or OAuth tokens | All endpoints require authentication; no unauthenticated endpoints accessible in production | Any payment API endpoint accessible without authentication; test credentials active in production |
Check rate limiting on payment API endpoints (card submission, refund, void) | Rate limits applied and enforced; brute-force and enumeration attacks blocked at the API layer | No rate limiting on card submission endpoints; card testing attacks possible |
Verify API input validation: reject unexpected parameters and enforce strict schema validation | All inputs validated against strict schema; unexpected fields rejected; SQL injection and XXE protections in place | API accepts and processes unexpected parameters; no input sanitisation on payment fields |
Audit API error responses: payment errors must not leak card data, stack traces, or internal system information | Standardised error codes returned; no card data, internal paths, or system details in error responses | Error responses include raw exception messages, card numbers, or internal server paths |
Verify HTTPS-only enforcement: HTTP requests redirected to HTTPS or rejected | HTTPS enforced at load balancer or application layer; HTTP requests rejected or redirected; HSTS header present | Payment API endpoints accessible over HTTP; HSTS not implemented |
Audit Step
Verify API authentication: all payment API calls require valid API keys or OAuth tokens
Check rate limiting on payment API endpoints (card submission, refund, void)
Verify API input validation: reject unexpected parameters and enforce strict schema validation
Audit API error responses: payment errors must not leak card data, stack traces, or internal system information
Verify HTTPS-only enforcement: HTTP requests redirected to HTTPS or rejected
✅ Pass Criteria
All endpoints require authentication; no unauthenticated endpoints accessible in production
Rate limits applied and enforced; brute-force and enumeration attacks blocked at the API layer
All inputs validated against strict schema; unexpected fields rejected; SQL injection and XXE protections in place
Standardised error codes returned; no card data, internal paths, or system details in error responses
HTTPS enforced at load balancer or application layer; HTTP requests rejected or redirected; HSTS header present
❌ Fail Signal
Any payment API endpoint accessible without authentication; test credentials active in production
No rate limiting on card submission endpoints; card testing attacks possible
API accepts and processes unexpected parameters; no input sanitisation on payment fields
Error responses include raw exception messages, card numbers, or internal server paths
Payment API endpoints accessible over HTTP; HSTS not implemented
Audit Domain 4 — Access Control and Authentication
How permissions are structured — RBAC design, key rotation policy, review cadence — reflects choices made when the system was built, not something a security team bolts on later.
Audit Step | ✅ Pass Criteria | ❌ Fail Signal |
|---|---|---|
Verify least-privilege access: each system component has only the permissions required for its function | Role-based access control (RBAC) implemented; no service accounts with admin-level permissions | Shared admin credentials; service accounts with excessive database or network permissions |
Confirm multi-factor authentication (MFA) on all administrative access to the CDE | MFA required for all admin, DevOps, and support access to payment infrastructure | Admin access to CDE systems possible with password alone |
Audit API key lifecycle: rotation schedule, revocation process, and no hardcoded keys in code | API keys rotated on schedule; immediate revocation process documented; no keys in source code repositories | API keys hardcoded in application code or configuration files committed to version control |
Verify access review cadence: user and service account permissions reviewed quarterly | Access review completed and documented in last 90 days; terminated employee access revoked within 24 hours | No documented access review; former employee accounts still active |
Audit Step
Verify least-privilege access: each system component has only the permissions required for its function
Confirm multi-factor authentication (MFA) on all administrative access to the CDE
Audit API key lifecycle: rotation schedule, revocation process, and no hardcoded keys in code
Verify access review cadence: user and service account permissions reviewed quarterly
✅ Pass Criteria
Role-based access control (RBAC) implemented; no service accounts with admin-level permissions
MFA required for all admin, DevOps, and support access to payment infrastructure
API keys rotated on schedule; immediate revocation process documented; no keys in source code repositories
Access review completed and documented in last 90 days; terminated employee access revoked within 24 hours
❌ Fail Signal
Shared admin credentials; service accounts with excessive database or network permissions
Admin access to CDE systems possible with password alone
API keys hardcoded in application code or configuration files committed to version control
No documented access review; former employee accounts still active
Audit Domain 5 — Tokenization and Card Data Handling
Tokenization either gets designed into the data model from the start or it gets patched in afterward, and that decision is really a smaller piece of a bigger question: how data security in fintech applications gets engineered in from day one rather than layered on after launch.
Audit Step | ✅ Pass Criteria | ❌ Fail Signal |
|---|---|---|
Verify tokenization is in use: PAN replaced with token before any storage or logging | Full PAN never stored; token-based references used in application database and logs | Full PAN appears in application logs, database records, or error messages |
Confirm token mapping is stored separately from application database | Token vault is isolated from application infrastructure; separate access controls and audit logging | Token-to-PAN mapping stored in same database as application data |
Verify CVV/CVC is never stored post-authorisation | CVV/CVC not present in any database, log, or audit trail after transaction authorisation | CVV/CVC found in transaction logs, error dumps, or analytics data |
Confirm PAN masking in all displays, logs, and exports (show only last 4 digits) | PAN displayed as XXXX-XXXX-XXXX-1234 or equivalent in all UI, log, and export contexts | Full PAN visible in admin dashboard, support tool, or exported CSV |
Audit Step
Verify tokenization is in use: PAN replaced with token before any storage or logging
Confirm token mapping is stored separately from application database
Verify CVV/CVC is never stored post-authorisation
Confirm PAN masking in all displays, logs, and exports (show only last 4 digits)
✅ Pass Criteria
Full PAN never stored; token-based references used in application database and logs
Token vault is isolated from application infrastructure; separate access controls and audit logging
CVV/CVC not present in any database, log, or audit trail after transaction authorisation
PAN displayed as XXXX-XXXX-XXXX-1234 or equivalent in all UI, log, and export contexts
❌ Fail Signal
Full PAN appears in application logs, database records, or error messages
Token-to-PAN mapping stored in same database as application data
CVV/CVC found in transaction logs, error dumps, or analytics data
Full PAN visible in admin dashboard, support tool, or exported CSV
Audit Domain 6 — Penetration Testing
A pentest scoped to the network layer alone misses where most payment gateways actually break: business logic, authentication flows, and 3DS2 integration need to be in scope by design, not added as an afterthought.
Audit Step | ✅ Pass Criteria | ❌ Fail Signal |
|---|---|---|
Confirm penetration test conducted by qualified external firm within the last 12 months | Written pentest report from qualified third party; findings documented and remediated | No external penetration test in the last 12 months; only automated scanning used |
Verify pentest scope includes: API endpoints, authentication flows, business logic, and 3DS2 integration | Pentest scope documentation confirms coverage of payment-specific attack surfaces | Pentest scope limited to network layer; application-level and business logic testing absent |
Confirm all critical and high findings from last pentest are remediated and verified | Remediation evidence (code change, configuration update) documented for all critical/high findings; verification retest completed | Open critical or high findings from previous pentest with no remediation timeline |
Verify automated vulnerability scanning is in place and running quarterly | Approved Scanning Vendor (ASV) scans completed quarterly; last scan report shows no unresolved critical vulnerabilities | No ASV scans; only ad-hoc internal scanning; scan results older than 90 days |
Audit Step
Confirm penetration test conducted by qualified external firm within the last 12 months
Verify pentest scope includes: API endpoints, authentication flows, business logic, and 3DS2 integration
Confirm all critical and high findings from last pentest are remediated and verified
Verify automated vulnerability scanning is in place and running quarterly
✅ Pass Criteria
Written pentest report from qualified third party; findings documented and remediated
Pentest scope documentation confirms coverage of payment-specific attack surfaces
Remediation evidence (code change, configuration update) documented for all critical/high findings; verification retest completed
Approved Scanning Vendor (ASV) scans completed quarterly; last scan report shows no unresolved critical vulnerabilities
❌ Fail Signal
No external penetration test in the last 12 months; only automated scanning used
Pentest scope limited to network layer; application-level and business logic testing absent
Open critical or high findings from previous pentest with no remediation timeline
No ASV scans; only ad-hoc internal scanning; scan results older than 90 days
Audit Domain 7 — Fraud Detection and Transaction Controls
3DS2 implementation and velocity rule design determine how much fraud gets caught before it reaches a human, and this domain tests whether those rules were built for current attack patterns or left untouched since launch.
Audit Step | ✅ Pass Criteria | ❌ Fail Signal |
|---|---|---|
Verify 3DS2 (3D Secure 2) is implemented for card-not-present transactions | 3DS2 active on all card-not-present flows; exemptions documented and within regulatory limits | 3DS2 not implemented; 3DS1 in use (deprecated); no strong customer authentication for CNP transactions |
Confirm velocity controls: limits on transaction frequency, amount, and card-testing patterns | Velocity rules active and tested; card testing attacks (multiple low-value charges) detected and blocked | No velocity controls; card testing attacks pass undetected; no rate limits on payment submission |
Verify chargeback monitoring and alert thresholds are configured | Chargeback rate monitored against card scheme thresholds (Visa: 0.9%, Mastercard: 1%); alerts triggered before threshold breach | No chargeback monitoring; chargeback rate discovered at card scheme review, not proactively |
Confirm fraud rules are tested against real attack scenarios and updated quarterly | Fraud rule testing documented; rules updated to reflect current attack patterns; false positive rate monitored | Fraud rules set once at launch and not reviewed; high false positive rate blocking legitimate transactions |
Audit Step
Verify 3DS2 (3D Secure 2) is implemented for card-not-present transactions
Confirm velocity controls: limits on transaction frequency, amount, and card-testing patterns
Verify chargeback monitoring and alert thresholds are configured
Confirm fraud rules are tested against real attack scenarios and updated quarterly
✅ Pass Criteria
3DS2 active on all card-not-present flows; exemptions documented and within regulatory limits
Velocity rules active and tested; card testing attacks (multiple low-value charges) detected and blocked
Chargeback rate monitored against card scheme thresholds (Visa: 0.9%, Mastercard: 1%); alerts triggered before threshold breach
Fraud rule testing documented; rules updated to reflect current attack patterns; false positive rate monitored
❌ Fail Signal
3DS2 not implemented; 3DS1 in use (deprecated); no strong customer authentication for CNP transactions
No velocity controls; card testing attacks pass undetected; no rate limits on payment submission
No chargeback monitoring; chargeback rate discovered at card scheme review, not proactively
Fraud rules set once at launch and not reviewed; high false positive rate blocking legitimate transactions
Audit Domain 8 — Audit Logging and Webhook Security
Webhook signature design and idempotency handling are architecture calls made when the integration was built, and they’re the ones most often skipped under deadline pressure.
Audit Step | ✅ Pass Criteria | ❌ Fail Signal |
|---|---|---|
Verify all payment events are logged: transaction initiation, authorisation, capture, void, refund | Complete transaction lifecycle logged; logs include timestamp, actor, action, and outcome; logs are tamper-evident | Partial logging; refunds and voids not logged; logs can be modified without detection |
Confirm log retention meets PCI DSS requirements: 12 months minimum, 3 months immediately available | 12 months of logs retained; 3 months accessible for immediate review; retention policy documented | Logs deleted after 30–90 days; no documented retention policy; logs stored in same environment as application |
Verify webhook signature validation: all incoming webhooks validated before processing | HMAC signature validated on all incoming webhooks; requests without valid signature rejected; replay attack prevention in place | Webhooks processed without signature validation; any system can send webhook events to trigger refunds or status updates |
Confirm webhook endpoint security: authentication, HTTPS-only, and idempotency handling | Webhook endpoints require HTTPS; duplicate event handling prevents double-processing of refunds or captures | Webhook endpoint accessible over HTTP; no idempotency key; duplicate webhooks trigger duplicate refunds |
Audit Step
Verify all payment events are logged: transaction initiation, authorisation, capture, void, refund
Confirm log retention meets PCI DSS requirements: 12 months minimum, 3 months immediately available
Verify webhook signature validation: all incoming webhooks validated before processing
Confirm webhook endpoint security: authentication, HTTPS-only, and idempotency handling
✅ Pass Criteria
Complete transaction lifecycle logged; logs include timestamp, actor, action, and outcome; logs are tamper-evident
12 months of logs retained; 3 months accessible for immediate review; retention policy documented
HMAC signature validated on all incoming webhooks; requests without valid signature rejected; replay attack prevention in place
Webhook endpoints require HTTPS; duplicate event handling prevents double-processing of refunds or captures
❌ Fail Signal
Partial logging; refunds and voids not logged; logs can be modified without detection
Logs deleted after 30–90 days; no documented retention policy; logs stored in same environment as application
Webhooks processed without signature validation; any system can send webhook events to trigger refunds or status updates
Webhook endpoint accessible over HTTP; no idempotency key; duplicate webhooks trigger duplicate refunds
Webhook security gets less attention than any other domain on this list, yet it’s one of the most exploited surfaces on a payment gateway: an attacker who can send a forged webhook event doesn’t need to touch the card processing layer at all to trigger a refund, flip a transaction status, or quietly disable a fraud rule. A signature check that’s missing or misconfigured turns the webhook endpoint into an open door, no card data required.
Discover how to competently approach payment gateway security at a broader scale!
Audit Frequency by PCI DSS Level
Audit frequency isn’t one-size-fits-all — it’s set by your PCI DSS level, which is determined by transaction volume, not by how the gateway was architected.
PCI DSS Level | Transaction Volume | Audit Requirement | Required Activities |
|---|---|---|---|
Level 1 | Over 6 million transactions/year | Annual | On-site QSA assessment; quarterly ASV scans; annual penetration test; Report on Compliance (ROC) |
Level 2 | 1–6 million transactions/year | Annual | SAQ completion (with QSA assistance recommended); quarterly ASV scans; annual penetration test |
Level 3 | 20,000–1 million e-commerce transactions/year | Annual | SAQ completion; quarterly ASV scans |
Level 4 | Under 20,000 e-commerce transactions/year | Annual | SAQ completion; quarterly ASV scans recommended |
All Levels | — | Immediate | Unscheduled audit triggered by: data breach or suspected breach, significant architecture change, payment provider migration, new regulatory requirement |
PCI DSS Level
Level 1
Level 2
Level 3
Level 4
All Levels
Transaction Volume
Over 6 million transactions/year
1–6 million transactions/year
20,000–1 million e-commerce transactions/year
Under 20,000 e-commerce transactions/year
—
Audit Requirement
Annual
Annual
Annual
Annual
Immediate
Required Activities
On-site QSA assessment; quarterly ASV scans; annual penetration test; Report on Compliance (ROC)
SAQ completion (with QSA assistance recommended); quarterly ASV scans; annual penetration test
SAQ completion; quarterly ASV scans
SAQ completion; quarterly ASV scans recommended
Unscheduled audit triggered by: data breach or suspected breach, significant architecture change, payment provider migration, new regulatory requirement
If you’re still in the build phase, our how to build a payment gateway guide walks through where these decisions belong in the sequence.
Key Takeaways
- A payment gateway security audit spans 8 domains: PCI DSS scope, encryption and TLS, API security, access control, tokenization, penetration testing, fraud controls, and audit logging and webhook security.
- There are three audit types — pre-launch, annual, and post-incident, and each one carries a different scope and a different party responsible for running it.
- Level 1 merchants (over 6 million transactions/year) need an on-site QSA assessment every year; Levels 2 through 4 can complete a self-assessment (SAQ) instead.
- Eliminating the PAN means more than securing primary storage, it has to disappear from application logs, databases, and error messages too.
- Unsigned webhooks are one of the most exploited gaps in a payment gateway: without signature validation, an attacker can trigger refunds or change transaction status without ever touching card data.
- PCI DSS no longer accepts 3DS1 for card-not-present transactions, 3DS2 is the requirement now.
- No PCI DSS level is exempt from annual penetration testing by a qualified external firm; automated scanning alone doesn’t meet the requirement.
FAQ
What is a payment gateway security audit?
A payment gateway security audit is a structured review across eight domains — PCI DSS scope, encryption and TLS, API security, access control, tokenization, penetration testing, fraud controls, and audit logging and webhook security — covering technical, compliance, and operational security together. It differs from a general web audit by testing payment-specific surfaces like tokenization architecture, 3DS2, and webhook signatures that standard audits skip.
How often should I audit my payment gateway?
PCI DSS requires an annual audit at every merchant level — Level 1 needs an on-site QSA assessment, Levels 2-4 can self-assess via SAQ, and all levels need quarterly ASV scans. Outside that schedule, run an unscheduled audit after a breach, major architecture change, provider migration, or new regulatory requirement.
What is the difference between a PCI DSS audit and a payment gateway security audit?
A PCI DSS audit checks only the 12 PCI DSS requirements. A payment gateway security audit is broader, also covering API security, business logic, webhook security, fraud controls, and 3DS2 — so a gateway can pass PCI DSS and still have an exploitable webhook or unscoped business logic flaw.
Do I need a QSA for a payment gateway audit?
Level 1 merchants (over 6M transactions/year) need a QSA for their annual Report on Compliance; Levels 2-4 can self-assess via SAQ, though a QSA is worth it for SAQ-D scope. Penetration testing by a qualified external firm is required at every level regardless.
What is tokenization and why does it matter for a security audit?
Tokenization replaces a card’s Primary Account Number with a non-sensitive token before any storage or logging happens, and it’s the single most effective way to shrink your PCI DSS scope — if the PAN never touches your systems, most PCI DSS requirements stop applying to begin with. An audit needs to confirm the PAN is absent everywhere, not just in primary storage: logs, databases, error messages, and exports all count.
What is webhook security and why is it part of a payment gateway audit?
Webhooks notify your application of events like payments, refunds, and chargebacks. Without signature validation, an attacker can forge an event to trigger an unauthorized refund or bypass verification — no card data needed, and it’s consistently the most overlooked audit domain.
How much does a payment gateway security audit cost?
Costs vary by merchant level and audit scope. A QSA audit for Level 1 merchants typically runs $15,000–$50,000+ depending on environment complexity, while SAQ completion with QSA assistance falls in the $3,000–$10,000 range. External, payment-scoped penetration testing usually costs $5,000–$20,000, quarterly ASV scans run $500–$2,000 per quarter, and a scoped internal readiness assessment ahead of a formal audit typically costs $3,000–$8,000.
What tools are used in a payment gateway security audit?
Common tools: SSL Labs for TLS, OWASP ZAP or Burp Suite for API security, Nessus or Qualys for vulnerability scanning, plus an ASV tool for PCI DSS quarterly scans. None cover business logic or payment-specific scenarios, so a complete audit pairs automated scanning with manual penetration testing.