Payment gateway compliance is the process of meeting the technical, operational, and legal requirements set by industry standards and regional regulations that govern how payment card data is handled. The primary standard is PCI DSS, which applies globally to all entities that store, process, or transmit cardholder data. Additional requirements include PSD2 and GDPR in the EU, DORA for financial entities, and regional frameworks across APAC and the UK. Security controls mandated across these standards include TLS 1.2/1.3 encryption, tokenization, 3DS2 authentication, access control, audit logging, and annual penetration testing.
Deloitte reports that financial crime is growing in scale, speed, and sophistication, pushing compliance costs and operational strain. PCI DSS differs from PSD2, GDPR, SOC 2, ISO 27001, and DORA, each governs a different layer of a payment gateway’s architecture, with its own scope, audit cadence, and technical trigger.
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 | Payment Card Industry Data Security Standard | 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 | Payment service providers operating in the EU/EEA | Strong Customer Authentication (SCA) for online card payments; 3DS2 implementation; open banking API standards (Berlin Group); liability shift rules | EU national competent authorities; EBA guidelines |
GDPR | General Data Protection Regulation | Any entity processing personal data of EU/EEA residents | Lawful basis for payment data processing; data minimisation; right to erasure (conflicts with PCI DSS retention requirements — must be architecturally resolved); data residency; breach notification within 72 hours | EU national data protection authorities (DPAs) |
DORA | Digital Operational Resilience Act | Financial entities and ICT service providers in the EU from Jan 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 | 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 27001 | Information Security Management System | 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 | 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
PSD2
GDPR
DORA
SOC 2 Type II
ISO 27001
PCI PIN / P2PE
Full Name
Payment Card Industry Data Security Standard
Payment Services Directive 2
General Data Protection Regulation
Digital Operational Resilience Act
System and Organization Controls 2
Information Security Management System
PCI PIN Security / Point-to-Point Encryption
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 Jan 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; open banking API standards (Berlin Group); liability shift rules
Lawful basis for payment data processing; data minimisation; right to erasure (conflicts with PCI DSS retention requirements — 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; PCI DSS assumes transaction records are retained. 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 Req 4; GDPR Art. 32; ISO 27001 | PCI DSS non-compliance; GDPR fine up to 4% of global annual turnover for data breach involving card data |
Encryption at rest | AES-256 for stored cardholder data; encryption keys managed separately from encrypted data; key rotation policy documented | PCI DSS 4.0 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 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 PCA guidelines | Liability shift: merchant bears chargeback cost for fraud on non-SCA 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 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 Req 10; DORA incident reporting; GDPR breach notification | PCI DSS non-compliance; DORA incident reporting failure (72-hour notification window); GDPR breach notification failure |
Penetration testing | Annual external penetration test by qualified third party; payment-specific scope (API, business logic, 3DS2, tokenization); all critical/high findings remediated before next assessment | PCI DSS 4.0 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; patching SLA: critical within 1 month, high within 3 months; OWASP Top 10 coverage in application security testing | PCI DSS 4.0 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 external penetration test by qualified third party; payment-specific scope (API, business logic, 3DS2, tokenization); all critical/high findings remediated before next assessment
Quarterly ASV scans (PCI DSS); internal vulnerability scanning; patching SLA: critical within 1 month, high within 3 months; OWASP Top 10 coverage in application security testing
Mandated By
PCI DSS 4.0 Req 4; GDPR Art. 32; ISO 27001
PCI DSS 4.0 Req 3; ISO 27001; SOC 2
PCI DSS 4.0 Req 3 (scope reduction); card scheme network tokenization standards
PSD2 RTS on SCA; EU national PCA guidelines
PCI DSS 4.0 Req 7 & 8; SOC 2; DORA ICT risk framework
PCI DSS 4.0 Req 10; DORA incident reporting; GDPR breach notification
PCI DSS 4.0 Req 11; DORA TLPT (Threat-Led Penetration Testing) for in-scope financial entities
PCI DSS 4.0 Req 6 & 11; ISO 27001; SOC 2
Consequence of Non-Compliance
PCI DSS non-compliance; GDPR fine up to 4% of global annual turnover for data breach involving card data
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
Liability shift: merchant bears chargeback cost for fraud on non-SCA 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 (72-hour notification window); 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
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-EP | Low–Medium | Card data entered in the provider’s iFrame but your page loads it. Your server security affects the security of the iFrame environment. JavaScript 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-EP
SAQ D or Level 1 ROC
SAQ A (if tokenized SDK) or SAQ D
SAQ D or Level 1 ROC
Scope
Minimal
Low–Medium
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.
Card data entered in the provider’s iFrame but your page loads it. Your server security affects the security of the iFrame environment. JavaScript 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.
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.
Region | Applicable Frameworks (beyond PCI DSS) | Key Gateway-Specific Obligations |
|---|---|---|
European Union / EEA | PSD2, GDPR, DORA (from Jan 2025) | SCA/3DS2 required for all CNP transactions; open banking API compliance (Berlin Group); DORA ICT risk management and TLPT for financial entities; GDPR data residency and breach notification |
United Kingdom (post-Brexit) | UK GDPR, UK PSRs (Payment Services Regulations), 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 | No federal payments data law; state-level (CCPA in California); FinCEN AML requirements; Reg E (electronic fund transfers) | 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; ePayments Code | 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 (Singapore); MAS TRM Guidelines; 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, GDPR, DORA (from Jan 2025)
UK GDPR, UK PSRs (Payment Services Regulations), FCA oversight
No federal payments data law; state-level (CCPA in California); FinCEN AML requirements; Reg E (electronic fund transfers)
Privacy Act 1988 (Australian Privacy Principles); APRA CPS 234; ePayments Code
PDPA (Singapore); MAS TRM Guidelines; local payment system acts by jurisdiction
Key Gateway-Specific Obligations
SCA/3DS2 required for all CNP transactions; open banking API compliance (Berlin Group); 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; rebuilding API integration to add tokenization: 4–8 weeks |
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 | Adding 3DS2 to a live payment flow: 4–6 weeks; 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; rebuilding API integration to add tokenization: 4–8 weeks
Data is co-mingled; separating post-launch requires data migration, schema redesign, and re-testing: 6–10 weeks
Adding 3DS2 to a live payment flow: 4–6 weeks; 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 architecture decided at build time typically adds 15–25% to total gateway development cost. Retrofitting non-compliant architecture after launch typically matches or exceeds the cost of the original build — on top of the regulatory exposure and reputational risk sitting 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. PCI DSS’s transaction record retention requirements — 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; it also shifts fraud detection liability from merchant to issuer on authenticated transactions.
- Compliance architecture decided at build time costs 15–25% of total gateway development cost; retrofitting non-compliant architecture post-launch typically costs as much or more than the original build.
- 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 January 2025) adds ICT risk management, incident reporting, and Threat-Led Penetration Testing requirements for EU financial entities and their ICT service providers — including payment gateway developers serving regulated clients.
FAQ
What compliance standards apply to payment gateways?
Seven frameworks typically apply: PCI DSS globally for card data; PSD2, GDPR, and DORA in the EU/EEA, covering authentication, personal data, and ICT resilience; SOC 2 and ISO 27001 as enterprise contract requirements; and PCI PIN/P2PE for card-present integrations. Regional frameworks — UK PSRs, MAS TRM, APRA CPS 234 — add jurisdiction-specific obligations on top.
Is PCI DSS mandatory for all payment gateways?
PCI DSS isn’t a legal requirement in most jurisdictions — it’s a contractual requirement imposed by card schemes (Visa, Mastercard, Amex) through acquiring banks, and non-compliance risks losing the ability to accept card payments. The validation level required (SAQ vs. full ROC) depends on transaction volume and integration method, not jurisdiction.
What is the difference between PCI DSS and GDPR for payment gateways?
PCI DSS governs cardholder data security and is set by the card industry; GDPR governs all EU residents’ personal data and is law, with fines up to 4% of global turnover. Both apply simultaneously to EU-facing gateways, and the conflict between GDPR’s erasure right and PCI DSS’s retention requirement has to be resolved at the data model stage.
What does PSD2 require for payment gateways?
PSD2 mandates SCA for card-not-present transactions in the EU/EEA — 3DS2 is how that gets implemented. It also requires open banking API access and shifts fraud liability to the issuer once SCA clears a transaction. Low-value payments under €30, and some low-risk transactions, are exempt.
What is DORA and does it apply to payment gateways?
DORA is an EU regulation, effective January 2025, covering financial entities and their critical ICT service providers. A payment gateway serving EU banks, PSPs, or e-money institutions may itself fall into scope — bringing ICT risk management, incident reporting, and Threat-Led Penetration Testing (TLPT) requirements with it.
How does the integration method affect PCI DSS scope?
A hosted payment page qualifies for SAQ A (minimal scope, since card data never touches the merchant’s servers); an iFrame integration requires SAQ A-EP (the page’s JavaScript security is in scope); a server-to-server API integration requires SAQ D or a full Level 1 ROC. Choose integration method against compliance budget before architecture begins — see the PCI DSS Compliance Checklist.
What is the cost of PCI DSS compliance for a payment gateway?
Cost scales with scope. SAQ A: $500–2,000/year. SAQ D self-assessment: $3,000–10,000/year plus a $5,000–20,000 pentest. Level 1 QSA: $15,000–50,000+. DORA TLPT for in-scope EU entities: $30,000–100,000+. The bracket you land in gets decided by one thing — the integration method chosen at build time.
What is network tokenization and how does it affect compliance?
Network tokenization (EMVCo) replaces a card’s PAN with a network-issued token — Visa Token Service, Mastercard Digital Enablement Service — rather than a gateway-generated token, making it portable across providers. It reduces PCI DSS scope, tends to improve authorization rates, and supports secure stored-credential transactions for subscriptions.