Virtual Terminals for Processing Credit and Debit Cards

Virtual Terminal Payments: How to Take Card Payments by Phone Safely

A virtual terminal allows a business to accept a card payment without the customer using a physical card machine or entering their details through an online checkout.

Instead, an authorised member of staff signs into a secure browser-based system and manually enters the card information supplied by the customer.

This may be useful when:

• A customer calls to pay an invoice
• A business takes telephone orders
• A customer cannot use a payment link
• Staff assist customers with one-off payments
• A business receives mail-order instructions
• A remote balance needs to be collected
• A business-to-business customer pays by company card

However, a virtual terminal changes who handles the card information.

With a payment link, the customer normally enters their own card details.

With a virtual terminal, the merchant’s staff may hear, receive and enter those details.

That creates important questions about:

• PCI DSS compliance
• Staff access
• Call recording
• Card-security codes
• Email and messaging
• Fraud
• Customer consent
• Strong Customer Authentication
• Chargebacks
• Refund permissions
• Remote working
• Reconciliation
• Provider underwriting

The correct question is not simply:

Can we take a payment over the telephone?

It is:

Is a manually entered virtual-terminal payment the safest and most appropriate journey for this customer, or should the customer enter their details through a secure payment link instead?

This guide explains how virtual terminals work, how to take telephone payments more safely and what UK businesses should check before selecting a provider.

---

Find Your New Processor

Quick answer: What is a virtual terminal?

A virtual terminal is a secure web-based interface through which authorised merchant staff manually enter a customer’s card information.

Unlike an ecommerce checkout, the customer does not normally enter the information directly into the payment page.

Unlike a physical card terminal, the card is not usually inserted, tapped or presented to the device.

The PCI Security Standards Council describes a virtual-terminal environment as one where the merchant manually enters a single transaction at a time using a keyboard and a browser-based solution supplied by a validated third party.

A virtual terminal may allow the merchant to:

• Enter a one-off payment
• View the transaction result
• Send or record a receipt
• Issue a refund
• Search previous transactions
• Add an invoice or customer reference
• Control staff permissions
• Export reports

The exact features depend on the provider.

Using a virtual terminal does not automatically mean:

• The business is PCI DSS compliant
• Every member of staff can use it
• Card details can be written down
• Calls can retain card-security codes
• Payments are protected by 3D Secure
• Every transaction is correctly classified as MOTO
• The business can store the card for later use
• Approval or chargeback protection is guaranteed

---

How does a virtual-terminal payment work?

A typical process may look like this:

Customer agrees to pay

↓

Staff confirm the customer, invoice, amount and purpose

↓

Customer is told how their card information will be handled

↓

Any call-recording process is paused or protected

↓

Staff enter the information directly into the virtual terminal

↓

The provider returns an approved or declined result

↓

Staff record only the information needed for the business record

↓

A receipt or payment confirmation is sent

↓

The payment is reconciled to the correct customer and invoice

The business should avoid any unnecessary stage where the card details are copied into:

• Paper notes
• Email
• CRM free-text fields
• Spreadsheets
• Instant messaging
• Call-centre notes
• Internal chat
• Photographs or screenshots

The safest practical workflow normally moves the information directly from the customer into the approved payment interface without creating a second copy.

---

Virtual terminal versus payment link

These payment methods can both be used remotely, but the customer journey is different.

A payment link is not automatically appropriate for every customer.

Some customers may:

• Not use email
• Not have a smartphone
• Have accessibility needs
• Be uncomfortable clicking links
• Need staff assistance
• Be calling from a location with poor internet access

Likewise, a virtual terminal should not be used automatically merely because it is convenient for the member of staff.

Find Your New Processor

MAS insight: Use the lowest-risk journey that still works

A sensible order is:

1. Customer-led secure checkout or payment link where appropriate
2. Properly configured physical or remote payment method
3. Virtual terminal where staff-assisted entry is genuinely required

This does not mean the virtual terminal is unsafe.

It means that reducing the amount of raw card information handled by staff can reduce both PCI DSS scope and operational risk.

Virtual terminal versus IVR telephone payments

An Interactive Voice Response payment system, commonly called IVR, allows a customer to enter their own card information using the telephone keypad.

IVR payments can be:

• Fully automated, without a member of staff remaining on the call
• Agent-assisted, with the customer temporarily transferred into a secure payment stage
• Connected to an invoice, account or customer reference
• Used as an alternative to staff manually entering card details

In a properly designed telephone-payment system, the customer’s keypad entries may be captured directly by the payment service without the employee seeing or hearing the complete card information.

Some systems use DTMF masking or suppression. DTMF refers to the tones generated when the caller presses telephone keypad buttons.

The system may replace or suppress those tones so that:

• The employee cannot identify the card digits
• The digits do not remain in the ordinary call recording
• The card information is passed directly to the payment environment
• The employee receives only the payment result

PCI SSC recommends considering technologies that minimise the exposure of employees to card information. However, it also warns that telephone-payment technology must be carefully assessed because the effect on PCI DSS scope depends on the complete implementation, telephony environment and responsibilities of the service providers involved. 

Virtual terminal, IVR and payment link compared

Does IVR remove the business from PCI DSS scope?

Not automatically.

The result depends on:

• How the telephone system is configured
• Whether staff can hear or see the card information
• Whether card data enters call recordings
• Whether DTMF tones are properly suppressed
• Whether Voice over Internet Protocol systems carry card information
• Which company hosts and processes the payment
• Whether card information reaches the merchant’s network
• How transaction information is stored
• The merchant’s other payment channels

PCI DSS applies wherever payment card data is stored, processed or transmitted. PCI SSC specifically notes that VoIP systems carrying card information can fall within scope while the traffic is under the organisation’s control. 

An IVR provider may help reduce the merchant’s exposure, but the merchant should confirm the actual PCI DSS effect with its acquirer or PCI adviser.

Questions to ask an IVR payment provider

Ask:

• Does the customer enter the card details through their telephone keypad?
• Can the employee hear any of the card digits?
• Can the employee see the complete card number?
• Are DTMF tones suppressed or replaced?
• Can card information enter the call recording?
• Is the payment information sent directly to the processor?
• Is the IVR provider PCI DSS validated for the service?
• Which parts of the telephone environment remain in our PCI DSS scope?
• Can the customer return to the employee after paying?
• What happens if the customer cannot use the keypad?
• Can the system connect the payment to an invoice or customer account?
• Are receipts, refunds and reconciliation supported?
• Can the system operate outside normal office hours?
• How are failed or abandoned payments handled?

MAS insight: Not every system described as IVR offers the same protection

The term IVR may describe several different telephone journeys.

A basic automated telephone menu is not necessarily a secure card-payment solution.

The business should establish:

• Who receives the card information
• What the employee can hear or see
• Whether the call is recorded
• Where the data travels
• Which systems store it
• Who is responsible for PCI DSS compliance

The value of secure IVR is not simply automation.

It is the ability, where properly implemented, to let the customer enter their card details without unnecessarily exposing those details to the employee or the wider call-centre environment.

Virtual terminal versus a physical card terminal

A physical card terminal allows the customer to:

• Insert the card
• Tap the card or device
• Enter a PIN
• Complete an authenticated card-present transaction

A virtual terminal normally involves:

• Manual card-number entry
• Card-not-present processing
• No physical reading of the card
• Different fraud and chargeback exposure
• Different pricing and provider controls

A customer standing in the shop while an employee keys their card number into a virtual terminal does not automatically make the transaction card present.

The payment should be processed through the correct provider-approved channel rather than whichever screen happens to be easiest to access.

---

Find Your New Processor

Virtual terminal versus MOTO merchant account

MOTO means mail order or telephone order.

A virtual terminal is the technology used to enter some MOTO payments.

A MOTO merchant account describes the wider provider and underwriting arrangement supporting that payment channel.

A business processing most of its turnover by telephone may require the provider to understand:

• Monthly MOTO turnover
• Number of telephone payments
• Average and maximum transaction
• Call-centre operation
• Customer countries
• Fraud controls
• Chargeback history
• Goods or services
• Fulfilment
• Refund processes

Simply receiving access to a virtual-terminal screen does not mean every type or value of MOTO payment has been approved.

---

When can a virtual terminal be useful?

Virtual terminals can suit businesses such as:

• Professional services
• Legal firms
• Estate-planning businesses
• Funeral directors
• Wholesalers
• Business-to-business suppliers
• Hotels and hospitality businesses
• Travel businesses
• Membership organisations
• Charities
• Debt-collection businesses
• Insurance-related businesses
• Home-improvement companies
• Kitchen and bathroom suppliers
• Call centres
• Mail-order businesses
• Trades collecting invoice payments

