The email came from a payment processor I'd been working with for six months. Subject line: "Urgent: Visa Compliance Action." My stomach dropped before I even opened it.
They'd been processing transactions for thousands of merchants, handling billions of dollars annually, and had somehow convinced themselves they were "just a technology company." Visa didn't see it that way. Neither did Mastercard. And neither did the PCI Security Standards Council.
The compliance action gave them 90 days to achieve full PCI DSS validation or lose their registration with the card brands. Ninety days to fix what should have been built correctly from day one.
That was in 2017. After fifteen years of working with payment processors, acquirers, and service providers, I can tell you this: understanding your role in the payment ecosystem isn't optional—it's existential.
The Payment Ecosystem: More Complex Than You Think
Most people think payment processing is simple: a customer swipes a card, money moves from their bank to the merchant's bank, done.
If only.
The reality involves a intricate dance between multiple entities, each with specific roles, responsibilities, and—crucially—specific PCI DSS compliance requirements. Get your role wrong, and you're either over-complying (expensive) or under-complying (catastrophic).
Let me show you how this actually works.
The Players in Every Transaction
I was presenting to a fintech startup last year when their CEO interrupted me: "Wait, how many entities are involved in a single card transaction?"
I drew this table on the whiteboard:
Entity | Role | PCI DSS Validation Level | Key Responsibility |
|---|---|---|---|
Cardholder | Person using the payment card | None | Protecting their card and PIN |
Merchant | Business accepting card payments | Levels 1-4 (based on volume) | Securing cardholder data at point of sale |
Acquirer (Acquiring Bank) | Bank that processes card payments for merchants | Level 1 (mandatory) | Onboarding compliant merchants, monitoring transactions |
Payment Processor | Entity that processes transactions on behalf of acquirer | Level 1 or 2 | Securely transmitting and processing payment data |
Card Brand | Visa, Mastercard, Amex, Discover | Sets rules | Establishing and enforcing payment security standards |
Issuer (Issuing Bank) | Bank that issues cards to cardholders | Level 1 (mandatory) | Fraud detection, cardholder authentication |
Payment Gateway | Technology that authorizes transactions | Level 1 or 2 | Securing data transmission between merchant and processor |
His eyes widened. "We're all of those except the cardholder and issuer."
Exactly. And that's where most companies get into trouble.
"In the payment ecosystem, your role determines your rules. Misidentify your role, and you're either breaking regulations or wasting money on compliance you don't need."
Acquirers: The Gatekeepers of Payment Security
Let me tell you about an acquiring bank I worked with in 2019. They'd been in business for 30 years, processing for about 4,500 merchants. Their compliance program? A disaster.
They treated PCI DSS like a merchant-level problem. They'd onboard merchants, hand them a self-assessment questionnaire, file it away, and call it done. No validation. No monitoring. No merchant education.
Then one of their merchants—a small restaurant chain—suffered a breach. 12,000 cards compromised. The breach investigation traced back through the payment chain, and guess who Visa held responsible?
The acquirer.
The fine: $250,000 from Visa, plus $180,000 from Mastercard. But worse? They had to implement a three-year remediation plan with quarterly audits. Every quarter, I watched them write six-figure checks to consultants and auditors.
What Acquirers Actually Do (And Why It Matters for PCI DSS)
As an acquirer, you're the bridge between merchants and the card brands. You have three critical responsibilities:
1. Merchant Onboarding and Validation
You can't just sign up any merchant and hope for the best. You're required to:
Verify each merchant's PCI DSS compliance status
Ensure merchants complete appropriate Self-Assessment Questionnaires (SAQs)
Validate that high-risk or high-volume merchants undergo external audits
Document everything (and I mean everything)
2. Ongoing Merchant Monitoring
Here's where most acquirers fail. They think compliance is a point-in-time check. It's not.
I worked with an acquirer who learned this the hard way. They'd validated a merchant's compliance at onboarding. Eighteen months later, that merchant got breached. The investigation revealed the merchant had completely abandoned their security practices six months after onboarding.
Who did Visa penalize? The acquirer, for failing to maintain ongoing monitoring.
3. Your Own PCI DSS Compliance
This is non-negotiable. As an acquirer, you're automatically a Level 1 Service Provider, which means:
Annual Report on Compliance (ROC) from a Qualified Security Assessor (QSA)
Quarterly network scans by an Approved Scanning Vendor (ASV)
Compliance with all 12 PCI DSS requirements
No exceptions, no shortcuts
The Acquirer's PCI DSS Compliance Breakdown
Here's what compliance actually looks like for acquirers:
PCI DSS Requirement | Acquirer-Specific Application | Common Pitfalls I've Seen |
|---|---|---|
Req 1: Firewalls | Segment merchant processing from internal networks | Flat networks exposing everything |
Req 2: Defaults | Change all default passwords on processing systems | Leaving vendor defaults on gateway configurations |
Req 3: Data Protection | Never store sensitive authentication data (CVV, PIN) | Logging systems inadvertently capturing CVV codes |
Req 4: Encryption | Encrypt cardholder data transmission across networks | Using deprecated TLS 1.0 for merchant connections |
Req 5: Anti-malware | Deploy anti-malware on all systems in payment flow | Excluding Linux systems (wrong assumption) |
Req 6: Secure Systems | Patch critical vulnerabilities within 30 days | 90+ day patch cycles due to "change management" |
Req 7: Access Control | Restrict data access based on business need-to-know | Administrators with unnecessary data access |
Req 8: User IDs | Unique IDs for all users accessing payment systems | Shared "admin" accounts for support teams |
Req 9: Physical Access | Secure data centers and offices with card data | Unlocked server rooms in co-location facilities |
Req 10: Monitoring | Log and monitor all access to payment systems | Log retention of only 30 days (90+ required) |
Req 11: Testing | Quarterly vulnerability scans, annual penetration tests | Skipping internal network pen testing |
Req 12: Policy | Maintain information security policy and program | Policies that nobody reads or follows |
"Every requirement in PCI DSS exists because someone, somewhere, got breached by not doing it. These aren't theoretical—they're lessons written in stolen card data."
Payment Processors: The Hidden Compliance Challenge
In 2020, I consulted for a payment processor that had grown from startup to unicorn in five years. Their technology was brilliant. Their compliance? Nearly nonexistent.
They'd convinced themselves they were just providing "technology services" to their acquirer partners. Therefore, they reasoned, compliance was someone else's problem.
This is the most dangerous misconception in the payment industry.
Processor vs. Acquirer: Understanding the Difference
The confusion is understandable. In many cases, processors and acquirers work so closely together that the lines blur. But from a PCI DSS perspective, the distinctions matter:
Aspect | Acquirer | Processor |
|---|---|---|
Card Brand Relationship | Direct registration with Visa, Mastercard, etc. | Works through acquirer's sponsorship |
Merchant Relationship | Direct contractual relationship | May have no direct merchant contact |
Settlement | Manages funds settlement | May handle transaction routing only |
PCI DSS Validation | Always Level 1 (mandatory ROC) | Level 1 or 2 depending on volume |
Primary Responsibility | Merchant compliance oversight | Secure transaction processing |
Risk Exposure | Direct liability for merchant breaches | Technical processing vulnerabilities |
When Processors Become Level 1 Service Providers
This catches many processors off-guard. They assume they're Level 2 until they suddenly aren't.
You're a Level 1 Service Provider if you process, store, or transmit more than 300,000 card transactions annually for any single card brand. Notice that's across all your clients combined.
I watched a processor discover this the hard way. They had 50 small acquirer clients, each processing modest volumes. Individually, they were all below the Level 1 threshold. Combined? They were processing over 15 million transactions annually.
Card brands didn't care about the "individually" part. They demanded a full Level 1 Report on Compliance. Cost to comply: $280,000 in the first year, plus ongoing annual costs of $120,000.
The Processor's Unique Compliance Challenges
Processors face challenges that acquirers don't:
Multi-Tenant Environments
You're processing for multiple acquirers and potentially thousands of merchants through a shared infrastructure. How do you ensure:
Data segregation between clients
Access control that prevents one client seeing another's data
Audit trails that accurately attribute actions to specific users
Incident response that contains breaches to single clients
I worked with a processor whose cloud infrastructure was so poorly segmented that one client's administrative user could theoretically access any other client's transaction data. Their QSA found this in about 15 minutes during the assessment. The remediation took nine months and cost over $2 million.
API Security
Modern processors expose APIs to acquirers, gateways, and sometimes merchants. Each API endpoint is a potential vulnerability.
In 2021, I investigated a breach where attackers exploited an API that had been deprecated but not disabled. It was still processing about 50 transactions per month—enough to stay under the radar but enough to provide an attack vector.
The API had no rate limiting, weak authentication, and logged sensitive authentication data. It was a PCI DSS violation on multiple fronts, and it cost the processor everything: reputation, clients, and ultimately the business.
Change Management in Fast-Moving Environments
Processors typically deploy code changes much faster than traditional financial institutions. I've seen processors pushing updates daily or even multiple times per day.
PCI DSS Requirement 6 demands secure development practices and change management. Here's what that means in practice:
Development Practice | PCI DSS Requirement | Real-World Implementation |
|---|---|---|
Code Review | All custom code reviewed before production | Peer review + automated SAST scanning |
Separation of Duties | Developers can't deploy to production | Separate deployment team or automated pipelines with approval gates |
Testing | Changes tested for security impact | Security test cases in CI/CD pipeline |
Change Authorization | All changes formally approved | Ticket-based approval system with audit trail |
Rollback Procedures | Ability to quickly reverse changes | Automated rollback capabilities tested quarterly |
Production Data | No live cardholder data in dev/test | Data masking or synthetic test data generation |
Third-Party Processors: The Service Provider Within a Service Provider
Here's where it gets really complicated. I once worked with a processor that used another processor for international transactions. They were a service provider, using another service provider, to provide services to acquirers, who served merchants.
The compliance question: Who's responsible for what?
The Service Provider Hierarchy
The PCI DSS has clear guidance, but implementation is messy:
Scenario | Primary Responsibility | Validation Requirement |
|---|---|---|
Acquirer processes in-house | Acquirer | Full ROC including processing environment |
Acquirer uses single processor | Both: Acquirer for oversight, Processor for technical controls | Acquirer ROC + Processor ROC or AOC |
Processor uses sub-processors | All parties in chain | Each entity validates their scope |
White-label processing | Depends on contract and technical implementation | Often requires combined assessment |
I spent three months helping a processor untangle their service provider relationships. They used:
A cloud provider (AWS) for infrastructure
A separate company for fraud detection
Another company for tokenization
Yet another for HSM (Hardware Security Module) management
Each relationship required documented due diligence, validation of PCI DSS compliance, and clear contractual terms about responsibilities.
"In payment processing, complexity is the enemy of security. Every additional service provider is another link in the chain—and chains break at their weakest link."
Gateway Providers: The Transaction Middleman
Payment gateways occupy an interesting position. They're the technology that connects merchant websites or point-of-sale systems to processors.
In 2018, I worked with a gateway provider who thought their only job was "passing data through." They didn't store anything, so they figured PCI DSS barely applied to them.
Wrong.
Gateway-Specific Compliance Requirements
If you're a gateway, you're still handling cardholder data, even if only in transit. Your requirements include:
Secure Transmission (Requirement 4)
This seems obvious, but I've seen gateways fail audits for:
Supporting TLS 1.0 or 1.1 (deprecated protocols)
Weak cipher suites
Missing certificate validation
Insecure fallback mechanisms
One gateway I audited had "temporary" support for unencrypted HTTP for testing purposes. That "temporary" support had been in production for two years. The QSA found it immediately.
Logging and Monitoring (Requirement 10)
Gateways must log:
All transaction attempts (successful and failed)
Administrative access to gateway systems
Configuration changes
Security events
But here's the catch: you can't log sensitive authentication data. No CVVs, no PINs, no full magnetic stripe data.
I've seen gateways fail audits because their logs contained:
Full credit card numbers (only first 6 and last 4 digits allowed)
CVV codes (never permitted)
Full magnetic stripe data (only for debugging, must be immediately deleted)
Tokenization (Optional but Recommended)
Smart gateways implement tokenization immediately upon receiving card data. This means:
Original card data is immediately replaced with a token
Only the tokenization system stores actual card data
Merchants and processors work with tokens, not real cards
Dramatically reduced PCI DSS scope for downstream systems
I worked with a gateway that implemented this in 2019. Their merchant customers saw their PCI DSS compliance costs drop by 60-80% because they no longer stored cardholder data. The gateway became a competitive advantage.
The Responsibility Matrix: Who's Accountable for What?
This is where most breaches happen—in the gaps between responsibilities.
After a major breach in 2020, I was brought in to help determine accountability. The breach had affected 200,000 cards processed through a chain of: Merchant → Gateway → Processor → Acquirer → Issuer.
Everyone pointed fingers. The merchant said the gateway was compromised. The gateway blamed the processor. The processor said the acquirer didn't properly validate the merchant. The acquirer claimed the merchant lied on their SAQ.
The investigation took four months. The truth? Everyone was partially at fault.
Defining Clear Responsibilities
Here's how to avoid that nightmare:
Function | Typical Responsibility | Validation Evidence |
|---|---|---|
Merchant POS Security | Merchant (with acquirer oversight) | SAQ completion, quarterly scans if applicable |
Data Transmission Security | Gateway + Processor | Encryption protocols, certificate management |
Transaction Processing | Processor | Secure coding, access controls, monitoring |
Merchant Compliance Validation | Acquirer | Documented validation program, quarterly reviews |
Cardholder Data Storage | Whoever stores it (NO ONE should if possible) | Data flow diagrams, storage justification |
Tokenization | Gateway or Processor (if implemented) | Tokenization system assessment |
Fraud Detection | Typically Acquirer + Issuer | Fraud monitoring tools, alert procedures |
Incident Response | All parties in their scope | Documented IR plans, tested annually |
Forensic Investigation | Breached entity + PFI (if breach occurs) | Forensic investigation reports |
The Shared Responsibility Model
I always tell clients: think of PCI DSS compliance like a relay race. Each runner is responsible for their leg, but everyone's working toward the same finish line.
Here's a real-world example from 2021:
A merchant got breached. The investigation revealed:
The merchant had never implemented basic POS security (merchant failure)
The acquirer never validated the merchant's PCI DSS compliance (acquirer failure)
The gateway was using deprecated encryption (gateway failure)
The processor's monitoring didn't detect the unusual activity patterns (processor failure)
Result?
Merchant: Out of business
Acquirer: $500,000 in fines, three-year remediation program
Gateway: Lost their largest client (the acquirer)
Processor: Reputation damage, 40% client churn
Everyone lost because nobody took complete ownership of their piece.
Due Diligence: Validating Your Service Providers
If you're an acquirer or processor using third-party services, you can't just trust that they're compliant. You need proof.
The Service Provider Validation Process
I've developed this checklist after watching too many companies skip due diligence:
Validation Step | What to Request | Red Flags |
|---|---|---|
1. PCI DSS Compliance Status | Current AOC (Attestation of Compliance) or ROC | Expired certificates, provisional compliance |
2. Scope Definition | Detailed scope documentation | Vague descriptions, unclear boundaries |
3. Vulnerability Management | Recent ASV scan results | Failed scans, overdue remediation |
4. Incident History | Past breach disclosures | Undisclosed breaches, repeated incidents |
5. Insurance Coverage | Cyber liability insurance details | Low coverage limits, exclusions |
6. SLA Terms | Service level agreements | No security SLAs, vague uptime guarantees |
7. Audit Rights | Contract terms allowing audits | Resistance to audits, restrictive terms |
8. Data Handling | Data flow diagrams, retention policies | Unnecessary data retention, unclear flows |
9. Incident Response | IR procedures, notification timelines | No documented procedures, slow notification |
10. Exit Strategy | Data deletion, service termination process | Data retention after termination |
The $2 Million Due Diligence Mistake
In 2019, I worked with an acquirer who skipped proper due diligence on a new processor partner. The processor provided an AOC, which the acquirer filed away without review.
Eighteen months later, a breach investigation revealed the processor's AOC was fraudulent. They'd never actually been PCI DSS compliant.
The acquirer faced:
$1.2 million in card brand fines
$800,000 in forensic investigation costs
$400,000 in legal fees
Loss of their largest merchant client
14 months of enhanced oversight from Visa
All because they didn't spend two hours properly reviewing a compliance document.
"Trust but verify' isn't paranoia in payment security—it's survival. Every service provider relationship is a potential liability if not properly validated."
Common Compliance Failures and How to Avoid Them
After fifteen years of assessments, audits, and breach investigations, I've seen the same mistakes repeatedly:
Failure #1: Scope Creep
A processor I worked with started as a simple payment gateway. Over five years, they added:
Fraud detection (now storing transaction history)
Recurring billing (now storing card data)
Payment analytics (now processing sensitive data)
Mobile SDK (now responsible for mobile app security)
Their PCI DSS scope grew from 15 systems to 187 systems. Their compliance costs increased 12x. Why? Because they never properly assessed the compliance impact of new features before launching them.
How to Avoid It:
Conduct compliance impact assessments for all new features
Update your data flow diagrams quarterly
Reassess your PCI DSS scope annually (minimum)
Involve your QSA in product planning discussions
Failure #2: The "We Don't Store It" Myth
I've lost count of how many times I've heard: "We don't store cardholder data, so PCI DSS doesn't really apply to us."
Then we look at:
Application logs (containing full card numbers)
Database backups (containing transaction data)
Error logs (containing CVV codes)
Email systems (containing payment information)
Development environments (containing production data copies)
Suddenly, they're storing data everywhere.
How to Avoid It:
Conduct thorough data discovery across all systems
Implement automated tools to detect cardholder data
Review logging configurations to ensure no sensitive data capture
Scan all environments (including dev/test) for cardholder data
Document everywhere cardholder data flows, even temporarily
Failure #3: Outsourcing Without Accountability
An acquirer I worked with outsourced their entire payment processing infrastructure to a third party. They thought this meant they'd outsourced PCI DSS compliance too.
Wrong.
When their processor got breached, Visa held the acquirer accountable. The acquirer's defense: "But we outsourced it!" Visa's response: "We don't care. You're the acquirer. You're responsible."
How to Avoid It:
You can outsource services, but not responsibility
Maintain documented oversight of service providers
Require annual compliance validation
Conduct your own security assessments of critical providers
Include security requirements in all service contracts
The Real Cost of Compliance vs. Non-Compliance
Let me share some numbers from companies I've worked with:
Acquirer Compliance Cost Analysis
Acquirer Size | Annual Transaction Volume | PCI DSS Compliance Cost | Non-Compliance Risk Exposure |
|---|---|---|---|
Small | < 1M transactions | $80,000 - $150,000 | $500,000+ in potential fines |
Medium | 1M - 10M transactions | $150,000 - $300,000 | $1M - $5M in potential fines |
Large | > 10M transactions | $300,000 - $800,000 | $5M - $25M+ in potential fines |
Processor Compliance Cost Analysis
Processor Type | Annual Transaction Volume | PCI DSS Compliance Cost | Technology Investment |
|---|---|---|---|
Gateway Only | < 5M transactions | $100,000 - $200,000 | $200,000 - $500,000 |
Full Processor | 5M - 50M transactions | $200,000 - $500,000 | $500,000 - $2M |
Large Processor | > 50M transactions | $500,000 - $1.5M | $2M - $10M |
These costs include:
QSA assessment fees
Internal security staff
Technology and tools
Remediation and improvements
Quarterly scanning
Training and awareness
Documentation and policy management
Building a Sustainable Compliance Program
The acquirers and processors that succeed don't treat PCI DSS as a once-a-year audit. They build it into their operational DNA.
The Compliance Calendar
Here's what a mature acquirer's compliance calendar looks like:
Activity | Frequency | Owner | Key Deliverable |
|---|---|---|---|
Merchant Validation | Quarterly | Compliance Team | Updated compliance register |
ASV Scans | Quarterly | Security Team | Clean scan reports |
Internal Vulnerability Scans | Monthly | Security Team | Remediation tracking |
Log Reviews | Daily (automated), Weekly (manual) | Security Operations | Incident detection |
Access Reviews | Quarterly | System Owners | Updated access lists |
Policy Review | Annually | Compliance Team | Updated policies |
Security Awareness Training | Annually + ongoing | HR/Compliance | Training completion records |
QSA Assessment | Annually | Compliance Team | ROC or AOC |
Internal Audit | Semi-annually | Internal Audit | Audit reports |
Penetration Testing | Annually + after significant changes | Security Team | Pen test reports |
Incident Response Drills | Quarterly | Security Operations | Exercise reports |
Business Continuity Testing | Semi-annually | Operations | BCP test results |
Making Compliance Easier Through Automation
A processor I worked with in 2022 automated 60% of their compliance activities:
Automated daily log analysis for suspicious activity
Automated quarterly access reviews
Automated vulnerability scanning and tracking
Automated compliance evidence collection
Automated policy acknowledgment tracking
Automated merchant compliance status checks
Result: Their compliance team shrank from 8 people to 3, while actually improving compliance quality. The automation cost $180,000 to implement but saved them $320,000 annually in labor costs.
Red Flags That You're Headed for Trouble
After working through countless breach investigations and failed audits, I can spot trouble from a mile away:
🚩 Your executive team views PCI DSS as "just a checkbox"
Compliance requires executive support and resources
If leadership doesn't care, neither will anyone else
🚩 You're making exceptions to policies "just this once"
One exception becomes two, becomes ten
Every exception is a potential breach vector
🚩 Your compliance program is entirely managed by one person
That person leaves, gets sick, or goes on vacation
Your entire program collapses
🚩 You can't produce evidence within 24 hours when asked
If you can't find evidence quickly, it doesn't exist
Auditors (and breach investigators) won't wait
🚩 Your last several audits had the same findings
Repeated findings indicate systemic problems
Eventually, the QSA will issue a failing report
🚩 Nobody knows what data you actually have and where it is
You can't protect what you don't know about
Scope definition becomes impossible
🚩 Security is always the reason you can't ship new features
Security should enable business, not block it
This indicates security isn't integrated into development
The Future of Acquirer and Processor Compliance
PCI DSS 4.0 is here, and it's bringing significant changes for acquirers and processors:
Key Changes Impacting Service Providers
Change Area | What's New | Implementation Deadline | Impact on Acquirers/Processors |
|---|---|---|---|
Customized Approach | Flexible control implementation if you meet objectives | March 2024 (effective) | Allows innovation while maintaining security outcomes |
Multi-Factor Authentication | Required for all access to CDE | March 2025 | Significant technology upgrade for most organizations |
Legacy Systems | Must document why systems can't meet requirements | March 2025 | Forces decisions on system modernization |
Phishing Protection | Technical and user awareness controls required | March 2025 | New tools and training programs needed |
Encryption Agility | Must plan for encryption algorithm changes | March 2025 | Requires cryptographic inventory and migration planning |
Targeted Risk Analysis | More flexibility in applying certain requirements | March 2025 | Opportunity to optimize control implementation |
I'm currently helping several processors prepare for these changes. The smart ones started in 2023. The ones scrambling started in 2025 and are now facing compressed timelines.
Your Action Plan: Next Steps
If you're an acquirer or processor reading this, here's what I recommend:
Within 30 Days:
Validate your current PCI DSS compliance status
Review all service provider relationships and verify their compliance
Conduct a gap analysis against PCI DSS 4.0 requirements
Document your complete cardholder data flow
Within 90 Days:
Implement a formal merchant validation program (acquirers)
Establish a compliance calendar with clear ownership
Deploy automated monitoring and alerting
Conduct security awareness training for all staff
Within 6 Months:
Complete any remediation from your last QSA assessment
Implement MFA across all environments
Update all policies and procedures
Conduct internal audit of PCI DSS controls
Within 12 Months:
Successfully complete annual QSA assessment
Achieve clean quarterly ASV scans
Demonstrate compliance with PCI DSS 4.0 requirements
Build compliance into product development lifecycle
Final Thoughts: Compliance as Competitive Advantage
I opened this article with a story about a processor facing a 90-day compliance action. They worked incredibly hard, spent over $500,000, and ultimately achieved compliance with 72 hours to spare.
Three years later, I caught up with their CISO. He told me something that stuck: "The compliance action was the best thing that ever happened to us. It forced us to build a proper security program. Now we win deals because of our security posture, not despite our compliance costs."
That's the mindset shift that separates successful acquirers and processors from those constantly fighting fires.
Compliance isn't a burden—it's the foundation of a trustworthy payment business. Your merchants trust you with their payment processing. Your merchants' customers trust you with their card data. That trust is built on the demonstrable security that PCI DSS compliance provides.
"In the payment industry, your reputation is your business. PCI DSS compliance doesn't just protect card data—it protects the trust that makes your business possible."
Whether you're an acquirer managing thousands of merchants or a processor handling millions of transactions, your role in the payment ecosystem comes with serious responsibilities. But with those responsibilities come opportunities—to build better systems, serve clients more effectively, and create lasting competitive advantages.
The question isn't whether you can afford PCI DSS compliance. It's whether you can afford not to be compliant.
Choose wisely. Your business depends on it.