Nearly every business is subject to payment laws and regulations—some determined by associations like the Payment Card Industry Security Standards Council.
Although these requirements were adopted to ensure fair business practices and consumer protections, navigating them can lead to sifting through pages and pages of dense language and confusing jargon. The potential consequences of non-compliance only make adherence more stressful.
With almost three and a half decades of experience in payment processing, we’re no strangers to how difficult compliance can be at Electronic Merchant Systems (EMS). So, we put together a quick guide covering the primary laws and regulations that affect most US merchants.
Contents:
- The PCI Data Security Standard
- The PCI Payment Application DSS
- Other Payment Processing Laws
- What’s Next?
The Payment Card Industry Data Security Standard (PCI DSS)
The most comprehensive regulatory framework that businesses need to comply with when processing card payments is the Payment Card Industry Data Security Standard (PCI DSS).
It was developed to safeguard credit card and cardholder data (CHD) and applies to any organization collecting, processing, storing, or transmitting this information.
You’re subject to PCI compliance if you handle credit card payments.
The framework itself is pretty extensive—stipulating 12 Requirements across six Goals and myriad sub-requirements, testing procedures, guidance, and recurring reporting processes.
Although PCI DSS is an industry regulation rather than a legal requirement, the entity that oversees it—the PCI Security Standards Council (SSC)—comprises the major credit card companies like Mastercard and Visa.
If you want to continue handling credit card payments through them, compliance is obligatory; there simply aren’t realistic alternatives to consider.
The PCI DSS’s 12 Requirements
The six Goals and 12 Requirements of the PCI DSS’ overarching regulatory framework are:
Goal 1 – Build and maintain a cardholder data environment comprised of a secure network and systems
- Requirement 1 – Enforce network security controls
- Requirement 2 – Securely configure all system components
Goal 2 – Protect account data
- Requirement 3 – Protect stored account data
- Requirement 4 – Protect CHD by implementing strong cryptography for any transmission over open, public networks
Goal 3 – Implement and maintain a vulnerability management program
- Requirement 5 – Implement cybersecurity defenses against malicious software
- Requirement 6 – Develop and maintain secure systems and software
Goal 4 – Implement strong access control measures
- Requirement 7 – Restrict access to system components and CHD according to individuals’ roles and responsibilities
- Requirement 8 – Implement identity and access management for all users and require authenticated access to system components
- Requirement 9 – Physical access to CHD must be restricted
Goal 5 – Perform regular network monitoring and testing
- Requirement 10 – All access to system components and CHD must be monitored and logged
- Requirement 11 – Perform regular systems and network security tests
Goal 6 – Implement and maintain an information security policy
- Requirement 12 – Develop and document organizational policies and programs overseeing information security
Within each Requirement are numerous sub-requirements (i.e., 1.1, 1.2) detailing the exact measures you’ll need to take (and document) to verify your PCI-DSS compliance.
PCI DSS Versions 3.2.1 vs. 4.0
Organizations handling credit card payments should note that version 4.0 of the PCI DSS was officially released in March 2022, superseding the previous version (v3.2.1).
However, the SCC provides an 18-month transition period to adjust to the changes. So, until September 2023, you can still send compliance reporting based on v3.2.1.
In addition to the v4.0 transition, future-dated requirements will not take effect until their specified date. Organizations will need to watch out for those deadlines to remain compliant.
PCI DSS Compliance Levels and Obligations
The volume of processed transactions generally determines the extent of your obligatory PCI DSS compliance reporting, split into four levels. Organizations categorized into each Level must follow the outlined annual reporting requirements.
Credit card companies may define these levels differently to complicate PCI compliance. Per Visa, Level differentiation is as follows:
Level 4 – Merchants that process under 20,000 Visa eCommerce transactions per year and all other merchants that process up to 1 million Visa transactions per year.
- Annual reporting obligation – Complete a Self-Assessment Questionnaire (SAQ)
Level 3 – Merchants that process between 20,000 and 1 million Visa eCommerce transactions per year.
- Annual reporting obligation – Complete an SAQ and file an Attestation of Compliance (AOC), which is completed by a third-party Qualified Security Assessor (QSA) approved by the PCI SSC
Level 2 – Merchants that process between 1 and 6 million Visa transactions per year across all channels (not just eCommerce).
- Annual reporting obligation – Complete an SAQ and file an AOC
Level 1 – Merchants that process more than 6 million transactions per year or are considered Global merchants that a Visa region has identified as Level 1.
- Annual reporting obligation – File a Report on Compliance (ROC)—which is completed by a QSA during an on-site assessment—and an AOC
The forms you or a QSA must complete and file are all available on the PCI SSC’s document library. Aside from the annual reporting obligations, organizations subject to the PCI DSS must also undergo quarterly vulnerability scanning assessments by an Approved Scanning Vendor.
Third-Party PCI DSS Compliance
If this is the first time you’ve encountered the PCI DSS, you shouldn’t necessarily worry about your organization being non-compliant.
The overwhelming majority of businesses that accept credit cards don’t have the bandwidth or resources to manage the framework’s implementation and ongoing reporting requirements.
Instead, most businesses can outsource the bulk of their PCI compliance obligations to third-party service providers (TPSPs). A payment processor like Electronic Merchant Systems would be considered a TSPS.
However, it’s important to note that partnering with PCI DSS compliant TPSP does not absolve liability or adherence requirements for organizations regardless of outsourced activities (e.g., POS systems, eCommerce payment gateways).
Regardless of what is outsourced, you must maintain a secure cardholder data environment (CDE) by the 12 Requirements above.
As a result, you’ll want to determine your remaining share of compliance obligations after partnering with a TSPS—and thoroughly assess all third-party vendors and service providers’ PCI DSS and PA-DSS compliance records.
The Payment Application Data Security Standard
Alongside the compliance behemoth that is the PCI DSS, the SSC also oversees the Payment Application Data Security Standard, which applies specifically to vendors of payment application software, like EMS. This framework contains 14 requirements and an implementation guide.
Given the much narrower range of organizations subject to the PA-DSS, most businesses will not have to concern themselves with the framework’s specific stipulations.
However, for the third-party PCI DSS compliance reasons stated above, you should always confirm whether your partner vendors and service providers subject to the PA-DSS have and maintain their compliance.
Other Payment Processing Laws
Aside from the PCI SSC’s primary two frameworks, merchants are also directly and tangentially subject to a few more laws and regulations. However, these generally do not have nearly as substantial an effect on operations as the PCI DSS and PA-DSS.
Merchants must also be aware of:
- 26 U.S. Code § 6050W from the IRS – 6050W requires merchants to report their total annual gross transactions across credit, debit, or co-branded cards to their merchant services provider, who will then report them to the IRS.
- The Durbin Amendment – Section 1075 of 2010’s Dodd-Frank law, also known as the Durbin Amendment, halved interchange fees (plus 5% of total purchase price) on debit cards, which are charged to merchants’ banks by cardholders’ banks for facilitating transactions.
However, despite the effort to alleviate a burden on merchants and consumers with lower interchange fees, the Durbin Amendment led to increased transaction and other account fees. - Nacha Operating Rules regulations – The National Automated Clearinghouse Association (Nacha) Operating Rules apply to eCommerce businesses that accept direct payments. Like the PCI DSS and PA-DSS, they generally pertain to cybersecurity controls implemented to protect customers’ information and include:
- Third-party sender roles and responsibilities
- Standardized micro-entry practices and formatting
- ACH Security Framework data protection requirements and supplemental requirements
Staying up-to-date on these laws and regulations and the PCI standards will help you avoid non-compliance penalties.
What’s Next?
Reducing your compliance burden depends on partnering with the right payment processors and other third-party partners.
As a payment processor ourselves, we’re held to strict requirements and have developed our platforms to help ensure your compliance with the maximum platform functionality available.
Have more Payment Processing Questions?
Click on the link below to check out our ultimate guide on How to Choose The Right Payment Processor for your business.
