PCI SAQ C-VT and SAQ D for Phone-Order and Virtual Terminal Merchants: Which Questionnaire You Actually Owe

If you take card numbers by phone and manually enter one transaction at a time into a qualifying third-party hosted browser virtual terminal, SAQ C-VT may apply. But SAQ C-VT virtual terminal PCI eligibility depends on the complete payment-data environment. Electronic storage, other electronic intake channels, integrated software, attached capture devices, or a broader connected environment can require another SAQ or SAQ D.

As of September 2026, PCI DSS v4.0.1 remains the currently published PCI DSS standard. In June 2026, PCI SSC opened a Request for Comments to help shape a future iteration, but that process did not replace v4.0.1.

Merchants should therefore work from current PCI SSC materials rather than relying on old v3.x checklists, processor blog posts, or archived questionnaires whose eligibility language may no longer reflect the current version.

SAQ C-VT vs SAQ D: The Fast Answer

A phone order does not determine your SAQ. What matters is what happens to the account data after the customer gives it to you, which systems touch it, whether it is electronically stored, and whether the complete environment meets every eligibility condition for the selected questionnaire.

That principle is central to understanding SAQ C-VT virtual terminal PCI requirements. PCI SSC explains that SAQ eligibility depends on the merchant’s actual payment environment and the conditions attached to that questionnaire. That is why a merchant should not select C-VT simply because transactions happen by phone. 

Situation	C-VT Candidate?	Why
Employee hears the card number and immediately enters one transaction into a qualifying hosted browser VT	Potentially	Every C-VT eligibility condition still must be met
PAN is placed in a spreadsheet or text file before processing	No	C-VT does not permit merchant electronic account-data storage
Customer emails a card number	Generally outside the C-VT model	Account data is being received electronically through another channel
Computer runs store-and-forward or batch software containing account data	No	C-VT excludes software that causes cardholder data to be stored
Employee keys the card into an integrated CRM or POS payment module	Not automatically	A merchant payment application is different from the narrow C-VT model
Several qualifying VT computers exist in one properly isolated network zone	Potentially	Current guidance does not impose a universal one-computer rule
Merchant has a VT plus ecommerce or another payment channel	Depends	All channels must be identified and appropriately scoped
Merchant cannot satisfy another applicable reduced-scope merchant SAQ	SAQ D becomes relevant	SAQ D is the broad merchant self-assessment route

The organization accepting the merchant’s PCI validation—typically an acquirer, payment brand, or another compliance-accepting entity—controls its validation and reporting program. That does not mean it can waive PCI DSS itself. PCI SSC clarified in August 2026 that merchants should confirm validation and reporting expectations with the organization managing their compliance program.

What SAQ C-VT Actually Covers

PCI SSC describes SAQ C-VT as the questionnaire for qualifying merchants using Internet-connected virtual payment terminals. The intended environment involves manually entering one transaction at a time, no electronic cardholder-data storage, a qualifying third-party hosted solution, and compliance with the other C-VT eligibility conditions.

Under PCI terminology, a virtual terminal is narrower than “any screen where an employee can type a card number.” An integrated POS application, merchant-hosted payment form, CRM payment window, custom business application, or other software interface is not automatically a C-VT virtual terminal.

That distinction is essential.

For SAQ C-VT virtual terminal PCI eligibility, the current model requires the merchant to verify that:

• payment processing for the assessed environment occurs through the qualifying Internet-connected virtual terminal;
• the virtual-terminal solution is provided and hosted by a PCI DSS-validated third-party service provider;
• the permitted computer environment satisfies the applicable isolation requirements;
• software installed on the relevant systems does not cause cardholder data to be stored;
• attached hardware is not being used to capture or store cardholder data;
• the merchant does not otherwise electronically receive or transmit cardholder data through another channel;
• applicable retained account-data records are on paper rather than electronically stored; and
• the merchant satisfies every other current eligibility condition.

PCI SSC’s current C-VT FAQ expressly describes these conditions.

Businesses should also separate PCI eligibility from the general feature set of their payment technology. Integrations, tokenization, reporting, mobile acceptance, online invoicing, recurring billing, and other capabilities can all be useful, but adding them can also change the systems participating in a payment workflow.

When assessing a broader payment stack, features such as software integration, security controls, omnichannel acceptance, tokenization, reporting, and payment-method support should be evaluated alongside—not instead of—the official PCI eligibility rules.