Possible use cases include:

• Paying an outstanding invoice
• Booking a service by telephone
• Paying a project deposit
• Settling a final balance
• Taking payment from a corporate purchasing card
• Collecting a one-off membership payment
• Processing a customer-authorised telephone order

The provider must still approve the business activity, payment channel and transaction profile.

---

When might a payment link be preferable?

A payment link may be more suitable where:

• The customer can access email or SMS
• The payment can wait a few minutes
• Customer authentication is desirable
• Staff should not handle card information
• The customer needs to review an invoice first
• The business wants the customer to complete the checkout independently
• The payment needs to connect with an online record
• Several remote staff would otherwise hear card details

For more detail, see the MAS guide to Pay by Link payments.

---

What information is entered into a virtual terminal?

Depending on the provider and transaction, the member of staff may be asked for:

• Card number
• Expiry date
• Cardholder name
• Card-security code
• Billing address
• Postcode
• Transaction amount
• Invoice or order reference
• Customer details
• Currency
• Description

Only collect information required for the transaction and approved business process.

Do not ask the customer for:

• Card PIN
• Online banking password
• One-time banking code
• Full authentication credentials
• Unrelated security information

A card PIN should not be requested for a telephone payment.

---

Can staff ask for the CVV or security code?

A merchant can request the card-verification code for a card-not-present payment where it is required for authorisation.

However, the code is treated as sensitive authentication data.

PCI DSS prohibits storing it after authorisation, even where it is encrypted. The PCI Security Standards Council says merchants may request CVV, CVC, CID or equivalent values when necessary for a card-not-present authorisation, but systems and processes must prevent the value from being stored or retained after authorisation.

This means the code must not remain in:

• Call recordings
• Paper notes
• CRM records
• Payment reports
• Emails
• Screenshots
• Chat transcripts
• Spreadsheets
• Customer profiles

MAS insight: “We delete it later” is not a good operating process

The business should design the payment process so the code is never placed into a general business record.

Staff should enter it directly into the approved virtual terminal and allow the payment system to handle the authorisation.

---

Find Your New Processor

Call recording and telephone card payments

Businesses may record calls for:

• Training
• Quality control
• Complaint evidence
• Security
• Regulatory or contractual reasons

However, card information creates additional risk.

The PCI Security Standards Council confirms that card-verification codes must not remain in digital audio recordings after authorisation. It says businesses should make every effort to prevent that information from being recorded and should use suppression or redaction technology.

A practical workflow may be:

1. Tell the customer that the call is being recorded and why.
2. Confirm the customer, invoice and payment amount.
3. Pause, suppress or redact the recording before card details are spoken.
4. Enter the details directly into the virtual terminal.
5. Do not repeat the complete card information aloud.
6. Complete the payment.
7. Resume the recording after the sensitive payment stage.
8. Confirm the transaction result and receipt reference.

The ICO also says organisations monitoring telephone calls must inform callers that recording is taking place.

---

Can card details remain in a call recording?

Sensitive authentication data, including the card-security code, cannot be stored after authorisation.

A recording containing other cardholder data may also place the recording system, storage, retrieval tools and staff access within PCI DSS scope.

Do not assume that removing only the CVV means the remainder of the call-recording environment is automatically outside scope.

The business should assess:

• Recording platform
• Storage
• Encryption
• Access
• Retention period
• Search and playback permissions
• Backups
• Third-party service providers
• Secure deletion
• PCI responsibilities

Where call recording and telephone payments are central to the business, specialist PCI advice may be appropriate.

---

Can a customer email their card details?

Businesses should actively discourage customers from sending unprotected card numbers by:

• Email
• SMS
• WhatsApp
• Live chat
• Internal messaging
• Social media

PCI DSS prohibits sending unprotected primary account numbers through end-user messaging technologies. Where card information is received or transmitted through one of these channels, the channel and associated systems can fall within PCI DSS scope and must meet the applicable security requirements.

Instead, send the customer:

• A secure payment link
• Instructions to telephone the approved payment team
• Access to an authenticated customer portal
• Another provider-approved payment route

What if the customer sends card details unexpectedly?

