What Is PCI Compliance for Car Rental Businesses?
PCI DSS is the Payment Card Industry Data Security Standard, maintained by the PCI Security Standards Council (PCI SSC), a body founded by the major card brands to set uniform rules for handling cardholder data. For a rental company, compliance is not optional or tied to size. If your branch swipes a card at pickup, your website takes a booking deposit, or your call center reads a card number over the phone, you are a merchant under PCI DSS and you owe your acquirer proof of compliance, typically an Attestation of Compliance (AOC) tied to the correct SAQ.
The rental industry has a quirk that catches operators off guard: a single rental touches payment data multiple times. There's the initial deposit at booking, a hold or swipe at the counter, and often a post-rental charge for tolls, fuel, or damage days after the car is returned. Each of those moments can sit in a different PCI scope, which is exactly why the SAQ selection process matters so much.
Which SAQ applies to rental payment flows?
Three self-assessment questionnaires cover the vast majority of rental operations, and picking the wrong one is one of the most common compliance failures the industry sees.
- SAQ A applies only when card-not-present processing is entirely outsourced to a PCI-compliant third party, meaning your booking page redirects to a payment processor's hosted page and your servers never touch, see, or store card data. This is the narrowest and simplest questionnaire to complete, but eligibility is strict.
- SAQ A-EP covers merchants whose website affects the security of the payment page, even without directly receiving card numbers. If your booking site hosts an embedded payment form, loads a payment iframe with custom scripts, or runs third-party analytics tags near the checkout flow, you likely fall here rather than SAQ A.
- SAQ D is the fallback for merchants that don't meet the criteria for other SAQs, including any rental company that stores electronic cardholder data on its own systems, accepts card data directly on a self-hosted page, or runs a branch point-of-sale terminal connected to internal networks that also touch other cardholder data. PCI SSC's own guidance says to complete SAQ D if you're uncertain which questionnaire fits, and to consult the entity requesting your AOC.
Mapping this to real rental channels usually looks like this: a branch counter running a standalone, PCI-listed terminal that connects directly to the processor (not your internal network) often qualifies for a simpler path, while that same terminal wired into your reservation system for auto-charge features can push you toward SAQ D. An online booking form that redirects fully to a hosted payment page supports SAQ A. That same booking form with an embedded card field, even a slick one, usually lands in A-EP territory. Phone and mail-order (MOTO) transactions typically fall under SAQ D unless captured through a validated virtual terminal solution. Post-rental charges, the toll and fuel adjustments processed days later, depend entirely on whether you're charging a stored token from your processor or holding raw card data yourself, which is illegal under PCI rules regardless of SAQ.
Before you commit to any questionnaire, get your third-party service provider's (TPSP) current AOC in writing, document exactly how each payment flow moves data, and confirm your selection with your acquirer. A 2025 PCI SSC clarification made clear that embedded scripts and booking plugins can shift your scope even when you never directly see a card number, so don't assume your website is out of scope just because a processor handles the actual charge.
Building Your PCI Compliance Checklist Step by Step
Compliance stops feeling abstract once you break it into tasks with owners and deadlines. Here's the sequence that works for most rental operations, regardless of fleet size.
- Inventory every payment channel and connected system. List branch POS terminals, the booking website, mobile checkout apps, phone/call center scripts, customer support tools that might log card numbers, and any spreadsheet still floating around with card details on it. Don't skip the spreadsheet. It's the most common skeleton in a rental company's compliance closet.
- Collect current AOCs from every provider. Your payment gateway, your booking platform, your call center software if it processes cards, all of them should have an Attestation of Compliance you can request and file. If a vendor can't produce one, that's a red flag worth escalating before you sign a renewal.
- Document scope-reduction claims in writing. If a provider tells you their integration keeps you in SAQ A territory, get that claim in an email or contract addendum. Verbal assurances don't hold up when your acquirer asks for evidence.
- Confirm SAQ eligibility with your acquirer and select the correct questionnaire. This is the step operators most often rush. PCI SSC's own merchant guidance walks through the full validation process, including identifying where PAN (primary account number) enters your systems.
- Schedule Approved Scanning Vendor (ASV) scans if your SAQ requires them. SAQ A-EP and SAQ D typically carry quarterly external vulnerability scan requirements. Mark these on a recurring calendar, not a sticky note.
- Remediate any gaps the scan or self-assessment uncovers. This might mean patching software, segmenting your network so the POS terminal isn't sitting next to your general office Wi-Fi, or retraining staff on card handling.
- Retain evidence continuously. Policies, scan results, training records, and terminal inspection logs all need a home. NIST's small business cybersecurity guidance recommends assigning this to a specific role rather than leaving it to whoever remembers.
- Set a recheck cadence. Annual reassessment is the PCI baseline, but a fast-growing rental company adding new booking channels or a new franchise location should revisit scope more often than once a year.
Pro Tip: Keep a single shared folder, digital or otherwise, where every AOC, scan report, and training certificate lives with a date stamp. When your acquirer asks for evidence during a routine review, the difference between a five-minute reply and a two-week scramble is almost always organization, not compliance effort.
Assigning a specific person or small team to own this checklist matters more than most operators expect. Compliance work that's "everyone's job" tends to become nobody's job the moment a busy rental season hits.
Redirects, Tokenization, and P2PE: What Actually Shrinks Your Scope
Not all scope-reduction tactics deliver equal value, and understanding the difference saves both money and audit headaches.
- Full redirects or fully outsourced hosted payment pages support SAQ A eligibility because your servers never touch card data. The tradeoff is design flexibility. You're relying on the processor's page, which can feel less seamless than a form built into your own booking flow.
- Embedded forms and scripts, even ones that look identical to a redirect from the customer's perspective, typically push you into SAQ A-EP because your website's code can influence the security of that payment field. This surprises a lot of operators who assumed "the processor handles the card number" meant they were automatically in the clear.
- Tokenization replaces the actual card number with a substitute value (a token) that's useless if stolen, and it's one of the more effective scope-reduction tools available to rental businesses handling repeat charges. But tokenization doesn't mean your systems disappear from PCI scope entirely. The token vault and any system that can map a token back to a real card number remain in-scope, and tokenization never permits storing CVV under any circumstance.
- Point-to-point encryption (P2PE) encrypts card data at the moment of swipe or dip, before it ever reaches your systems in readable form. Here's the catch worth flagging: only solutions officially validated and listed by PCI SSC deliver the dramatic validation simplification the industry talks about. A non-listed encryption solution that claims "P2PE-like" security may still require a full assessment, so verify the exact terminal, software, and processor combination against PCI SSC's official listing before assuming you've simplified anything.
For rental-specific scenarios like deposits and post-rental charges, the safest workflow relies on processor-managed tokens rather than stored card numbers. When a customer returns a car with a toll violation three weeks later, you should be charging a token your processor recognizes, never a card number sitting in your reservation notes. This single practice, token-based authorization instead of local storage, closes one of the most common vulnerability paths in the rental business model.
One detail that trips up multi-location operators: mapping every booking path separately matters because a website redirect, a phone reservation, a branch POS swipe, and a mobile checkout app can each generate different scope even within the same company. Treating them as one uniform "payment process" during a self-assessment is how gaps slip through.
Data You Can Never Store, and the Mistakes That Cause Breaches
Some rules in PCI DSS aren't about reducing risk, they're absolute prohibitions, and violating them creates liability regardless of how good the rest of your security setup looks.
You may never store the CVV/CVC/CID code, full magnetic-stripe or chip track data, or the PIN after a transaction is authorized. PCI SSC's tokenization guidance is unambiguous that sensitive authentication data must never persist past authorization, no matter how convenient it might seem to keep it "just in case" a customer disputes a charge later.
The trouble is that this data ends up stored by accident far more often than on purpose. Common accidental storage vectors in rental businesses include:
- Support tickets or chat logs where an agent copies a customer's full card number to "verify" a booking.
- Exported reservation reports that include payment fields nobody scrubbed before saving to a shared drive.
- Screenshots taken during troubleshooting that capture a payment screen mid-transaction.
- Recorded phone calls where a customer reads their card number aloud and the recording is stored without redaction.
Preventive controls address most of this without much operational disruption. Set a logging policy that explicitly bans full card numbers or CVVs in any support ticket, email, or note field. Use automated redaction on call recordings so numbers are masked the moment they're spoken. Restrict access to payment systems on a need-to-know basis rather than giving every front-desk employee visibility into full transaction records. Train staff at onboarding and annually on what "never write this down" actually means in practice.
Pro Tip: Run a quarterly search across your shared drives and support platform for strings of 13 to 16 digits. It sounds crude, but it catches accidental card-number storage far more reliably than relying on staff memory alone.
How Nomora Helps Rental Operators Reduce PCI Scope
Think of your rental management platform as the central nervous system of the business, and payment security has to run through that same system rather than living in a patchwork of separate tools. Nomora is built with that principle in mind.
Nomora supports integrated payment gateways with tokenization built into the payment flow, which reduces how often raw card numbers pass through your own systems when configured correctly. That matters directly for the SAQ eligibility questions covered above.
Beyond the payment mechanics, Nomora helps with the organizational side of compliance that trips up so many operators:
- Centralizes your payment-channel inventory across branches, so you're not chasing down which location uses which terminal.
- Provides a single place to store provider attestations and compliance documentation, cutting the scramble during an acquirer review.
- Standardizes secure booking and payment flows across every location through consistent system integrations, including GPS tracking and payment gateway connections.
- Gets new locations operational in 24 to 48 hours, which means new branches inherit your existing security configuration instead of starting from a blank slate.
None of this replaces your own responsibility for choosing the right SAQ or maintaining evidence, but it removes a meaningful amount of the manual tracking that makes PCI compliance feel harder than it needs to be for a growing rental fleet.
What a PCI Audit Actually Looks Like for a Rental Company
A PCI "audit" for most rental businesses is a self-assessment, not an on-site inspection by an outside firm, unless your transaction volume or risk profile requires a Qualified Security Assessor (QSA). The process starts with your acquirer or the payment brand specifying which SAQ applies, then you work through that document's control checklist, gathering evidence as you go.
The documentation an assessor or acquirer typically wants includes your network diagram showing how payment systems connect (or don't connect) to the rest of your infrastructure, current AOCs from every third-party payment provider, quarterly ASV scan reports if your SAQ requires them, written information security policies, staff training records, and logs showing access controls on any system that touches cardholder data.
For a multi-location rental company, the audit process gets more complex because evidence needs to reflect every branch, not just headquarters. A franchise model in particular needs to confirm that each location's POS terminal setup matches the assumptions in the parent company's SAQ, since a single non-compliant branch can undermine the whole company's attestation.
The completed SAQ becomes part of your AOC, which you submit to your acquirer, typically on an annual cycle. Keep in mind that "passing" isn't a one-time event. Evidence needs ongoing maintenance, because an acquirer or card brand can request updated documentation at any point, not just at renewal time.
Balancing Payment Security With a Smooth Rental Experience
Compliance measures can either disappear into the background of a good customer experience or create visible friction, and the difference usually comes down to implementation choices rather than the requirements themselves.
A well-configured hosted payment page or tokenized checkout adds no noticeable delay for the customer booking a car online. They enter their card details once, and everything after that (deposits, post-rental charges, damage adjustments) runs on a token rather than requiring them to re-enter a card number every time. Done poorly, though, redirect-based payment flows can feel clunky if the hosted page doesn't match your booking site's branding, and staff who over-verify card details at the counter out of caution can slow down what should be a quick pickup.
Operationally, the biggest workflow shift is usually training staff to stop writing anything down. Front-desk employees accustomed to jotting a card number on a rental agreement or reading it back to a customer for confirmation need new habits, ones built around the terminal or system doing the verification instead of a human transcribing sensitive numbers. This isn't just a compliance requirement, it also reduces disputes, since a token tied to a specific transaction is far easier to trace than a handwritten note.
The upside for well-implemented compliance is real: faster checkout at pickup, fewer payment disputes because charges trace cleanly to authorized tokens, and less staff anxiety about handling sensitive data incorrectly.
Why In-Person and Online Payments Create Different Rental Challenges
Car rental sits in an unusual spot compared to most retail businesses because it routinely mixes card-present and card-not-present transactions within a single customer relationship, often within the same rental.
The in-person challenge centers on branch POS terminals and how they connect to the rest of your network. A standalone terminal that talks directly to the processor keeps scope narrow. The same terminal wired into a shared network with your reservation system, printer, and office Wi-Fi expands scope considerably, since a vulnerability anywhere on that network could theoretically expose cardholder data. Staff training matters just as much as the hardware: a rushed counter employee jotting a card number to "confirm" a reservation undoes a well-configured terminal setup instantly.
Online payments carry a different risk profile. Booking sites often integrate third-party plugins, live chat widgets, and marketing scripts, any of which can create SAQ A-EP exposure without anyone realizing it. The best practice here is a periodic script audit, reviewing everything that loads on your payment page and confirming each element's necessity and security posture.
The hardest challenge is the handoff between the two: a customer books online, pays a deposit through one flow, then finishes payment or racks up post-rental charges in person or by phone. Each transition point is a place where card data could move outside its intended, secured channel. Standardizing on tokenized authorization across both channels, so the online deposit and the in-branch charge reference the same secure token rather than separate card entries, closes that gap more reliably than any single technical fix.
Practitioner Take: Focus on Scope Mapping, Not Certificates
The biggest misconception operators carry into PCI compliance is treating it as a document to obtain rather than a set of controls to maintain. A completed SAQ sitting in a folder means nothing if a new booking plugin quietly changed your scope six months later.
Outsourcing payment capture to a processor reduces your technical burden, but it never removes accountability. You still need a signed agreement with every provider and a habit of checking their compliance status annually, not just at onboarding. The operators who avoid trouble are the ones obsessed with mapping where card data actually flows, especially through booking scripts and staff habits that never make it into official documentation.
Bring in a Qualified Security Assessor when you're storing electronic cardholder data directly, running custom-built reservation software, or recovering from a repeated incident. For most single-location and mid-size rental operations working through SAQ A or A-EP with standard integrations, internal remediation guided by your acquirer covers the ground fine.
— Dizzy
Get Your Payment Setup Audit-Ready With Nomora
Nomora gives rental operators a faster route to a defensible PCI posture than stitching together a booking site, a separate payment gateway, and a spreadsheet of provider AOCs. Integrated payment processing with tokenization support means fewer systems touch raw card data in the first place, and centralized provider documentation means you're not hunting for an AOC the week before an acquirer review.
Getting started doesn't require a lengthy migration. Nomora's onboarding typically has new accounts operational in 24 to 48 hours, with plans running from the Starter tier at €45 per month up through Business and Fleet pricing scaled per vehicle. If your rental business is ready to centralize payment channels and cut down on manual compliance tracking, visit Nomora's pricing page to compare plans or request a demo suited to your fleet size.
Where to Verify These PCI Rules Yourself
Every claim in this guide traces back to primary PCI SSC documentation, and rental operators making final SAQ decisions should read the source documents directly rather than relying on secondhand summaries.
- SAQ A for PCI DSS v4.0, SAQ D for Merchants, and the related A-EP questionnaire lay out exact eligibility tests and testing procedures for each path.
- PCI SSC's tokenization information supplement explains what tokenization does and doesn't remove from scope.
- PCI SSC's non-listed encryption assessment guidance clarifies why only validated P2PE solutions simplify your validation burden.
These documents matter for rental operators specifically because eligibility hinges on exact wording, and a misread criterion is how companies end up completing the wrong questionnaire entirely.
Sources
FAQ
How serious is PCI compliance for a rental business?
It's serious in both financial and reputational terms. Non-compliance can result in fines from your acquirer, increased transaction fees, and liability if a breach occurs, and a single incident involving stored card data can trigger notification obligations and lasting damage to customer trust.
Is PCI compliance legally required?
PCI DSS itself is a card brand and industry requirement enforced through your merchant agreement with your acquirer, not a government statute. That said, many states have data breach notification laws that apply once cardholder data is exposed, so the practical effect of ignoring PCI requirements can still carry legal consequences.
What disqualifies a rental company from using SAQ A?
Any system on your side that affects the payment page's security, including embedded card fields, custom checkout scripts, or third-party widgets near the payment flow, disqualifies you from SAQ A and typically moves you to SAQ A-EP. Storing any electronic cardholder data on your own systems moves you further, to SAQ D.
Does a rental company need to check for a customer's DUI history separately from payment compliance?
Yes, driver eligibility checks like DUI history are a separate operational process from PCI compliance and typically run through your reservation or identity verification system rather than your payment processor. The two processes often happen close together at pickup, but they address entirely different risks: one screens the driver, the other protects the card transaction.
A platform that centralizes payment channels, stores provider attestations, and supports tokenization, like Nomora, reduces the manual tracking that makes compliance harder for multi-location rental operators. It doesn't replace the need to confirm your own SAQ eligibility with your acquirer, but it removes a lot of the scattered documentation work along the way.
Recommended