C-VT Isolation Does Not Mean “Exactly One Computer”

One persistent misunderstanding is that C-VT means a merchant is allowed exactly one physical computer.

PCI SSC does not describe the rule that way.

Its guidance explains that more than one permitted system of the same type can exist within the same network zone, provided the permitted systems are properly isolated from other system types. For C-VT, the permitted system type is the web-based virtual payment terminal environment.

So it is inaccurate to reduce the rule to:

“C-VT means one business can have only one virtual-terminal computer.”

The more accurate question is whether the permitted systems remain within an eligible, appropriately isolated C-VT environment.

A merchant should be able to identify:

• which systems access the virtual terminal;
• what those systems connect to;
• whether other system types are present;
• whether network segmentation is being used;
• whether another system administers the VT workstation; and
• whether any connection changes the eligible system environment.

For example, a general back-office server, unrelated business application, or other incompatible system should not simply be assumed acceptable because employees ultimately process the payment in a hosted browser VT.

The SAQ Map for Non-Ecommerce Merchants

Understanding SAQ C-VT vs SAQ D is easier when the neighboring merchant questionnaires are separated clearly.

SAQ	High-Level Eligible Environment	Relationship to Phone/Virtual-Terminal Payments
SAQ B	Qualifying imprint-only or standalone dial-out terminal environments with no electronic cardholder-data storage	Browser VT entry does not become B merely because a customer supplied the card number by phone
SAQ B-IP	Qualifying standalone approved IP-connected POI-device environments	Device-focused rather than browser-VT focused
SAQ C	Qualifying Internet-connected payment-application environment	Different from a hosted browser C-VT environment
SAQ C-VT	Manual single-transaction entry through qualifying hosted virtual payment terminal	Primary reduced-scope candidate discussed here
SAQ P2PE	Environment using an applicable validated PCI-listed P2PE solution	Ordinary browser key-entry is not automatically P2PE
SAQ D	Merchant environment that does not qualify for another applicable reduced-scope SAQ	Broad merchant self-assessment path

SAQ B

SAQ B covers specifically defined environments such as qualifying standalone dial-out terminals or imprint-only arrangements.

Manually typing card information into an Internet browser does not become SAQ B merely because the merchant obtained the details over the telephone.

SAQ B-IP

SAQ B-IP concerns narrowly defined environments using eligible approved IP-connected point-of-interaction devices.

It is device-focused and should not be treated as a substitute for C-VT merely because an employee manually enters a transaction.

SAQ C

SAQ C is associated with qualifying Internet-connected payment application environments.

PCI SSC explicitly states that SAQ C-VT does not replace SAQ C. SAQ C is intended for qualifying payment-application environments, while C-VT addresses merchants manually entering one transaction at a time into an Internet-based virtual terminal supplied by a PCI DSS-validated service provider.

SAQ C-VT

This is the narrow payment environment at the center of this article.

For a phone-order business, SAQ C-VT virtual terminal PCI may be a logical candidate when an employee hears account data from the customer and immediately enters an individual transaction into the qualifying browser VT without routing that information through other merchant electronic systems.

SAQ P2PE

SAQ P2PE is commonly misunderstood.

A merchant cannot simply purchase a terminal advertised as encrypted and declare the environment P2PE.

Eligibility depends on using an applicable validated PCI-listed P2PE solution and satisfying the corresponding merchant requirements.

For a MOTO merchant, a P2PE workflow can be materially different from browser-based C-VT. Card information received over the phone can, in an eligible P2PE design, be entered directly into equipment forming part of the validated P2PE solution.

That does not transform ordinary browser entry into a P2PE transaction.

SAQ D for Merchants

SAQ D is the broader merchant self-assessment questionnaire.

It should not be described as “the questionnaire for large merchants.”

A small office can have a broad PCI environment that does not fit any reduced-scope SAQ, while a larger operation may have one or more specially structured payment channels with different validation arrangements.

Eligibility and environment—not company size alone—drive the distinction.

Your Payment Workflow Determines the Questionnaire

The simplest way to understand phone-order PCI compliance is to draw what happens to the card number.

Workflow 1: Phone Call Directly Into a Hosted Virtual Terminal

Customer → phone conversation → employee → permitted VT workstation → hosted third-party virtual terminal → processor