Do not:

• Forward the message internally
• Copy the details into another email
• Leave the information in the inbox
• Reply quoting the card number
• Process the details through an unapproved device

Follow the business’s security and incident procedure.

That may include:

• Restricting access
• Notifying the relevant security or compliance person
• Securely deleting the message where appropriate
• Recording the incident without copying the card details
• Directing the customer to a secure payment method
• Reviewing whether further reporting is required

---

Do not write card details on paper

Paper card information can also fall within PCI DSS.

Staff should not routinely write card details on:

• Sticky notes
• Order forms
• Notepads
• Printed emails
• Envelopes
• Call sheets

Where the business genuinely receives mail-order forms containing card information, it needs a documented process covering:

• Restricted access
• Physical security
• Processing
• Redaction
• Retention
• Secure destruction
• Treatment of the security code

A form containing a CVV must not simply be filed with the customer order after the payment has been authorised.

---

Does using a virtual terminal make the business PCI compliant?

No.

Using a hosted virtual terminal can reduce the complexity of the technical environment, but it does not remove the merchant’s responsibilities.

PCI SSC says that outsourcing payment processing does not remove the merchant’s PCI DSS responsibilities. The business still needs to confirm that relevant service providers are appropriately compliant, understand how responsibilities are divided and complete the validation process required by its acquirer or payment provider.

The business may still be responsible for:

• Staff processes
• The computer used
• User access
• Call handling
• Paper records
• Email
• Recording systems
• Security policies
• Third-party oversight
• Incident response
• Compliance validation

---

What is SAQ C-VT?

SAQ C-VT is a PCI DSS Self-Assessment Questionnaire designed for certain merchants using a web-based virtual terminal.

The eligibility conditions are relatively narrow.

PCI SSC describes SAQ C-VT as applying where the merchant manually enters one transaction at a time into a hosted virtual terminal and does not store cardholder data electronically.

Its published criteria include:

• Virtual-terminal processing is the only electronic payment processing within that environment.
• The solution is hosted by a PCI DSS-validated third-party provider.
• The virtual terminal is accessed through a computer isolated in a single location.
• The computer does not store card information.
• No attached equipment captures or stores card information.
• The merchant does not otherwise receive or transmit card information electronically.
• The merchant retains only permitted paper reports or paper receipts.
• The merchant does not store cardholder data electronically.

PCI SSC says all the relevant conditions must be met and that the merchant should confirm the correct questionnaire with its acquirer.

Find Your New Processor

MAS insight: Owning a virtual terminal does not guarantee SAQ C-VT eligibility

A business may use a virtual terminal but not meet the SAQ C-VT criteria because it also:

• Accepts ecommerce payments
• Receives card data through email
• Uses several connected systems
• Records calls containing card data
• Stores card numbers electronically
• Processes payments from multiple non-isolated locations
• Uses other software handling card information

Do not select the questionnaire solely from the name.

Confirm the business’s actual payment environment.

---

The computer used for virtual-terminal payments

The device used to enter payments should be treated as a sensitive business system.

Controls may include:

• Supported operating system
• Current security updates
• Anti-malware protection
• Firewall
• Restricted software installation
• Screen lock
• Strong authentication
• Controlled administrator access
• Secure network
• No shared browser profiles
• No automatic storage of card data
• No screenshots
• No clipboard or form-filling tools retaining card numbers
• Restricted physical access

The device should not be used carelessly for:

• Personal email
• Unapproved downloads
• General internet browsing
• Social media
• Uncontrolled remote-access software

The exact controls should reflect the business’s PCI assessment and provider requirements.

---

Can staff use a virtual terminal from home?

Potentially, but it should not be assumed.

The business needs to consider:

• Provider permission
• PCI DSS scope
• The employee’s device
• Home network
• Privacy
• Call recording
• Other people in the property
• Paper notes
• Screen visibility
• Secure disposal
• Remote support
• Incident management

The published SAQ C-VT criteria refer to an isolated computer in a single location. A business processing from several homes or offices may not meet that specific SAQ environment and should confirm its PCI DSS validation requirements with its acquirer or the organisation managing its compliance programme.

Do not permit remote processing simply by sharing the office login with a home worker.

---

Individual staff accounts

Each member of staff should normally have their own login.

This helps the business identify:

• Who submitted a payment
• Who issued a refund
• Who searched a customer
• Who changed a record
• When the activity occurred
• Whether activity was unusual

PCI DSS strongly emphasises individual accountability. Shared credentials are only permitted in tightly controlled exceptional circumstances and must still preserve attribution.

Controls may include:

• Individual usernames
• Strong passwords
• Multi-factor authentication
• Role-based permissions
• Separate refund authority
• Session timeouts
• Failed-login monitoring
• Immediate removal of leavers
• Regular access reviews

---

Refund permissions

Not every member of staff who can take a payment should automatically be able to issue an unlimited refund.

A safer permission structure might separate:

Payment users

Can take payments but cannot issue refunds.

Supervisors

Can issue refunds up to an agreed amount.

Finance or management users

Can authorise larger or exceptional refunds.

The business should monitor:

• Refund amount
• Original transaction
• Customer
• User
• Date
• Reason
• Destination
• Approval

Refunds should normally be linked to the original payment and handled in line with provider rules.

A staff member should not use a refund function to transfer money to an unrelated card.

---

Strong Customer Authentication and virtual terminals

Strong Customer Authentication applies when a payer initiates an electronic payment transaction, unless the relevant legal treatment or exemption applies. The FCA describes SCA as requiring payment providers to verify customers more strongly when they initiate the transaction.

Genuine mail-order and telephone-order payments are generally treated as being initiated non-electronically.

Genuine mail-order and telephone-order payments are generally treated as being initiated non-electronically. However:

Manually keyed does not automatically mean MOTO.

The EBA has specifically addressed the distinction between genuine MOTO and transactions that are simply entered manually. The facts of how the customer initiated the transaction matter, not just the method used by the merchant. 

MAS insight: MOTO is a genuine channel, not an SCA workaround

Do not label a transaction as MOTO merely because:

• Authentication failed
• The amount was high
• The customer is standing in the shop
• Staff want to avoid 3D Secure
• The normal online checkout declined

The payment provider should configure and classify the channel correctly.

Incorrect transaction classification can affect:

• Fraud controls
• Scheme compliance
• Chargeback position
• Provider monitoring
• Account stability

---

Find Your New Processor

Can 3D Secure be used with a virtual terminal?

A conventional manually entered telephone payment may not follow the same authentication journey as an ecommerce payment entered directly by the customer.

Some providers offer related tools such as:

• Payment links
• Hosted pages
• Customer authentication journeys
• Secure call-centre payment technology
• Keypad or IVR solutions

Where authentication is important, the business should ask whether the customer can temporarily move into a secure self-entry journey rather than having the employee manually key the payment.

For example:

1. Staff confirm the invoice and amount.
2. Customer receives a secure payment link.
3. Customer enters their own details.
4. Authentication occurs where required.
5. Staff receive confirmation.

---

Telephone-payment fraud risks

Telephone payments can expose the merchant to risks including:

• Stolen card details
• Identity misrepresentation
• Social engineering
• Fraudulent high-value orders
• Rushed delivery requests
• Customer not being the cardholder
• International fraud
• Repeat attempts across several cards
• Friendly fraud
• Staff misuse

Fraud controls may include:

• Address checks
• Card-security-code result
• Transaction limits
• Customer-history checks
• Delivery controls
• Delayed fulfilment of unusual orders
• Manual review
• Velocity controls
• Device or customer verification through other systems
• Supervisor approval for exceptional payments

No single check guarantees that a transaction is genuine.

---

Warning signs during a telephone payment

Potential warning signs include:

• Customer insists on immediate delivery.
• Several cards are attempted.
• Customer cannot explain the billing relationship.
• Delivery address is unrelated to the cardholder.
• Transaction is much larger than normal.
• Customer is unusually interested in payment limits.
• Caller asks staff to divide one payment into several transactions.
• Caller wants a refund sent elsewhere.
• Customer refuses reasonable verification.
• The order has high resale value.
• The customer pressures a junior employee.

A warning sign does not prove fraud.

It means the transaction may need further review before goods or services are supplied.

---

Do not split payments to avoid controls

A customer may ask staff to divide a £10,000 transaction into:

• Five payments of £2,000
• Several cards
• Repeated smaller transactions

There may be legitimate reasons for using several cards.

However, the business should not split a payment for the purpose of avoiding:

• Provider limits
• Authentication
• Fraud controls
• Approval requirements
• Transaction monitoring

Where several payments genuinely form one order, retain a clear record of the complete commercial transaction.

---

Find Your New Processor

High-value virtual-terminal payments

A provider may place limits on:

• Individual transaction value
• Daily MOTO volume
• Monthly MOTO turnover
• International cards
• Refunds
• Particular products or services

Before taking a payment materially above the normal profile, check:

• Approved maximum transaction
• Customer identity
• Invoice
• Contract
• Delivery or fulfilment
• Fraud indicators
• Provider requirements

A payment being technically approved does not necessarily mean it fits the merchant’s approved processing profile.

For more detail, see the MAS guide to high-value card payments.

---

Why might a virtual-terminal payment be declined?

Possible reasons include:

• Incorrect card number
• Incorrect expiry date
• Incorrect security code
• Address mismatch
• Insufficient available credit
• Issuer fraud control
• Transaction value
• International restriction
• Repeated attempts
• Merchant fraud rules
• Provider limit
• Card not enabled for remote use

Do not repeatedly retry the same payment without understanding the result.

Repeated attempts can:

• Increase authorisation costs
• Trigger issuer controls
• Make fraud harder to identify
• Create customer confusion
• Affect provider monitoring

The customer may need to contact their card issuer or use another legitimate method.

---

Chargebacks and telephone payments

A virtual-terminal payment can still be disputed.

A customer may claim:

• They did not authorise the payment.
• The amount was incorrect.
• Goods were not received.
• Service was not provided.
• The purchase was misrepresented.
• A refund was promised.
• The transaction was duplicated.
• The business charged again without permission.

Useful evidence may include:

• Contract
• Invoice
• Order
• Call record excluding prohibited card data
• Customer correspondence
• Delivery evidence
• Service records
• Payment reference
• Refund information
• Staff notes
• Customer-history information

A successful authorisation confirms that the issuer approved the payment request at that moment.

It does not prove that the customer will never dispute the transaction or that the goods and services were properly delivered.

---

Find Your New Processor

MAS insight: Record the agreement, not the card number

The business record should establish:

• Who was paying
• What they agreed to buy
• Amount
• Invoice
• Date
• Delivery or service terms
• Refund terms
• Employee handling the call

It should not create an unnecessary copy of the customer’s payment credentials.

The strongest evidence is often the commercial record surrounding the transaction rather than a handwritten card number.

---

Can a virtual terminal be used for recurring payments?

A virtual terminal can potentially be used for the initial customer-authorised payment, depending on the provider.

However, manually entering one payment does not automatically give the merchant permission to charge the card again.

The business needs to distinguish between:

• One-off telephone payment
• Saved payment credential
• Continuous payment authority
• Subscription
• Customer-initiated transaction
• Merchant-initiated transaction

A proper recurring-payment setup may require:

• Clear customer consent
• Tokenisation
• Correct initial transaction
• Stored-credential indicators
• Cancellation process
• Advance notices
• Correct later transaction classification

Do not store the card number or security code in a customer record so staff can re-enter it next month.

Use an approved tokenised recurring-payment solution.

See the MAS guide to recurring card payments.

---

Can staff save the card for later?

The virtual terminal should not be used as a reason to maintain an internal list of card information.

Where the business needs to use the credential later, ask the provider for:

• Tokenisation
• Customer vault
• Card-on-file functionality
• Subscription billing
• Merchant-initiated transaction support
• Account updater
• Consent records

The security code must not be stored.

---

Virtual terminals and debt collection

A debt-collection or arrears team may use telephone payments to collect:

• Full balance
• Agreed partial payment
• Settlement amount
• First payment under an arrangement

The process should confirm:

• Customer identity
• Amount
• Authority
• Allocation
• Remaining balance
• Receipt
• Whether another payment is authorised

Staff should not interpret a one-off card payment as consent to take future payments.

Where a regulated consumer-credit activity is involved, additional conduct requirements may apply.

---

Virtual terminals for kitchen and bathroom payments

A kitchen or bathroom business may use a virtual terminal for:

• Remote deposit
• Stage payment
• Variation
• Final balance

However, a payment link may often create a cleaner journey because the customer enters their own information and the payment can be referenced directly to the project.

Where a virtual terminal is used, the employee should confirm:

• Customer
• Project number
• Invoice
• Payment stage
• Amount
• Outstanding balance

For the wider project journey, see Kitchen and Bathroom Payments: Deposits, Staged Payments and Final Balances.

---

Find Your New Processor

International cards and currencies

A provider may allow international cards through the virtual terminal.

Ask:

• Which issuer countries are accepted?
• Which currencies can be processed?
• Which currencies can be settled?
• Does the customer pay in GBP or another currency?
• What international-card charges apply?
• What currency-conversion margin applies?
• How are refunds converted?
• Are particular countries restricted?
• Does the provider require additional verification?

A foreign-issued card paying in GBP may still attract international-card costs.

Do not assume the absence of currency conversion means the card will receive domestic pricing.

---

Virtual-terminal refunds

A virtual terminal may allow:

• Full refund
• Partial refund
• Search by original transaction
• Refund reporting
• User approval limits

The process should confirm:

• Original transaction
• Customer
• Amount
• Reason
• Approver
• Remaining balance
• Settlement impact

Do not issue a refund to a different card merely because the caller requests it.

That can create:

• Fraud
• Money-laundering concerns
• Reconciliation problems
• Provider breaches
• Duplicate customer claims

Follow the provider’s refund process and business policy.

---

Partial refunds

Suppose the original payment was:

£2,000

The customer receives a refund of:

£300

The business record should show:

The refund should also be linked to:

• Invoice
• Order
• Reason
• Customer communication
• Provider settlement

---

Virtual-terminal payment references

Every payment should contain a meaningful reference.

For example:

Invoice 10482 – final balance

or:

Project K334 – stage two

Avoid references such as:

Telephone payment

A useful reference helps:

• Customer-service staff
• Accounts
• Settlement reconciliation
• Refunds
• Dispute evidence
• Provider investigations

Do not include unnecessary sensitive information in the payment reference.

---

Integrating a virtual terminal with a CRM

A standalone virtual terminal may require staff to copy the transaction result into:

• CRM
• Accounting software
• Booking system
• Case-management system
• Order system

An integrated solution may allow the payment to be initiated from the customer record.

The workflow could be:

Staff open customer invoice

↓

Payment amount is populated

↓

Staff enter the card information into the secure payment interface

↓

Transaction result returns to the customer record

↓

Invoice is marked as paid

↓

Receipt is issued

This can reduce:

• Incorrect amounts
• Duplicate payments
• Wrong customer allocation
• Manual reconciliation
• Unclear audit trails

Integration does not remove the need to assess PCI DSS scope.

---

Reconciliation

The business should be able to reconcile:

Virtual-terminal transactions

↓

Refunds and chargebacks

↓

Processing fees

↓

Reserves or adjustments

↓

Provider payout

↓

Business bank account

↓

Customer invoice

Useful fields include:

• Transaction ID
• Customer or order reference
• Gross amount
• Date and time
• User
• Currency
• Status
• Refund
• Chargeback
• Net settlement

For more detail, see the MAS guide to card-payment settlement times.

---

Find Your New Processor

Are virtual-terminal payments more expensive?

They can be priced differently from card-present transactions because they are manually entered card-not-present payments.

Possible charges include:

• Percentage transaction fee
• Fixed authorisation fee
• Monthly virtual-terminal fee
• Gateway fee
• User fee
• International-card cost
• Refund fee
• Chargeback fee
• Monthly minimum
• Fraud service

There is no universal UK virtual-terminal rate.

Pricing depends on:

• Provider
• Turnover
• Transaction count
• Average transaction
• Sector
• Fraud
• Chargebacks
• Customer countries
• Contract
• Other services

Compare the complete expected cost rather than one headline percentage.

---

Worked cost example

Suppose a business processes:

Monthly virtual-terminal turnover: £100,000
Successful payments: 1,000
Authorisation attempts: 1,200

Illustrative pricing:

• 1.2% processing
• 5p per authorisation
• £25 monthly virtual-terminal fee

The simplified cost would be:

Effective rate:

£1,285 ÷ £100,000 × 100 = 1.285%

The actual cost could also include:

• International cards
• Refunds
• Chargebacks
• PCI-related fees
• Monthly minimums
• Currency conversion

---

What will a provider ask?

A provider may request:

Business

• Legal company
• Website
• Products or services
• Trading history
• Owners and directors
• Financial information

