Written or reviewed by Libby James, founder of Merchant Advice Service and specialist in merchant payments and complex provider requirements.
Tell us about your business, current payment setup and what you're looking to change. We'll use it to understand your requirements before identifying providers that may be suitable.
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:
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:
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.
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:
The exact features depend on the provider.
Using a virtual terminal does not automatically mean:
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:
The safest practical workflow normally moves the information directly from the customer into the approved payment interface without creating a second copy.
These payment methods can both be used remotely, but the customer journey is different.
| Virtual terminal | Payment link |
|---|---|
| Staff enter the card details | Customer enters their own card details |
| Merchant staff may hear or receive card information | Staff do not normally handle the raw card details |
| Usually used for manually entered remote payments | Usually follows an ecommerce-style payment journey |
| Authentication options may be more limited | May support 3D Secure and customer authentication |
| Useful where the customer cannot use a link | Often preferable where the customer can use email or SMS |
| Requires strong staff, call and device controls | Can reduce the merchant’s direct card-data handling |
| Payment is processed during the conversation | Customer may complete it in their own time |
| Staff immediately see the result | Merchant receives confirmation when the link is completed |
A payment link is not automatically appropriate for every customer.
Some customers may:
Likewise, a virtual terminal should not be used automatically merely because it is convenient for the member of staff.
A sensible order is:
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.
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:
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:
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 telephone payment | Payment link |
|---|---|---|
| Staff manually enter the card details | Customer enters details using the telephone keypad | Customer enters details online |
| Staff may hear or receive the details | Properly configured systems can prevent staff hearing or seeing them | Staff do not normally handle the details |
| Payment is completed by the employee | Payment is completed through the telephone-payment system | Payment is completed through a hosted online page |
| Useful for staff-assisted payments | Useful for call centres and telephone-led businesses | Useful where the customer can access email or SMS |
| Call, staff and device controls are important | Telephony, DTMF masking and provider controls are important | Website, link delivery and customer authentication are important |
| May involve broader staff exposure to card information | Can reduce staff exposure when properly implemented | Can reduce direct telephone card-data handling |
Not automatically.
The result depends on:
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.
Ask:
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:
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:
A virtual terminal normally involves:
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.
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:
Simply receiving access to a virtual-terminal screen does not mean every type or value of MOTO payment has been approved.
Virtual terminals can suit businesses such as:
Possible use cases include:
The provider must still approve the business activity, payment channel and transaction profile.
A payment link may be more suitable where:
For more detail, see the MAS guide to Pay by Link payments.
Depending on the provider and transaction, the member of staff may be asked for:
Only collect information required for the transaction and approved business process.
Do not ask the customer for:
A card PIN should not be requested for a telephone payment.
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:
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.
Businesses may record calls for:
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:
The ICO also says organisations monitoring telephone calls must inform callers that recording is taking place.
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:
Where call recording and telephone payments are central to the business, specialist PCI advice may be appropriate.
Businesses should actively discourage customers from sending unprotected card numbers by:
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:
Do not:
Follow the business’s security and incident procedure.
That may include:
Paper card information can also fall within PCI DSS.
Staff should not routinely write card details on:
Where the business genuinely receives mail-order forms containing card information, it needs a documented process covering:
A form containing a CVV must not simply be filed with the customer order after the payment has been authorised.
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:
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:
PCI SSC says all the relevant conditions must be met and that the merchant should confirm the correct questionnaire with its acquirer.
A business may use a virtual terminal but not meet the SAQ C-VT criteria because it also:
Do not select the questionnaire solely from the name.
Confirm the business’s actual payment environment.
The device used to enter payments should be treated as a sensitive business system.
Controls may include:
The device should not be used carelessly for:
The exact controls should reflect the business’s PCI assessment and provider requirements.
Potentially, but it should not be assumed.
The business needs to consider:
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.
Each member of staff should normally have their own login.
This helps the business identify:
PCI DSS strongly emphasises individual accountability. Shared credentials are only permitted in tightly controlled exceptional circumstances and must still preserve attribution.
Controls may include:
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:
Can take payments but cannot issue refunds.
Can issue refunds up to an agreed amount.
Can authorise larger or exceptional refunds.
The business should monitor:
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 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.
Do not label a transaction as MOTO merely because:
The payment provider should configure and classify the channel correctly.
Incorrect transaction classification can affect:
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:
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:
Telephone payments can expose the merchant to risks including:
Fraud controls may include:
No single check guarantees that a transaction is genuine.
Potential warning signs include:
A warning sign does not prove fraud.
It means the transaction may need further review before goods or services are supplied.
A customer may ask staff to divide a £10,000 transaction into:
There may be legitimate reasons for using several cards.
However, the business should not split a payment for the purpose of avoiding:
Where several payments genuinely form one order, retain a clear record of the complete commercial transaction.
A provider may place limits on:
Before taking a payment materially above the normal profile, check:
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.
Possible reasons include:
Do not repeatedly retry the same payment without understanding the result.
Repeated attempts can:
The customer may need to contact their card issuer or use another legitimate method.
A virtual-terminal payment can still be disputed.
A customer may claim:
Useful evidence may include:
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.
The business record should establish:
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.
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:
A proper recurring-payment setup may require:
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.
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:
The security code must not be stored.
A debt-collection or arrears team may use telephone payments to collect:
The process should confirm:
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.
A kitchen or bathroom business may use a virtual terminal for:
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:
For the wider project journey, see Kitchen and Bathroom Payments: Deposits, Staged Payments and Final Balances.
A provider may allow international cards through the virtual terminal.
Ask:
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.
A virtual terminal may allow:
The process should confirm:
Do not issue a refund to a different card merely because the caller requests it.
That can create:
Follow the provider’s refund process and business policy.
Suppose the original payment was:
£2,000
The customer receives a refund of:
£300
The business record should show:
| Item | Amount |
|---|---|
| Original virtual-terminal payment | £2,000 |
| Partial refund | £300 |
| Net retained amount | £1,700 |
The refund should also be linked to:
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:
Do not include unnecessary sensitive information in the payment reference.
A standalone virtual terminal may require staff to copy the transaction result into:
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:
Integration does not remove the need to assess PCI DSS scope.
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:
For more detail, see the MAS guide to card-payment settlement times.
They can be priced differently from card-present transactions because they are manually entered card-not-present payments.
Possible charges include:
There is no universal UK virtual-terminal rate.
Pricing depends on:
Compare the complete expected cost rather than one headline percentage.
Suppose a business processes:
Monthly virtual-terminal turnover: £100,000
Successful payments: 1,000
Authorisation attempts: 1,200
Illustrative pricing:
The simplified cost would be:
| Cost | Amount |
|---|---|
| Percentage fee: £100,000 × 1.2% | £1,200 |
| Authorisations: 1,200 × 5p | £60 |
| Monthly virtual-terminal fee | £25 |
| Total before other charges | £1,285 |
Effective rate:
£1,285 ÷ £100,000 × 100 = 1.285%
The actual cost could also include:
A provider may request:
A provider may approve one payment channel while restricting another.
The application should describe the complete operating process.
Before going live, confirm:
Before switching and closing the existing service, confirm that the replacement is:
Plan for:
A new virtual terminal does not automatically provide access to transactions processed through the old provider.
Tell Merchant Advice Service:
MAS can help you:
Merchant Advice Service cannot guarantee:
Final underwriting, PCI validation requirements, pricing, fraud controls and contractual terms remain with the relevant provider and compliance-accepting organisation.
Merchant Advice Service provides free, independent guidance to businesses looking for help with card payments, payment gateways and more complex payment requirements.
Where appropriate, MAS may introduce a business to a relevant payment provider. We may receive a referral fee or commission if an introduction results in a completed account or service.
MAS does not necessarily compare every provider in the market, and all applications remain subject to the relevant provider’s own assessment, underwriting and approval.
This article provides general payments and security information. It does not constitute legal, regulatory, data-protection, PCI DSS or information-security advice. PCI validation, transaction classification, fraud controls, pricing and provider requirements vary according to the business, payment environment and contractual arrangements.
Choose an area below and we'll take you to the relevant guide, where you can understand your options and find suitable providers.
Understand merchant accounts, acquiring and card processing options.
Online payments, ecommerce, recurring payments and complex integrations.
Explore options for taking face-to-face card payments.
Explore EPOS, POS and integrated payment setups for your business.
Guidance for businesses with more complex underwriting or payment requirements.
Explore business funding linked to your card sales.
Tell us how your business takes payments and what you're looking to change. We'll use your answers to understand your requirements and identify providers that may be suitable.
Merchant Advice Service helps businesses understand their payment requirements before approaching providers.
How Merchant Advice Service works →If your business already takes card payments, you may be able to access funding linked to your future card sales.
Explore merchant cash advance →Tell us about your business, how you take payments and what you're looking to change. We'll use your answers to identify providers that may be suitable.
Libby James is the founder and Managing Director of Merchant Advice Service. Since 2016, she has worked directly with businesses and payment providers across merchant accounts, card processing, payment gateways and complex provider requirements.
Libby specialises in high-risk, declined and harder-to-place merchants, as well as businesses requiring specialist payment methods, integrations or international support. She writes and reviews Merchant Advice Service content, drawing on practical experience gained from real merchant enquiries and provider relationships.