This is the classic SAQ C-VT virtual terminal PCI candidate.

Before treating it as C-VT, verify that:

• the VT provider satisfies the relevant requirements;
• the merchant environment meets current isolation criteria;
• transactions are entered individually;
• no software causes prohibited cardholder-data storage;
• no attached hardware breaks eligibility; and
• there is no parallel electronic card-data path.

The fact that a business calls a product a “virtual terminal” is not enough. The technical architecture and data flow must match the PCI model.

Workflow 2: Card Number Written on Paper First

Customer → phone → employee writes PAN on paper → employee enters transaction → paper securely handled

Paper does not automatically disqualify C-VT.

PCI SSC’s C-VT description expressly contemplates applicable paper reports or receipts.

Paper is not outside PCI DSS, however.

Merchants still need appropriate controls for:

• physical access;
• storage;
• retention;
• handling; and
• secure destruction.

The practical objective should be to retain payment-card data on paper only where there is a legitimate business need and to dispose of it securely when that need ends.

Workflow 3: Customer Emails the Card Number

Customer → email server → mailbox → employee → virtual terminal

Now there is another electronic account-data path.

Deleting the email after processing does not undo the fact that cardholder data was electronically received through a separate merchant system.

C-VT eligibility requires that the merchant not otherwise receive or transmit cardholder data electronically through another channel.

Businesses therefore should not design ordinary email, chat, SMS, ticketing tools, or similar systems as card-data intake channels when trying to maintain the narrow C-VT model.

Workflow 4: Employee Types PAN Into CRM Notes

Customer → employee → CRM → later re-keyed into virtual terminal

The VT is no longer the merchant’s only relevant electronic payment-data system.

An integrated CRM payment field, customer record, free-text note, scheduling application, or order-management system containing PAN becomes part of the account-data story.

Even if the PAN remains there for only an hour, “temporary” electronic storage is still electronic storage.

Workflow 5: Spreadsheet Used as an Order Queue

A spreadsheet containing full PAN creates one of the clearest conflicts with C-VT’s no-electronic-storage model.

The same problem can arise with:

• local text documents;
• desktop notes;
• screenshots;
• shared drives;
• databases;
• electronic order forms; and
• ticket queues.

The employee eventually typing the number into a hosted VT does not erase the preceding electronic storage.

Workflow 6: Call Recording Captures Card Details

Phone intake itself can be compatible with a C-VT workflow.

Electronically recording the payment information is different because the audio file can become electronic media containing account data.

Where possible, businesses should prevent payment-card information from entering call recordings rather than depending on later deletion.

Special care is required with CVV, CVC, CID, and similar card-verification values. Sensitive authentication data has stricter post-authorization storage restrictions than ordinary cardholder-data elements.

Workflow 7: Several Employees Use Virtual Terminals

More than one employee or workstation does not automatically mean SAQ D.

PCI SSC explains that several permitted systems of the same type can exist within an isolated network zone as long as they remain isolated from other system types and all other eligibility criteria are met.

A geographically distributed architecture is a different question.

Multiple offices, work-from-home systems, remote administration, shared servers, VPNs, or other connectivity should be evaluated against the actual C-VT criteria rather than assumed eligible.

Workflow 8: Virtual Terminal Plus Ecommerce

Many merchants accept payments through more than one channel.

A business might use:

• hosted VT for telephone payments;
• ecommerce checkout;
• mobile acceptance;
• in-person POS;
• online invoicing; and
• recurring billing.

Adding channels does not automatically mean “SAQ D for everything.”

The merchant must identify each channel, determine which systems participate in it, understand whether those environments are separated, and establish which validation method applies.

As payment operations grow, transaction volume, additional payment methods, new locations, integrations, and multichannel acceptance can expand the underlying payment architecture. PCI scope should be reassessed as those systems change rather than assuming the original questionnaire will remain appropriate indefinitely.

SAQ C-VT Virtual Terminal PCI Eligibility Checklist

Use this checklist as a preliminary screening exercise, not as a substitute for the official current questionnaire.