Payment profile

• Monthly MOTO turnover
• Transaction count
• Average transaction
• Maximum transaction
• Customer countries
• Card mix
• International-card percentage
• Refunds
• Chargebacks
• Fraud

Operation

• Number of staff
• Number of locations
• Office or home working
• Call recording
• CRM
• Current PCI process
• How card information is received
• Refund controls
• Delivery or fulfilment
• Existing provider

Requirements

• Virtual terminal
• Payment links
• Recurring payments
• Tokenisation
• Integration
• Multi-currency processing
• Reporting
• User permissions

A provider may approve one payment channel while restricting another.

The application should describe the complete operating process.

---

Find Your New Processor

Questions to ask a virtual-terminal provider

Payment processing

1. Which card types are supported?
2. Are commercial and international cards supported?
3. Which currencies can be processed?
4. What is the maximum transaction?
5. Are payments classified as MOTO?
6. Can payment links also be provided?

Security

7. Is multi-factor authentication available?
8. Does every employee have an individual user?
9. Can user permissions be restricted?
10. Can refund rights be separated?
11. What device and browser requirements apply?
12. What fraud controls are available?

PCI DSS

13. Is the provider PCI DSS validated for the service?
14. Which SAQ may apply?
15. What responsibilities remain with the merchant?
16. Does the provider supply PCI support?
17. How should recorded calls be handled?
18. Can the service be used from home?

Features

19. Are partial refunds supported?
20. Can receipts be emailed?
21. Can an invoice reference be recorded?
22. Can the service integrate with our CRM?
23. Can reports be exported?
24. Is tokenisation available?
25. Can recurring payments be configured properly?

Pricing

26. What percentage applies?
27. Is there a fixed authorisation charge?
28. Are declined attempts charged?
29. Is there a monthly fee?
30. Is there a minimum monthly charge?
31. What are the refund and chargeback fees?
32. Are international cards priced differently?

Contract and settlement

33. What is the settlement timetable?
34. Is a reserve required?
35. What is the initial contract term?
36. What notice is required?
37. What happens if the account closes?

---

Virtual-terminal security checklist

Before going live, confirm:

• Business and MOTO activity approved
• Maximum transaction approved
• PCI validation route confirmed
• Provider compliance checked
• Individual user accounts created
• Multi-factor authentication enabled
• Refund permissions restricted
• Device security reviewed
• Call-recording process documented
• Recording suppression or redaction tested
• Staff trained not to write down card data
• Email and messaging policy in place
• Secure-payment-link alternative available
• Customer consent and transaction purpose recorded
• Payment references standardised
• Refund process tested
• Reconciliation tested
• Leaver-access process documented
• Incident response documented

---

Changing virtual-terminal provider

Before switching and closing the existing service, confirm that the replacement is:

• Fully underwritten
• Contracted
• Configured
• PCI-reviewed
• User-tested
• Ready to settle
• Ready to refund
• Integrated where required

Plan for:

• Historic refunds
• Chargebacks
• Access to previous transactions
• Downloading reports
• Existing tokens
• Recurring payments
• Customer receipts
• Staff training
• Old user accounts
• Final settlements
• Reserve releases

A new virtual terminal does not automatically provide access to transactions processed through the old provider.

---

Looking for a virtual terminal?

Tell Merchant Advice Service:

• What the business sells
• Monthly telephone-payment turnover
• Number of payments
• Average transaction
• Maximum transaction
• Current provider
• Number and location of staff
• Whether calls are recorded
• How card details are currently received
• Refund and chargeback history
• Customer countries
• International-card requirements
• One-off or recurring-payment requirements
• Payment-link requirements
• CRM or accounting integration
• Current PCI process
• What is not working

MAS can help you:

• Explain the business and telephone-payment journey
• Identify information a provider may request
• Compare virtual terminals and payment-link options
• Consider potentially relevant providers
• Review pricing, settlement and reserve questions
• Prepare a clearer provider application

Merchant Advice Service cannot guarantee:

• Merchant-account approval
• A particular card rate
• Chargeback protection
• A specific settlement timetable
• That a virtual terminal will reduce PCI DSS scope
• That every provider in the market will be compared

Final underwriting, PCI validation requirements, pricing, fraud controls and contractual terms remain with the relevant provider and compliance-accepting organisation.

---