Home › PCI compliance by business › Contractors and home service pros

PCI compliance for contractors and home service businesses

Short answer. Contractors and home service businesses do not file one PCI form for the whole company: each way you take cards is a separate payment method with its own Self-Assessment Questionnaire (SAQ). A pay-online link on your invoices is usually SAQ A, card numbers taken by phone and typed into your provider's virtual terminal are usually SAQ C-VT, and a card reader on your phone depends on whether your provider's solution is PCI-validated. Taking cards several ways does not mean you need SAQ D.

If you fix, clean, build, haul or repair, you probably take cards more than one way: a link on the invoice, a reader on a phone at the job, a card number read out over the phone, maybe a saved card for a maintenance plan. PCI DSS, the card industry's security standard, applies to every business that accepts cards, and most small businesses show they meet it each year by completing a Self-Assessment Questionnaire (SAQ) for their bank or payment processor.

Each of those ways is assessed on its own, and most are short questionnaires because your payment provider does the heavy lifting. The setups that make PCI hard, and risky, are the ones where card numbers end up on job tickets, in text messages or in your own files.

How contractors and home service pros usually take cards, and the SAQ for each

Each way you take cards is its own payment method, and each one gets its own SAQ. Most businesses have two or three.

Payment method	Usually	Why
Pay-online link on invoices and estimates You email or text an invoice, estimate or deposit request from your invoicing or field-service software, and the customer clicks Pay and enters their card on the payment provider's page.	SAQ A SAQ A, when the payment page comes entirely from your provider	The customer types their card into your provider's page and nothing you own receives the card number. PCI SSC FAQ 1588 gives emailing customers a link to a provider's website to pay as an example of fully outsourcing payment. Watch out: If the customer replies with their card number instead, or your office types it in for them, the card number is now in your email or on your computer, and that is a different payment method.
Card reader or tap-to-pay on a phone or tablet A tech's phone or tablet running your payment or field-service app, with a small card reader paired to it, or the phone itself accepting a tap at the customer's door.	SAQ SPoC / SAQ P2PE SAQ SPoC if your provider's solution is a PCI-listed SPoC solution, SAQ P2PE if the reader is part of a PCI-listed P2PE solution; otherwise ask your provider which SAQ their solution supports	The SAQ depends on how your provider's solution was validated by PCI SSC, not on the phone. SAQ SPoC is only for solutions on PCI SSC's list of validated SPoC solutions, where the card is read by a secure reader paired with the phone. Watch out: Tap-to-pay on the phone alone falls under PCI SSC's CPoC or newer MPoC standard, and neither has an SAQ named after it. And a card number typed into the app by hand is not a card read by the reader; ask your provider how it treats manual entry.
Card numbers taken over the phone A customer calls the office to pay a balance or a deposit, and the office manager types the card number straight into the provider's virtual terminal, a payment page in a web browser.	SAQ C-VT SAQ C-VT, if you key one payment at a time into a provider-hosted virtual terminal and store nothing	The office computer handles the card number while someone types it, so that computer is part of the payment. SAQ C-VT is for keying single transactions by hand into a virtual terminal hosted by a PCI DSS compliant provider, on a computer kept apart from your other systems, with no card reader attached and nothing that saves card numbers. Watch out: Writing the number down to key in later, letting the browser save it, or having customers text or email it takes you outside SAQ C-VT. Texting the customer a pay link instead makes that payment SAQ A.
Card terminal at your shop or office counter An auto repair shop, showroom or office where customers pay at the counter on a terminal from your processor, sometimes connected to your shop-management software.	SAQ B-IP / SAQ P2PE / SAQ C SAQ B-IP for a standalone internet-connected terminal, SAQ P2PE if it is a PCI-listed P2PE solution, SAQ C if card data runs through your shop software or POS	What matters is how the terminal connects. A terminal that talks only to the processor keeps your computers out of it; one that passes card data through your software brings that software and your network into scope. Watch out: A terminal on the same open network as the office computers or the customer Wi-Fi no longer counts as standalone.
Saved cards for service plans, deposits and final balances A maintenance plan billed every month, or a deposit taken when the job is booked and the balance charged to the same card when the work is done.	SAQ A / SAQ D Covered by the payment method that captured the card: usually SAQ A when the customer saves it on your provider's page; SAQ D if you keep card numbers yourself	When your provider stores the card and you only see a token (a stand-in reference) and the last four digits, your systems hold no card numbers. Full card numbers kept in a spreadsheet, customer record or job file are electronic storage, which only SAQ D covers. Watch out: Never keep the three- or four-digit security code to charge later. PCI DSS forbids storing it after the payment is approved, even on paper and even with the customer's permission.