• We know every place where account data enters the business.
• Employees manually enter individual transactions into the qualifying hosted virtual terminal.
• We have verified the relevant third-party provider and service.
• We know exactly which systems can access the virtual terminal.
• The VT environment satisfies current isolation criteria.
• No software on those systems causes cardholder data to be stored.
• No attached hardware breaks the applicable C-VT eligibility criteria.
• We do not electronically store cardholder data.
• Employees do not place PAN in email, chat, CRM notes, spreadsheets, tickets, or recordings.
• Paper account-data records are appropriately controlled.
• We have documented every other payment channel.
• We are using the current SAQ rather than an outdated questionnaire.
• We have confirmed validation expectations with the organization accepting our PCI submission.

When SAQ D for Merchants Becomes Relevant

SAQ D becomes relevant when a merchant cannot satisfy the eligibility criteria for another applicable reduced-scope merchant questionnaire.

For a business originally expecting SAQ C-VT virtual terminal PCI, common conditions that can change that analysis include:

• electronically storing PAN;
• putting payment data into CRM or internal business applications;
• receiving card data through email or messaging;
• recording cardholder data electronically;
• receiving electronic order forms containing PAN;
• using merchant-controlled payment software instead of the qualifying hosted VT model;
• allowing payment data to travel through additional internal systems;
• using store-and-forward or batch-storage software;
• using attached capture/storage hardware inconsistent with C-VT criteria;
• operating a network environment that does not satisfy the required isolation model; or
• adding another payment channel whose environment needs broader assessment.

SAQ D is not a punishment.

It reflects a broader environment requiring a broader PCI DSS assessment.

C-VT vs SAQ D Requirements and Effort

Factor	SAQ C-VT	SAQ D for Merchants
Intended environment	Narrow qualifying browser-VT environment	Broad merchant environment
Eligibility restrictions	Highly specific	Used when another appropriate merchant SAQ does not fit
Electronic account-data storage	Not permitted under C-VT eligibility	May exist, subject to applicable PCI DSS controls
Systems typically involved	Isolated permitted VT systems	Potentially applications, databases, networks, workstations and other systems
PCI DSS coverage	Defined subset for eligible C-VT environment	Potentially broad coverage across PCI DSS
Documentation	Relatively focused	Usually considerably broader
Technical evidence	Focused on qualifying VT environment and applicable controls	Can include extensive inventories, network scope, application controls, logging, vulnerability management and other evidence
Typical use case	Controlled MOTO/manual VT operation	Integrated or otherwise broader merchant environment

Why a Universal “Question Count” Can Mislead

It is common to see claims such as:

“SAQ C-VT contains X questions, while SAQ D contains Y.”

That can be misleading without defining exactly what is being counted.

PCI documents contain several possible counting units:

• top-level requirements;
• subrequirements;
• testing procedures;
• individual response rows;
• administrative fields; and
• Attestation of Compliance sections.

Third-party PCI portals can further split or combine those elements into their own screens.

A portal saying that a merchant has 70, 100, or several hundred “questions” does not necessarily mean PCI SSC itself defines the questionnaire using that exact total.

The defensible comparison is that SAQ D normally involves substantially broader assessment coverage and evidence because the underlying merchant environment is broader.

Why P2PE Can Be Much Shorter—but Is Not a Browser-VT Shortcut

Some merchants learn that P2PE can reduce PCI assessment scope and assume that buying an encrypted device allows them to substitute P2PE for C-VT.

That is not how it works.

Eligibility depends on using an applicable validated PCI-listed P2PE solution and meeting its associated requirements.

An ordinary terminal that encrypts transaction data is not automatically equivalent to a PCI-listed P2PE solution.

Likewise, browser key-entry does not become P2PE simply because the payment processor encrypts the data after it leaves the browser.

For MOTO payments, an eligible P2PE architecture can exist where staff receive the card details by phone and enter them directly and only into an eligible device forming part of the validated P2PE solution.

That is a different technical workflow from entering the information into an ordinary Internet browser.

Five Common SAQ Misfiles

1. “We Take Phone Orders, So We Automatically Use C-VT.”

Incorrect.

MOTO describes an acceptance channel. SAQ C-VT virtual terminal PCI eligibility describes a specific technical and account-data environment.

2. “Manual Entry Means SAQ B.”

Manual entry by itself does not determine SAQ B.

Manual keyboard entry of individual transactions into an eligible hosted Internet virtual terminal is the use case associated with C-VT.

3. “Our POS Has a Manual-Entry Button, So It Is a Virtual Terminal.”

Not necessarily.

