Payment gateway security comes from architecture rather than add-on tools: card data is tokenized as early as possible, encrypted in transit and at rest, isolated in a segmented cardholder data environment, and monitored with tamper-evident logs. Every gateway that handles card data must meet PCI DSS. EU-facing gateways also fall under PSD2 and GDPR, and financial entities under DORA. Because the integration method decides PCI DSS scope, these requirements cost least when they are designed in before the build.
This guide maps payment gateway security from standard to system. It covers which standards apply and who enforces them, the technical controls each one mandates, how those controls fit into a security architecture, how to test them, how the integration method sets PCI DSS scope, and what changes when compliance is built in rather than retrofitted. Each standard governs a different layer of the gateway, with its own scope, audit cadence and technical trigger, so the same integration often has to meet several at once.
Payment Gateway Compliance Standards: Comparison Table
Depending on where it processes transactions and whose data passes through it, the same integration can fall under PCI DSS, PSD2, GDPR, DORA, SOC 2, ISO 27001, and PCI PIN/P2PE at once, each with its own scope, enforcement body, and technical requirement.
Standard | Full Name | Applies To | Key Gateway Requirements | Enforced By |
|---|---|---|---|---|
PCI DSS v4.0.1 | Payment Card Industry Data Security Standard (v4.0.1, published June 2024) | Any entity storing, processing, or transmitting cardholder data | 12 requirements covering network security, encryption, access control, monitoring, and penetration testing; annual validation based on merchant/service provider level | Card schemes (Visa, Mastercard, Amex) via acquiring banks |
PSD2 | Payment Services Directive 2 (Directive (EU) 2015/2366, applies from 13 January 2018; SCA rules under Delegated Regulation (EU) 2018/389, from 14 September 2019) | Payment service providers operating in the EU/EEA | Strong Customer Authentication (SCA) for online card payments; 3DS2 implementation; SCA exemptions (low-value, transaction risk analysis); open banking API obligations for account-holding banks, not card gateways | EU national competent authorities; EBA guidelines |
GDPR | General Data Protection Regulation (Regulation (EU) 2016/679, applies from 25 May 2018) | Any entity processing personal data of EU/EEA residents | Lawful basis for payment data processing; data minimisation; right to erasure (conflicts with transaction record retention under AML, tax and card scheme rules — must be architecturally resolved); data residency; breach notification within 72 hours | EU national data protection authorities (DPAs) |
DORA | Digital Operational Resilience Act (Regulation (EU) 2022/2554, applies from 17 January 2025) | Financial entities and ICT service providers in the EU from 17 January 2025 | ICT risk management framework; incident reporting; third-party ICT provider oversight; penetration testing (TLPT); digital operational resilience testing | EU national supervisory authorities; ESAs |
SOC 2 Type II | System and Organization Controls 2 (AICPA 2017 Trust Services Criteria, revised points of focus 2022) | Service providers handling customer data (US-centric; increasingly required globally) | Security, availability, processing integrity, confidentiality, and privacy trust service criteria; annual audit by CPA firm; required by enterprise clients as contract condition | AICPA; required by enterprise customers, not regulators |
ISO/IEC 27001 | Information Security Management System (ISO/IEC 27001:2022) | Global; particularly required for EU, UK, APAC enterprise clients | Information security management system (ISMS) covering risk assessment, security controls, incident management, and continuous improvement; complements PCI DSS | Accredited certification bodies; ISO |
PCI PIN / P2PE | PCI PIN Security / Point-to-Point Encryption (current versions in the PCI SSC Document Library) | Card-present, PIN-accepting payment gateways and terminal integrations | Secure PIN entry device (PED) standards; encrypted PIN blocks; P2PE solutions reduce PCI DSS scope for merchants by encrypting card data at point of interaction | PCI SSC (Security Standards Council) |
Standard
PCI DSS v4.0.1
PSD2
GDPR
DORA
SOC 2 Type II
ISO/IEC 27001
PCI PIN / P2PE
Full Name
Payment Card Industry Data Security Standard (v4.0.1, published June 2024)
Payment Services Directive 2 (Directive (EU) 2015/2366, applies from 13 January 2018; SCA rules under Delegated Regulation (EU) 2018/389, from 14 September 2019)
General Data Protection Regulation (Regulation (EU) 2016/679, applies from 25 May 2018)
Digital Operational Resilience Act (Regulation (EU) 2022/2554, applies from 17 January 2025)
System and Organization Controls 2 (AICPA 2017 Trust Services Criteria, revised points of focus 2022)
Information Security Management System (ISO/IEC 27001:2022)
PCI PIN Security / Point-to-Point Encryption (current versions in the PCI SSC Document Library)
Applies To
Any entity storing, processing, or transmitting cardholder data
Payment service providers operating in the EU/EEA
Any entity processing personal data of EU/EEA residents
Financial entities and ICT service providers in the EU from 17 January 2025
Service providers handling customer data (US-centric; increasingly required globally)
Global; particularly required for EU, UK, APAC enterprise clients
Card-present, PIN-accepting payment gateways and terminal integrations
Key Gateway Requirements
12 requirements covering network security, encryption, access control, monitoring, and penetration testing; annual validation based on merchant/service provider level
Strong Customer Authentication (SCA) for online card payments; 3DS2 implementation; SCA exemptions (low-value, transaction risk analysis); open banking API obligations for account-holding banks, not card gateways
Lawful basis for payment data processing; data minimisation; right to erasure (conflicts with transaction record retention under AML, tax and card scheme rules — must be architecturally resolved); data residency; breach notification within 72 hours
ICT risk management framework; incident reporting; third-party ICT provider oversight; penetration testing (TLPT); digital operational resilience testing
Security, availability, processing integrity, confidentiality, and privacy trust service criteria; annual audit by CPA firm; required by enterprise clients as contract condition
Information security management system (ISMS) covering risk assessment, security controls, incident management, and continuous improvement; complements PCI DSS
Secure PIN entry device (PED) standards; encrypted PIN blocks; P2PE solutions reduce PCI DSS scope for merchants by encrypting card data at point of interaction
Enforced By
Card schemes (Visa, Mastercard, Amex) via acquiring banks
EU national competent authorities; EBA guidelines
EU national data protection authorities (DPAs)
EU national supervisory authorities; ESAs
AICPA; required by enterprise customers, not regulators
Accredited certification bodies; ISO
PCI SSC (Security Standards Council)
The most common conflict sits between two individually correct requirements: GDPR’s right to erasure assumes data can be deleted on request; AML laws, tax rules and card scheme dispute rules require transaction records to be retained. PCI DSS itself pushes the other way, requiring card data to be deleted once it is no longer needed.
This is a data-modeling problem, as personal data and transaction records need separable structures so erasure on one doesn’t break retention on the other. Teams that skip this at the schema stage usually find out the hard way post-launch, see data security in fintech applications for how this plays out at the data layer.
Technical Security Requirements: What Each Standard Actually Mandates
Each payment gateway security standard in the comparison table above translates into specific technical controls at the gateway level — this section maps those controls to the requirement that mandates them.
Security Control | Technical Specification | Mandated By | Consequence of Non-Compliance |
|---|---|---|---|
Encryption in transit | TLS 1.2 minimum; TLS 1.3 strongly recommended; all legacy SSL and TLS 1.0/1.1 disabled | PCI DSS 4.0.1 Req 4; GDPR Art. 32; ISO 27001 | PCI DSS non-compliance; GDPR fine up to €10 million or 2% of global annual turnover for security failures under Art. 32 |
Encryption at rest | AES-256 for stored cardholder data; encryption keys managed separately from encrypted data; key rotation policy documented | PCI DSS 4.0.1 Req 3; ISO 27001; SOC 2 | PCI DSS Level 1 audit failure; SOC 2 report qualification; loss of enterprise contracts requiring SOC 2 |
Tokenization | Full PAN replaced with token before any storage or logging; token vault isolated from application; network tokenization (EMVCo) for recurring payments | PCI DSS 4.0.1 Req 3 (scope reduction); card scheme network tokenization standards | Without tokenization, all application systems are in PCI DSS scope, multiplying compliance cost and complexity |
Strong Customer Authentication (SCA) | 3DS2 implementation for all CNP transactions in PSD2 scope; two-factor authentication combining possession + knowledge or inherence; exemptions for low-value and low-risk transactions | PSD2 RTS on SCA; EU national competent authority guidelines | Under card scheme rules, the merchant bears chargeback cost for fraud on unauthenticated transactions; PSP regulatory fine for systematic SCA bypass |
Access control | Role-based access control (RBAC); MFA on all CDE access; least-privilege principle; quarterly access review; service account permission audit | PCI DSS 4.0.1 Req 7 & 8; SOC 2; DORA ICT risk framework | PCI DSS audit finding; SOC 2 trust criteria failure; DORA ICT risk management deficiency |
Audit logging and monitoring | All payment events logged with timestamp, actor, action, outcome; tamper-evident logs; 12-month retention (3 months immediately available); real-time anomaly alerting | PCI DSS 4.0.1 Req 10; DORA incident reporting; GDPR breach notification | PCI DSS non-compliance; DORA incident reporting failure (staged reporting deadlines for major ICT incidents); GDPR breach notification failure |
Penetration testing | Annual internal and external penetration tests by a qualified, organizationally independent tester, repeated after significant changes; payment-specific scope (API, business logic, 3DS2, tokenization); all critical/high findings remediated before next assessment | PCI DSS 4.0.1 Req 11; DORA TLPT (Threat-Led Penetration Testing) for in-scope financial entities | PCI DSS non-compliance; DORA TLPT deficiency for regulated financial entities in EU |
Vulnerability management | Quarterly ASV scans (PCI DSS); internal vulnerability scanning; critical and high-security patches installed within one month; OWASP Top 10 coverage in application security testing | PCI DSS 4.0.1 Req 6 & 11; ISO 27001; SOC 2 | PCI DSS quarterly scan failure; ISO 27001 nonconformity; open vulnerabilities found in SOC 2 audit |
Security Control
Encryption in transit
Encryption at rest
Tokenization
Strong Customer Authentication (SCA)
Access control
Audit logging and monitoring
Penetration testing
Vulnerability management
Technical Specification
TLS 1.2 minimum; TLS 1.3 strongly recommended; all legacy SSL and TLS 1.0/1.1 disabled
AES-256 for stored cardholder data; encryption keys managed separately from encrypted data; key rotation policy documented
Full PAN replaced with token before any storage or logging; token vault isolated from application; network tokenization (EMVCo) for recurring payments
3DS2 implementation for all CNP transactions in PSD2 scope; two-factor authentication combining possession + knowledge or inherence; exemptions for low-value and low-risk transactions
Role-based access control (RBAC); MFA on all CDE access; least-privilege principle; quarterly access review; service account permission audit
All payment events logged with timestamp, actor, action, outcome; tamper-evident logs; 12-month retention (3 months immediately available); real-time anomaly alerting
Annual internal and external penetration tests by a qualified, organizationally independent tester, repeated after significant changes; payment-specific scope (API, business logic, 3DS2, tokenization); all critical/high findings remediated before next assessment
Quarterly ASV scans (PCI DSS); internal vulnerability scanning; critical and high-security patches installed within one month; OWASP Top 10 coverage in application security testing
Mandated By
PCI DSS 4.0.1 Req 4; GDPR Art. 32; ISO 27001
PCI DSS 4.0.1 Req 3; ISO 27001; SOC 2
PCI DSS 4.0.1 Req 3 (scope reduction); card scheme network tokenization standards
PSD2 RTS on SCA; EU national competent authority guidelines
PCI DSS 4.0.1 Req 7 & 8; SOC 2; DORA ICT risk framework
PCI DSS 4.0.1 Req 10; DORA incident reporting; GDPR breach notification
PCI DSS 4.0.1 Req 11; DORA TLPT (Threat-Led Penetration Testing) for in-scope financial entities
PCI DSS 4.0.1 Req 6 & 11; ISO 27001; SOC 2
Consequence of Non-Compliance
PCI DSS non-compliance; GDPR fine up to €10 million or 2% of global annual turnover for security failures under Art. 32
PCI DSS Level 1 audit failure; SOC 2 report qualification; loss of enterprise contracts requiring SOC 2
Without tokenization, all application systems are in PCI DSS scope, multiplying compliance cost and complexity
Under card scheme rules, the merchant bears chargeback cost for fraud on unauthenticated transactions; PSP regulatory fine for systematic SCA bypass
PCI DSS audit finding; SOC 2 trust criteria failure; DORA ICT risk management deficiency
PCI DSS non-compliance; DORA incident reporting failure (staged reporting deadlines for major ICT incidents); GDPR breach notification failure
PCI DSS non-compliance; DORA TLPT deficiency for regulated financial entities in EU
PCI DSS quarterly scan failure; ISO 27001 nonconformity; open vulnerabilities found in SOC 2 audit
Payment Gateway Security Architecture
The technical requirements above describe what each standard demands. Payment gateway security architecture is how those demands become a system design. Most of a gateway’s audit scope, and most of its compliance cost, is decided by how a few layers are arranged: where card data enters, where it is replaced with a token, which systems can reach it, and how keys and logs are managed. Get these layers right at the design stage, and most controls in the table above follow from the architecture rather than being added afterward.
A secure gateway is typically built in five layers.
Tokenization
Tokenization is the layer that shrinks PCI DSS scope the most. The full card number (PAN) is replaced with a token as early in the flow as possible, ideally before it reaches any application server, so downstream systems such as order management, analytics, CRM and support tools only ever handle tokens. The token vault that maps tokens back to PANs is isolated in its own segment, with access restricted to a small set of services. For recurring and stored-credential payments, network tokens (EMVCo) issued by the card schemes can replace gateway-generated tokens, which also makes stored cards portable between providers.
Encryption
Card data and sensitive authentication data are encrypted everywhere they move or rest:
- In transit: TLS 1.2 or higher on every connection, including internal service-to-service traffic inside the cardholder data environment (CDE).
- At rest: strong cryptography such as AES-256 for any stored PAN.
Encryption doesn’t remove systems from PCI DSS scope on its own. Its value depends entirely on how the keys are managed, which is the next layer.
Network Segmentation
Segmentation separates the CDE from everything else. The perimeter sits at the outer edge: a web application firewall and API gateway filter traffic before it reaches payment services. Inside, firewalls and network policies allow only the connections the payment flow needs. PCI DSS doesn’t require segmentation, but without it, every connected system falls into scope. With it, the audit can focus on the segment that actually handles card data. Segmentation controls must be tested regularly to prove they work, as covered in the testing section below.
Key Management
Encryption keys are stored and used separately from the data they protect, typically in a hardware security module (HSM) or a cloud key management service backed by HSMs. Keys are generated, rotated, revoked and retired under documented procedures. No single person can access a complete key (split knowledge and dual control), and only the services that need decryption have permission to request it.
Monitoring and Logging
Every access to card data and every administrative action is logged with the actor, time, action and outcome, in tamper-evident storage. Logs feed a SIEM that alerts on anomalies in real time, alongside intrusion detection at the CDE boundary. This layer is what turns a suspected incident into evidence, and it supports the incident reporting deadlines under GDPR and DORA.
How the Layers Map to Requirements
Architecture layer | What it does | Effect on compliance scope | Key requirements |
|---|---|---|---|
Tokenization | Replaces PANs with tokens before downstream systems see them | Removes most application systems from PCI DSS scope | PCI DSS Req. 3; EMVCo network tokenization |
Encryption | Protects data in transit and at rest | Required for any system that still handles card data | PCI DSS Req. 3, 4; GDPR Art. 32 |
Network segmentation | Isolates the CDE; filters traffic at the edge | Limits audit scope to the CDE segment | PCI DSS Req. 1, 6.4, 11.4.5 |
Key management | Controls the key lifecycle in HSMs or a KMS | Determines whether encryption actually protects data | PCI DSS Req. 3.6, 3.7 |
Monitoring and logging | Records and alerts on all CDE activity | Provides audit evidence and incident detection | PCI DSS Req. 10, 11.5; DORA incident reporting; GDPR Art. 33 |
Architecture layer
Tokenization
Encryption
Network segmentation
Key management
Monitoring and logging
What it does
Replaces PANs with tokens before downstream systems see them
Protects data in transit and at rest
Isolates the CDE; filters traffic at the edge
Controls the key lifecycle in HSMs or a KMS
Records and alerts on all CDE activity
Effect on compliance scope
Removes most application systems from PCI DSS scope
Required for any system that still handles card data
Limits audit scope to the CDE segment
Determines whether encryption actually protects data
Provides audit evidence and incident detection
Key requirements
PCI DSS Req. 3; EMVCo network tokenization
PCI DSS Req. 3, 4; GDPR Art. 32
PCI DSS Req. 1, 6.4, 11.4.5
PCI DSS Req. 3.6, 3.7
PCI DSS Req. 10, 11.5; DORA incident reporting; GDPR Art. 33
Taken together, these layers are the payment gateway security features auditors and enterprise clients look for first. They’re also where most payment gateway security problems originate when one layer is designed in isolation from the others.
Payment Gateway Security Testing
Payment gateway security testing confirms that the controls a gateway is built with actually hold up against attack, and it produces the evidence auditors ask for. PCI DSS sets the minimum: quarterly vulnerability scans and annual penetration tests, repeated after any significant change. A gateway also needs testing for risks that generic scans miss, such as payment business logic, tokenization boundaries and authentication flows.
Testing typically covers six areas:
- Vulnerability scanning. Internal and external scans at least every three months. External scans must be run by a PCI SSC Approved Scanning Vendor (ASV). Both are repeated after significant changes to the environment.
- Penetration testing. Internal and external tests at least every 12 months and after significant changes, following a documented methodology. For a gateway, the scope should explicitly include APIs, payment business logic, tokenization and 3DS2 flows, not only network infrastructure.
- Segmentation testing. This confirms that systems outside the cardholder data environment can’t reach it. PCI DSS requires this annually for merchants and every six months for service providers.
- Application security testing. Static and dynamic testing in the development pipeline, covering the OWASP Top 10 and the OWASP API Security Top 10. This catches payment gateway security issues such as broken object-level authorization or injection before they reach production.
- Payment page protection. Under PCI DSS v4.0.1, scripts on payment pages must be inventoried and authorized, and unauthorized changes to the page must be detected. This guards against card-skimming attacks that inject malicious JavaScript into checkout.
- Authentication and resilience testing. This covers 3DS2 challenge, frictionless, exemption and fallback flows, tested in the card scheme or provider sandbox before release. EU financial entities under DORA also need a digital operational resilience testing program, and some are required to run Threat-Led Penetration Testing (TLPT) at least every three years.
Payment Gateway Security Testing Checklist
The payment gateway security testing checklist below maps each test to its frequency and the requirement behind it. Use it to plan the testing calendar and check that each payment gateway security control has evidence ready for audit.
Test area | What to test | Frequency / trigger | Required by |
|---|---|---|---|
External vulnerability scan | Internet-facing systems in or connected to the CDE | Every 3 months and after significant changes; must be run by an ASV | PCI DSS Req. 11.3.2 |
Internal vulnerability scan | Internal systems in the CDE; high-risk and critical findings resolved and rescanned | Every 3 months and after significant changes | PCI DSS Req. 11.3.1 |
External penetration test | Perimeter, public APIs, payment endpoints | Every 12 months and after significant changes | PCI DSS Req. 11.4.3 |
Internal penetration test | CDE systems, lateral movement, privilege escalation | Every 12 months and after significant changes | PCI DSS Req. 11.4.2 |
Segmentation test | Isolation of the CDE from out-of-scope networks | Every 12 months; every 6 months for service providers | PCI DSS Req. 11.4.5, 11.4.6 |
API security test | Authentication, object-level authorization, rate limiting, input validation | Every release; included in pen test scope | PCI DSS Req. 6.2.4; OWASP API Security Top 10 |
Payment business logic | Amount tampering, replayed or duplicate transactions, refund abuse, currency manipulation | Every release affecting payment flows | PCI DSS Req. 6.2.4 |
Tokenization boundary | No full PAN in logs, databases, error messages or analytics; token vault isolated | Every release; annually in pen test scope | PCI DSS Req. 3 |
Payment page scripts | Inventory and authorization of scripts; tamper detection on the checkout page | Ongoing monitoring | PCI DSS Req. 6.4.3, 11.6.1 |
3DS2 / SCA flows | Challenge, frictionless, exemption and fallback paths | Before release; after any change to the authentication flow | PSD2 RTS on SCA; card scheme 3DS requirements |
Resilience and TLPT | Failover, recovery, threat-led testing of critical functions | Per testing program; TLPT at least every 3 years where required | DORA Arts. 24–26 |
Test area
External vulnerability scan
Internal vulnerability scan
External penetration test
Internal penetration test
Segmentation test
API security test
Payment business logic
Tokenization boundary
Payment page scripts
3DS2 / SCA flows
Resilience and TLPT
What to test
Internet-facing systems in or connected to the CDE
Internal systems in the CDE; high-risk and critical findings resolved and rescanned
Perimeter, public APIs, payment endpoints
CDE systems, lateral movement, privilege escalation
Isolation of the CDE from out-of-scope networks
Authentication, object-level authorization, rate limiting, input validation
Amount tampering, replayed or duplicate transactions, refund abuse, currency manipulation
No full PAN in logs, databases, error messages or analytics; token vault isolated
Inventory and authorization of scripts; tamper detection on the checkout page
Challenge, frictionless, exemption and fallback paths
Failover, recovery, threat-led testing of critical functions
Frequency / trigger
Every 3 months and after significant changes; must be run by an ASV
Every 3 months and after significant changes
Every 12 months and after significant changes
Every 12 months and after significant changes
Every 12 months; every 6 months for service providers
Every release; included in pen test scope
Every release affecting payment flows
Every release; annually in pen test scope
Ongoing monitoring
Before release; after any change to the authentication flow
Per testing program; TLPT at least every 3 years where required
Required by
PCI DSS Req. 11.3.2
PCI DSS Req. 11.3.1
PCI DSS Req. 11.4.3
PCI DSS Req. 11.4.2
PCI DSS Req. 11.4.5, 11.4.6
PCI DSS Req. 6.2.4; OWASP API Security Top 10
PCI DSS Req. 6.2.4
PCI DSS Req. 3
PCI DSS Req. 6.4.3, 11.6.1
PSD2 RTS on SCA; card scheme 3DS requirements
DORA Arts. 24–26
Compliance Scope by Payment Gateway Integration Type
The integration method is itself a compliance decision: the same payment gateway can land in a minimal-scope SAQ A or a full SAQ D assessment depending entirely on how card data flows through it.
Integration Type | PCI DSS SAQ | Scope | Key Compliance Implication |
|---|---|---|---|
Hosted Payment Page (redirect) | SAQ A | Minimal | Card data never touches your servers; the provider handles PCI DSS. Easiest compliance path. GDPR still applies to user data collected at checkout. |
iFrame / Embedded Form | SAQ A (provider-hosted iFrame) or SAQ A-EP (merchant-created form) | Minimal–Low | If the iFrame is fully hosted by a PCI DSS-compliant provider, the merchant is generally SAQ A-eligible, provided its site is protected against script-based attacks on the payment page. If the merchant’s own page creates or posts the payment form (direct post or JavaScript form), SAQ A-EP applies and the page’s script security is in scope. |
Server-to-Server API | SAQ D or Level 1 ROC | Full | Card data passes through your servers. Full PCI DSS scope applies: all 12 requirement domains. Highest compliance cost and complexity. Network tokenization can reduce scope post-integration. |
Mobile SDK Integration | SAQ A (if tokenized SDK) or SAQ D | Low or Full | Depends on the tokenization model. If SDK tokenizes before data reaches the app server: SAQ A equivalent. If the app handles raw PAN: full SAQ D scope. Clarify with the SDK provider before architecture design. |
Payment Orchestration Layer | SAQ D or Level 1 ROC | Full + multi-provider | Each provider in the orchestration layer must be independently PCI DSS compliant (AOC required). The orchestration layer itself is in full scope. Token portability between providers must be architecturally solved. |
Integration Type
Hosted Payment Page (redirect)
iFrame / Embedded Form
Server-to-Server API
Mobile SDK Integration
Payment Orchestration Layer
PCI DSS SAQ
SAQ A
SAQ A (provider-hosted iFrame) or SAQ A-EP (merchant-created form)
SAQ D or Level 1 ROC
SAQ A (if tokenized SDK) or SAQ D
SAQ D or Level 1 ROC
Scope
Minimal
Minimal–Low
Full
Low or Full
Full + multi-provider
Key Compliance Implication
Card data never touches your servers; the provider handles PCI DSS. Easiest compliance path. GDPR still applies to user data collected at checkout.
If the iFrame is fully hosted by a PCI DSS-compliant provider, the merchant is generally SAQ A-eligible, provided its site is protected against script-based attacks on the payment page. If the merchant’s own page creates or posts the payment form (direct post or JavaScript form), SAQ A-EP applies and the page’s script security is in scope.
Card data passes through your servers. Full PCI DSS scope applies: all 12 requirement domains. Highest compliance cost and complexity. Network tokenization can reduce scope post-integration.
Depends on the tokenization model. If SDK tokenizes before data reaches the app server: SAQ A equivalent. If the app handles raw PAN: full SAQ D scope. Clarify with the SDK provider before architecture design.
Each provider in the orchestration layer must be independently PCI DSS compliant (AOC required). The orchestration layer itself is in full scope. Token portability between providers must be architecturally solved.
SAQ type has to be determined before architecture is finalized, not discovered partway through the build. A team that starts a server-to-server API integration assuming SAQ A applies typically finds out mid-build that they’re actually in full SAQ D scope — at which point the fix isn’t a config change, it’s a rearchitecture.
See the PCI DSS compliance checklist for what each SAQ level actually requires to pass.
If you’re still choosing an integration method, our payment gateway integration services cover each option, and our payment gateway development team can help match the method to your compliance scope before the build starts.
Regional Compliance Requirements for Payment Gateways
Choosing the right payment gateway partner will help you navigate which of these obligations apply to your markets before they shape your architecture. Beyond PCI DSS, each market adds its own rules on authentication, personal data and operational resilience. The table below lists the frameworks that apply in the main regions and the gateway-specific obligations each one creates.
Region | Applicable Frameworks (beyond PCI DSS) | Key Gateway-Specific Obligations |
|---|---|---|
European Union / EEA | SCA/3DS2 required for CNP transactions unless an exemption applies; open banking API obligations for account-holding banks; DORA ICT risk management and TLPT for financial entities; GDPR data residency and breach notification | |
United Kingdom (post-Brexit) | UK GDPR and Data Protection Act 2018; UK Payment Services Regulations 2017; FCA oversight | SCA required under UK PSRs (mirroring PSD2 SCA); UK GDPR data residency separate from EU GDPR post-Brexit; FCA authorisation required for payment service provision |
United States | PCI DSS is primary framework; CCPA applies to California residents’ data; FinCEN AML/KYC for money transmission; Reg E for consumer dispute rights; no federal equivalent to GDPR | |
Australia | Privacy Act 1988 (Australian Privacy Principles); APRA CPS 234 (effective 1 July 2019); ePayments Code (ASIC, current version from 2 June 2022) | Privacy Act governs payment data handling; APRA CPS 234 for financial institutions on information security; ePayments Code covers consumer liability for unauthorised transactions |
Singapore / APAC | PDPA 2012 (Singapore); MAS TRM Guidelines (January 2021); local payment system acts by jurisdiction | MAS Technology Risk Management Guidelines mandate security controls for financial institutions; PDPA governs personal data; cross-border data transfer restrictions vary by country |
Region
European Union / EEA
United Kingdom (post-Brexit)
United States
Australia
Singapore / APAC
Applicable Frameworks (beyond PCI DSS)
PSD2 (2015/2366, from 13 January 2018), GDPR (2016/679, from 25 May 2018), DORA (2022/2554, from 17 January 2025)
UK GDPR and Data Protection Act 2018; UK Payment Services Regulations 2017; FCA oversight
No federal payments data law; CCPA (in effect from 1 January 2020, amended by CPRA from 1 January 2023); FinCEN AML requirements under the Bank Secrecy Act; Reg E (12 CFR Part 1005)
Privacy Act 1988 (Australian Privacy Principles); APRA CPS 234 (effective 1 July 2019); ePayments Code (ASIC, current version from 2 June 2022)
PDPA 2012 (Singapore); MAS TRM Guidelines (January 2021); local payment system acts by jurisdiction
Key Gateway-Specific Obligations
SCA/3DS2 required for CNP transactions unless an exemption applies; open banking API obligations for account-holding banks; DORA ICT risk management and TLPT for financial entities; GDPR data residency and breach notification
SCA required under UK PSRs (mirroring PSD2 SCA); UK GDPR data residency separate from EU GDPR post-Brexit; FCA authorisation required for payment service provision
PCI DSS is primary framework; CCPA applies to California residents’ data; FinCEN AML/KYC for money transmission; Reg E for consumer dispute rights; no federal equivalent to GDPR
Privacy Act governs payment data handling; APRA CPS 234 for financial institutions on information security; ePayments Code covers consumer liability for unauthorised transactions
MAS Technology Risk Management Guidelines mandate security controls for financial institutions; PDPA governs personal data; cross-border data transfer restrictions vary by country
Compliance Built In vs Compliance Retrofitted: The Cost Difference
Compliance decisions are architecture decisions, and the timing of those decisions determine what they cost.
Compliance Decision | Built-In (at architecture stage) | Retrofitted (post-launch) |
|---|---|---|
PCI DSS scope definition | SAQ type chosen before integration design; scope minimised by architecture (hosted page or tokenization from day one) | Scope discovered during first audit; architecture changes required to reduce scope; the API integration has to be rebuilt to add tokenization |
GDPR vs PCI DSS data separation | Personal data and transaction records stored in separate schemas with separate access controls and retention policies from initial data model design | Data is co-mingled; separating post-launch requires data migration, schema redesign, and re-testing: 6–10 weeks |
3DS2 / SCA implementation | 3DS2 designed into payment flow from the start; exemption logic, challenge flows, and liability shift handling all tested pre-launch | 3DS2 has to be added to a live payment flow, with a risk of breaking existing checkout conversion during rollout |
Audit logging infrastructure | Tamper-evident logging of all payment events from first transaction; retention policy configured; SIEM integration in place | Retrofitting audit logs to cover historical transactions: impossible for past transactions; future coverage requires infrastructure work: 2–4 weeks plus historical gap in PCI DSS compliance |
Compliance Decision
PCI DSS scope definition
GDPR vs PCI DSS data separation
3DS2 / SCA implementation
Audit logging infrastructure
Built-In (at architecture stage)
SAQ type chosen before integration design; scope minimised by architecture (hosted page or tokenization from day one)
Personal data and transaction records stored in separate schemas with separate access controls and retention policies from initial data model design
3DS2 designed into payment flow from the start; exemption logic, challenge flows, and liability shift handling all tested pre-launch
Tamper-evident logging of all payment events from first transaction; retention policy configured; SIEM integration in place
Retrofitted (post-launch)
Scope discovered during first audit; architecture changes required to reduce scope; the API integration has to be rebuilt to add tokenization
Data is co-mingled; separating post-launch requires data migration, schema redesign, and re-testing: 6–10 weeks
3DS2 has to be added to a live payment flow, with a risk of breaking existing checkout conversion during rollout
Retrofitting audit logs to cover historical transactions: impossible for past transactions; future coverage requires infrastructure work: 2–4 weeks plus historical gap in PCI DSS compliance
Compliance work done at the architecture stage is part of the build. Done after launch, the same work means rebuilding live systems, migrating production data and re-testing payment flows, with the regulatory exposure and reputational risk left open during the gap. The how to build a payment gateway guide breaks down where these decisions sit in the broader build sequence.
Key Takeaways
- Payment gateway compliance spans multiple overlapping frameworks: PCI DSS applies globally; PSD2, GDPR, and DORA apply in the EU; regional frameworks (UK PSRs, MAS TRM, APRA CPS 234) add jurisdiction-specific requirements.
- PCI DSS scope is determined by integration method: a hosted payment page qualifies for SAQ A (minimal scope), while a server-to-server API integration requires full SAQ D or Level 1 ROC assessment.
- The most common architectural conflict is GDPR’s right to erasure vs. transaction record retention required by AML, tax and card scheme rules — resolving this requires storing personal data and transaction records in separately governed schemas from the start.
- 3DS2 is the technical implementation of PSD2’s Strong Customer Authentication requirement; under card scheme rules, authenticated transactions also shift fraud liability from merchant to issuer.
- Compliance decided at the architecture stage is built in once; retrofitted after launch, it means rebuilding live integrations, migrating production data and re-testing payment flows while the compliance gap stays open.
- SOC 2 Type II and ISO 27001 are not regulatory requirements but are increasingly mandated by enterprise clients as contract conditions for payment processing partnerships.
- DORA (effective 17 January 2025) adds ICT risk management, incident reporting, and Threat-Led Penetration Testing requirements for EU financial entities — gateway providers serving regulated clients are affected through their clients’ contracts.
FAQ
What compliance standards apply to payment gateways?
PCI DSS applies to every gateway that stores, processes or transmits card data. In the EU and EEA, PSD2 adds strong customer authentication, GDPR governs personal data, and DORA sets ICT resilience requirements for financial entities. SOC 2 and ISO/IEC 27001 are not legal requirements, but enterprise clients often make them a contract condition. Card-present integrations also fall under PCI PIN and P2PE. Regional frameworks such as the UK PSRs, MAS TRM Guidelines and APRA CPS 234 add jurisdiction-specific obligations on top.
Is PCI DSS mandatory for all payment gateways?
PCI DSS isn’t a law in most jurisdictions. It’s a contractual requirement that card schemes such as Visa and Mastercard impose through acquiring banks, and non-compliance puts the ability to accept card payments at risk. A gateway is a service provider, so it validates at a service provider level based on annual transaction volume. The largest providers need a Report on Compliance from a Qualified Security Assessor (QSA), and smaller ones can use the service provider version of SAQ D. The merchants that integrate the gateway validate separately, and their integration method decides which self-assessment they can use.
How does the integration method affect PCI DSS scope?
The method decides whether card data ever touches the merchant’s systems:
- Hosted payment page (redirect): qualifies for SAQ A, the smallest scope.
- Fully provider-hosted iFrame: generally qualifies for SAQ A too, provided the merchant confirms its site is protected against script-based attacks on the payment page.
- SAQ A-EP applies when the merchant’s own page creates or posts the payment form, for example through a direct post or JavaScript form.
- Server-to-server API integration puts the merchant’s servers in full scope: SAQ D or a full Report on Compliance.
Choose the integration method against your compliance budget before architecture begins.
How do you test the security of a payment gateway?
Testing combines the scans and tests PCI DSS requires with checks specific to payments:
- Internal and external vulnerability scans every three months, with external scans run by an Approved Scanning Vendor.
- Internal and external penetration tests every 12 months and after significant changes.
- Segmentation tests: every 12 months, or every six months for service providers.
A gateway’s test scope should also cover:
- APIs and payment business logic (amount tampering, replayed transactions, refund abuse)
- tokenization boundaries
- payment page scripts
- 3DS2 challenge, frictionless and fallback flows
EU financial entities under DORA also need a resilience testing program, and some must run Threat-Led Penetration Testing. The testing checklist above maps each test to its frequency and requirement.
What is the cost of PCI DSS compliance for a payment gateway?
Cost is driven by scope more than by any single fee. The main drivers are:
- the validation type (self-assessment or a QSA-led Report on Compliance)
- the number of systems in the cardholder data environment
- quarterly ASV scans
- annual penetration tests
- remediation of findings
- security tooling such as logging, monitoring and key management
- staff time to maintain evidence between audits
DORA Threat-Led Penetration Testing adds a separate cost for in-scope EU financial entities. The biggest lever is architecture: tokenization, segmentation and the integration method decide how many systems fall into scope, and every system in scope multiplies the work.
What is the difference between PCI DSS and GDPR for payment gateways?
PCI DSS is an industry standard set by the card schemes and covers cardholder data. GDPR is EU law and covers all personal data of EU residents. Its fines reach up to €20 million or 4% of global turnover for the most serious violations, and up to €10 million or 2% for security failures. Both apply to EU-facing gateways at the same time. The practical conflict is with record retention: GDPR gives individuals a right to erasure, while AML laws, tax rules and card scheme dispute rules require transaction records to be kept for set periods. PCI DSS itself pushes the other way, requiring card data to be deleted once it is no longer needed. Separating personal data from transaction records at the data model stage resolves the conflict.
What does PSD2 require for payment gateways?
PSD2 requires strong customer authentication (SCA) for card-not-present payments in the EU and EEA, and 3DS2 is how card payments meet it. Exemptions exist for low-value payments under €30, within cumulative limits, and for transactions that pass transaction risk analysis. The liability shift that moves fraud losses to the issuer on authenticated transactions comes from card scheme rules, not from PSD2 itself. PSD2’s open banking API obligations apply to banks that hold payment accounts, not to card payment gateways.
What is DORA and does it apply to payment gateways?
DORA is an EU regulation that has applied since 17 January 2025. It covers financial entities, including payment and e-money institutions, and sets requirements for ICT risk management, incident reporting and resilience testing. A gateway operated by a licensed payment institution falls directly in scope. A technology provider serving EU financial entities is affected through its clients’ contracts, and direct EU oversight applies only to providers designated as critical.
What is network tokenization and how does it affect compliance?
Network tokenization (EMVCo) replaces a card’s PAN with a token issued by the card network, such as Visa Token Service or Mastercard Digital Enablement Service, rather than a gateway-generated token. Network tokens are portable across providers, reduce the number of systems that handle real card numbers, and support stored-credential transactions for subscriptions. They can also improve authorization rates, because the token stays valid when a card is reissued.