Find out which SAQ fits each way you take payments, free

Describe how you take payments in your own words. We'll tell you which SAQ fits each one, free, before you pay anything.

One SAQ per payment method, and why that is not SAQ D

An SAQ is a checklist written for one kind of payment setup. We treat each way you take cards as its own payment method and match it to the SAQ written for that setup. A plumbing company with invoice pay links, phone readers and phone payments usually ends up with three short questionnaires, for example SAQ A, the SAQ for its reader and SAQ C-VT, not one long one.

SAQ D, the full questionnaire, is for card numbers that reach your own systems, for example a website that collects them on your server or card numbers kept in your files, or for a setup that fits no shorter SAQ. Taking cards several ways does not by itself put you there. Your acquirer, the bank behind your card account, often reached through your processor, has the final say on which SAQs you file.

Card readers on phones: SPoC, CPoC, MPoC and tap to pay

Most field techs take cards on a phone or tablet. PCI SSC, the council that writes the PCI standards, has three standards for this: SPoC (a small secure card reader paired with a phone, with any PIN typed on the phone's screen), CPoC (contactless tap on the phone, no PIN) and MPoC (Mobile Payments on COTS, which covers both tap and PIN on the same phone). COTS just means commercial off-the-shelf: an ordinary phone or tablet.

Only one SAQ is named after these: SAQ SPoC, which applies when your provider's solution is on PCI SSC's list of validated SPoC solutions and you follow the provider's SPoC user guide. Some card readers are instead part of a PCI-listed point-to-point encryption (P2PE) solution, which points to SAQ P2PE.

In May 2026 PCI SSC announced that it will accept no new SPoC or CPoC submissions after October 31, 2026, and pointed vendors toward MPoC. Solutions already listed stay valid until their listing expires. Because PCI SSC has not published an SAQ named for MPoC or tap to pay, ask your provider which SAQ their solution supports, get the answer in writing, and confirm it with your acquirer.

Is your mobile solution listed by PCI SSC as a validated SPoC, MPoC or P2PE solution, and under what name?
Which SAQ do you tell merchants to use with it?
What happens, for PCI purposes, when a tech types a card number into the app instead of tapping or inserting the card?
Is there a user guide or instruction manual we must follow, and where is it?

Job tickets, texts and emails: where card numbers leak

The most common PCI problem in home services is not the technology. It is a card number written on a work order, a sticky note in the truck, a photo of a card in the job file, or a customer texting their card to the tech. Each of those is card data your business now holds.

PCI DSS does not ban receiving card numbers by email, text or chat, but PCI SSC says any channel used that way must be protected under all applicable PCI DSS requirements, which pulls your phones and email into scope. Card numbers received electronically also break the conditions for SAQ A and SAQ C-VT. The simple answer is not to use those channels for cards.

If a customer sends a card number anyway, PCI SSC FAQ 1157 says to act quickly: do not reply to the message with the number in it, delete it securely, finish the payment another way, and tell customers how to pay safely next time.

Send a pay link instead of asking for the card number.
Have the office key phone payments straight into the virtual terminal while the customer is on the line, rather than writing the number down.
Never photograph cards or put card numbers in job notes, photos or the field-service app.
If a card number does end up on paper, keep it locked away and cross-cut shred it as soon as the payment is done.

Deposits, service plans and saved cards

Deposits and final balances are not a separate payment method. They go through whichever way you charge them: a pay link, a reader or the virtual terminal.

For recurring service plans, let your payment provider save the card. Many invoicing and field-service tools that offer saved cards keep the card number with the payment provider and show you only a token and the last four digits. Ask your provider to confirm that, and make sure nobody keeps a spreadsheet or customer file of card numbers just in case.

The security code is different from the card number. You may ask for it to approve a payment, but PCI DSS Requirement 3.3.1.2 forbids keeping it afterwards, even encrypted, and PCI SSC says a customer's permission does not change that.

Keeping payment phones and the office computer safe

Your SAQs will ask practical questions about the devices that touch payments: who can use them, whether they are kept updated, and whether they are kept apart from everything else.

Use company-managed phones or tablets for payments, with a passcode, automatic updates and only the apps you need.
Check card readers for signs of tampering, and keep them with the tech or locked in the truck.
Key phone payments on one computer, kept apart from your other systems, with no card reader plugged in.
Give each person their own login to the payment app and virtual terminal, and remove it when they leave.
Show techs and office staff what to do when a customer offers a card number by text, email or photo.

Your checklist

List every way you take cards: invoice links, readers in the field, phone payments, a counter terminal and saved cards.
For pay links, confirm the payment page is your provider's and that nobody types cards in on customers' behalf.
Ask your mobile payment provider, in writing, whether its solution is PCI-listed (SPoC, MPoC or P2PE) and which SAQ it supports.
Take phone payments straight into your provider's virtual terminal, one at a time, without writing the card number down.
Stop accepting card numbers by text, email or photo; send a pay link instead, and securely delete any you receive.
Search job tickets, trucks, the office and your software notes for written card numbers, then shred or securely delete them.
Let your provider store cards for service plans and deposits, and never keep security codes.
Ask your processor which SAQs they expect, and complete one for each payment method every year.

Common questions

Do plumbers, electricians and other contractors need to be PCI compliant?

Yes, if you accept credit or debit cards. Visa says PCI DSS compliance is required of all entities that store, process or transmit its cardholder data, and your acquirer is responsible for making sure you validate it, which is why your processor asks for an SAQ. For most small contractors that means a short SAQ for each way you take cards, once a year.

Which SAQ do I need if customers pay my invoices online?

Usually SAQ A for that payment method, as long as the customer enters their card on your provider's payment page and nothing you own receives the card number. If you also take cards in the field or by phone, those payment methods need their own SAQs.

Is the card reader on my phone SAQ SPoC?

Only if your provider's solution is listed by PCI SSC as a validated SPoC solution. Some readers are part of a PCI-listed P2PE solution instead, which points to SAQ P2PE, and tap-to-pay on the phone alone falls under PCI SSC's CPoC or MPoC standards, neither of which has an SAQ named after it. Ask your provider which SAQ their solution supports and confirm it with your acquirer.

Can a customer text me their card number?

Avoid it. PCI SSC says any channel used to receive card numbers, including text and email, must be protected under PCI DSS, and receiving cards that way takes you out of the shorter SAQs. Send a pay link instead, and if a number arrives anyway, do not reply to it, delete it and finish the payment another way.

Is it OK to write the card number on the work order and run it later?

It is best not to. The shorter SAQs allow card numbers on paper only if the paper is kept secure, never scanned or emailed, and destroyed when no longer needed, and the security code must never be kept after the payment is approved. Charging the card while the customer is with you, or sending a pay link, avoids the problem.

We take a deposit by phone and the balance by pay link. How many SAQs is that?

Two: usually SAQ C-VT for the phone payments typed into your virtual terminal, if you meet its conditions, and SAQ A for the pay link. Each payment method gets its own SAQ, which is usually less work than one large questionnaire.

Do I need SAQ D because I take cards several ways?

No. SAQ D is for card numbers that reach your own systems, such as a website that collects them or files where you keep them, or a setup that fits no shorter SAQ. Several payment methods usually means several short SAQs. Your acquirer has the final say.

Ready to see your SAQs?

Describe how you take payments in your own words. We'll tell you which SAQ fits each one, free, before you pay anything.

Other businesses

Hotels and lodgingRestaurants, bars and cafesRetail storesSalons, spas and barbershopsMedical, dental and veterinary officesSmall online storesNonprofits and charities

Sources

General guidance, not legal advice. Your acquirer or payment processor decides which SAQ you must file. PCI DSS v4.0.1; content checked 2026-10-23.