PCI SSC distinguishes payment-application environments from the specific Internet virtual-terminal environment used for C-VT.

4. “We Never Intentionally Save Cards, So CRM and Email Do Not Count.”

Intent is not the test.

PCI scope involves storage, processing, and transmission. A system can matter even where staff never intended to create a permanent card vault.

5. “The Portal Assigned C-VT, So It Must Be Correct.”

A compliance portal works from the environment information supplied to it.

If the merchant answered profiling questions incorrectly—or if the payment architecture changed—the assignment may no longer reflect the actual environment.

Correct the environment description rather than knowingly submitting an inapplicable questionnaire.

What PCI DSS v4.0.1 Changed—and What It Did Not Change

PCI DSS v4.0.1 was published in June 2024 as a limited revision to PCI DSS v4.0.

PCI SSC described the release as containing clarifications, corrections, and additional guidance rather than a completely new requirement framework.

The aligned v4.0.1 SAQs were published on October 15, 2024. PCI SSC specifically stated that the update clarified eligibility criteria in SAQ C-VT, among other questionnaires, and that aligned SAQ Instructions and Guidelines were also published.

PCI DSS v4.0 was retired on December 31, 2024.

That version change should not be confused with the separate March 31, 2025 date associated with requirements that PCI DSS v4.x had originally treated as future-dated.

Those effective dates have passed.

An article written in 2026 therefore should not describe applicable March 2025 controls as future optional best practices.

Is PCI DSS v4.0.1 Still Current in 2026?

Yes.

PCI SSC’s June 3, 2026 Request for Comments explicitly referred to PCI DSS v4.0.1 as the currently published PCI DSS while the Council solicited feedback for the standard’s future evolution.

Development of a future iteration does not mean a newer standard has already replaced v4.0.1.

How to Fix the Wrong SAQ in a Processor PCI Portal

Step 1: Inventory Every Payment Channel

List every way payment information can enter the organization:

• phone;
• paper order form;
• browser virtual terminal;
• ecommerce checkout;
• POS;
• mobile device;
• invoice;
• recurring payment system; and
• stored-credential workflow.

Step 2: Draw the Data Flow

For each channel, identify:

receipt → processing → transmission → storage

Document paper and electronic paths separately.

Step 3: Identify Every Electronic System That Can Touch PAN

Look beyond the processor.

Potentially relevant systems include:

• employee workstations;
• CRM;
• email;
• messaging;
• call recording;
• electronic order forms;
• document systems;
• browser extensions;
• payment applications;
• databases;
• shared storage;
• backup systems; and
• remote-access tools.

Step 4: Compare the Environment With Current SAQ Eligibility Criteria

Do not choose SAQ C-VT virtual terminal PCI because its questionnaire is shorter.

Choose it only where the actual environment satisfies the current conditions.

Step 5: Gather Evidence

Useful documentation may include:

• virtual-terminal provider and product information;
• provider PCI DSS status;
• workstation inventory;
• network or segmentation diagrams;
• payment-data flow;
• list of payment channels;
• retention policies;
• call-recording controls; and
• screenshots of relevant portal profile questions that do not expose PAN or sensitive authentication data.

When selecting or changing a provider, also consider payment methods, gateway and virtual-terminal capabilities, software compatibility, fraud controls, security, contract terms, and settlement timing. Those operational choices can alter the technology participating in the merchant’s payment workflow.

Step 6: Correct the Portal Environment Profile

PCI compliance portals use different terminology.

Do not expect a universal button called “change SAQ.”

Correct the factual profile describing your business and payment environment rather than manipulating answers merely to obtain the shortest questionnaire.

Step 7: Contact the Compliance Provider, Processor, or Acquirer

A useful factual request is:

“Our current payment workflow is [brief description]. The SAQ currently assigned in the portal does not appear to reflect this environment. Please review our eligibility against the current PCI DSS SAQ criteria and confirm the validation questionnaire your compliance program requires.”

PCI SSC’s current guidance emphasizes that merchants should consult the organization managing the relevant compliance program about validation and reporting expectations.

Step 8: Keep the Written Record

Retain:

• applicable SAQ version;
• completion date;
• Attestation of Compliance;
• required scanning evidence where applicable;
• processor/acquirer correspondence;
• network or segmentation diagrams;
• account-data flow documentation; and
• evidence supporting SAQ eligibility.

Step 9: Reassess After Technology Changes

Payment environments change.

Reassess when the merchant:

• adds ecommerce;
• adopts integrated POS or CRM payment functionality;
• changes VT providers;
• adds remote workers;
• adds locations;
• introduces call recording;
• changes network architecture;
• adopts new payment devices;
• introduces electronic card-data storage; or
• adds another acceptance channel.

The same principle applies to broader payment-system planning: integrations, multiple payment methods, security features, APIs, reporting tools, and omnichannel functions can be operationally useful, but each architectural change should be considered for its effect on payment-data scope.

Workflow Red Flags

Practice	Why It Matters	C-VT Impact	Better Control
PAN sent through ordinary email	Merchant electronically receives account data elsewhere	Conflicts with narrow C-VT model	Direct customer to an approved payment workflow
PAN saved in spreadsheet	Electronic storage	C-VT eligibility fails	Enter directly into qualifying payment process
PAN stored in CRM notes	Adds electronic application/storage path	Material eligibility issue	Keep card data out of free-text CRM fields
Call recording captures PAN	Creates electronic payment-data media	Material eligibility issue	Prevent payment details from entering recordings
Multiple remote locations	May affect isolation requirements	Needs architecture-specific review	Map connectivity and confirm eligibility
Integrated payment application	Different system type from narrow C-VT model	May point to another SAQ or D	Assess the actual payment architecture
Attached capture hardware	Specifically relevant to C-VT eligibility	Can break eligibility	Determine correct payment/SAQ model
Paper order form	Still contains cardholder data	Can remain compatible if criteria are met	Protect, minimize retention, securely destroy

What Phone-Order Merchants Should Never Treat as Normal Practice

Do not retain card-verification values after authorization merely because they might be useful later.

CVV, CVC, CID, and similar values are sensitive authentication data and receive particularly strict treatment.

Avoid making any of the following normal card-data repositories:

• ordinary email;
• chat;
• spreadsheets;
• shared documents;
• screenshots;
• free-text CRM fields;
• ticketing systems; and
• call recordings.

Also do not assume tokenization automatically makes every connected system irrelevant to PCI scope.

Tokenization depends on the implementation, including whether account data can be retrieved and whether connected systems can affect the security of the tokenization environment.

Finally, do not assume that a PCI DSS-compliant payment processor makes the merchant’s own environment automatically compliant.

The service provider’s environment and the merchant’s environment are separate assessment questions.

Decision Tree: Do I Qualify for SAQ C-VT?

1. Are employees manually entering individual transactions into an Internet-based virtual payment terminal?

No → C-VT is probably not the applicable SAQ. Evaluate the actual payment architecture.

Yes → Continue.

2. Is the virtual terminal the type of third-party hosted Internet solution contemplated by PCI SSC?

No → Evaluate another SAQ or SAQ D.

Yes → Continue.

3. Is the solution provided and hosted by an appropriate PCI DSS-validated third-party service provider?

No → C-VT eligibility is not established.

Yes → Continue.

4. Does the VT environment satisfy current isolation requirements?

No → C-VT does not fit unless the architecture is changed to satisfy those conditions.

Yes → Continue.

5. Does software on the relevant systems cause cardholder data to be stored?

Yes → C-VT eligibility fails.

No → Continue.

6. Is attached hardware used in a way inconsistent with C-VT eligibility?

Yes → Reassess the applicable SAQ.

No → Continue.

7. Does account data enter another electronic merchant system?

Examples include:

• email;
• CRM;
• messaging;
• electronic order forms;
• recordings;
• spreadsheets; and
• internal business applications.

Yes → The environment does not match the narrow C-VT model.

No → Continue.

8. Does the merchant electronically store cardholder data anywhere?

Yes → C-VT eligibility fails.

No → Continue.

9. If card data exists on paper, are applicable physical controls in place?

No → Correct those controls.

Yes → Continue.

10. Have all additional payment channels been mapped?

No → Complete the scope analysis first.

Yes → Continue.

11. Has the compliance-accepting entity confirmed the validation/reporting method?

No → Obtain confirmation before relying on a portal assignment.

Yes → Complete the applicable current assessment.

This decision tree is a screening exercise. It does not replace the current official SAQ eligibility language.

Frequently Asked Questions

Which PCI SAQ applies if I only take payments over the phone?

There is no universal “phone-payment SAQ.”

If an employee hears the card information and immediately enters individual transactions into a qualifying third-party hosted browser virtual terminal within an eligible environment, SAQ C-VT virtual terminal PCI may apply.

A different architecture may require another SAQ.

Is every browser-based payment screen a virtual terminal?

No.

A browser interface can still be part of a payment application or integrated merchant system rather than the specific Internet-based virtual-terminal environment contemplated by C-VT.

PCI SSC specifically distinguishes SAQ C and C-VT environments.

Can I use C-VT if I save customers’ card numbers electronically?

No under the C-VT eligibility model.

C-VT is intended for qualifying environments where cardholder data is not electronically stored by the merchant.

Does writing a card number on paper disqualify C-VT?

Not automatically.

The C-VT model can include applicable paper reports or receipts containing account data, but physical protection, retention, and destruction controls still apply.

Does receiving PAN by email change PCI scope?

Yes.

It introduces another electronic system through which cardholder data enters the merchant environment and conflicts with the narrow C-VT model described by PCI SSC.

Can several computers use the virtual terminal and still qualify?

Potentially.

PCI SSC explains that multiple permitted systems of the same type may exist in one network zone when they remain isolated from other system types and all applicable eligibility conditions are met.

What if the VT computer is also used for email or ordinary office work?

Do not assume that a multipurpose configuration is automatically compatible with C-VT.

Relevant questions include:

• which system types are present;
• whether the system remains properly isolated;
• what software is installed;
• whether cardholder data can be stored;
• whether other electronic channels receive PAN; and
• whether the actual environment still satisfies the current criteria.

Does C-VT require an ASV scan?

C-VT has a narrower requirement set than SAQ D and should not be treated as though every Requirement 11 control from a broader assessment automatically appears in it.

However, merchants should not turn that into the universal claim that no scanning obligation can ever apply. Validation requirements can also depend on the merchant environment and the compliance program being administered by the relevant payment brand or acquirer.

Confirm the applicable validation requirements with the compliance-accepting entity.

Is SAQ D harder than C-VT?

SAQ D normally involves substantially more assessment work because the underlying environment can be much broader.

That is a difference in scope, not a statement that PCI security controls are optional for C-VT merchants.

Can my processor require me to complete SAQ D?

The organization managing the merchant’s compliance program can establish its validation and reporting requirements.

PCI SSC says merchants should consult their compliance-accepting entities regarding the appropriate reporting and validation approach.

Does switching processors transfer my PCI validation automatically?

Do not assume automatic portability.

An SAQ and AOC document a particular environment and assessment, while a new processor or acquiring bank may operate a different compliance program or submission process.

Provide an accurate current description of the payment environment and ask what evidence the new compliance program will accept.

Is C-VT always the easiest PCI option for a phone-order business?

No.

C-VT may provide a relatively focused assessment when the merchant genuinely meets its eligibility criteria.

Designing operations around an inaccurate questionnaire simply because it is shorter is the wrong approach.

Can a phone-order business use P2PE instead?

Potentially, where the actual payment environment qualifies.

For example, an eligible MOTO workflow may involve an employee receiving the card information by telephone and entering it directly into equipment that forms part of a validated PCI-listed P2PE solution.

That is not the same thing as entering payment data into an ordinary browser VT.

Choosing the Right SAQ Is About Scope, Not the Shortest Form

The correct SAQ C-VT virtual terminal PCI determination starts with the complete account-data flow.

Identify exactly where PAN enters the business, which people and systems interact with it, whether it is electronically stored, what software and hardware participate in processing, how the VT environment is isolated, and which other payment channels exist.

Use SAQ C-VT virtual terminal PCI only where the merchant genuinely satisfies the current eligibility conditions. If another reduced-scope SAQ fits the actual environment, use that validation path. If no applicable reduced-scope merchant SAQ fits and the organization is otherwise eligible to self-assess, SAQ D becomes the broader questionnaire.

Revisit the analysis whenever technology or payment channels change.

A CRM integration, ecommerce site, remote office, call-recording platform, payment terminal, mobile channel, electronic storage workflow, or different virtual-terminal provider can change the PCI environment even though the business still describes the transaction as a phone order.

Most importantly, use current PCI SSC material as the technical baseline and confirm the reporting requirements with the organization accepting the merchant’s PCI validation.