Manual card payments allow businesses to accept debit and credit card payments when the customer is not completing a conventional online checkout or presenting their card at a physical terminal. They are commonly processed using a virtual terminal as a Mail Order / Telephone Order (MOTO) transaction. Manual payments can be useful for telephone sales, B2B collections, deposits, call centres and remote transactions, but businesses need to consider PCI DSS, fraud, chargebacks, transaction costs and whether a more automated payment method would be better at higher volumes.
MAS View: Manual card processing is not simply “typing a card number into a terminal”. The important decision is whether manual entry is the right payment channel for the transaction, and whether the business has the security, provider setup and operational controls to use it safely.
What is a manual card payment?
A manual card payment is a transaction where card details are entered manually into a payment system rather than being read directly from a physical card or entered by the customer through a conventional ecommerce checkout.
For businesses, this will usually mean using a virtual terminal supplied by a payment provider.
A common example is a customer calling a business to make a payment. An authorised member of staff accesses the secure virtual terminal, enters the card details supplied by the customer and submits the transaction for authorisation.
Telephone and postal card transactions are commonly referred to as MOTO — Mail Order / Telephone Order payments.
Manual payments form part of the wider card-not-present payment environment because the physical card is not being read by a payment terminal.
Manual card payments, MOTO and virtual terminals: what is the difference?
The terms are often used interchangeably, but they describe different parts of the payment process.
| Term | What it means | Typical example |
| Manual card payment |
A broad description of a transaction where card details are entered manually rather than read from the card. |
A member of staff entering card details into a secure payment interface. |
| MOTO |
Mail Order / Telephone Order. A card-not-present transaction where the merchant receives payment details remotely and initiates the transaction. |
A customer pays an invoice over the telephone. |
| Virtual terminal |
A secure browser-based payment interface supplied by an acquirer, processor or payment provider into which the merchant manually enters card data. |
A receptionist logs into a provider portal and processes a telephone payment. |
| Payment link |
A link sent to the customer so that the customer enters their own payment details into a hosted payment page. |
A business emails or texts a secure payment link after issuing an invoice. |
| Online checkout |
A customer-facing ecommerce payment journey integrated into a website, app or booking system. |
A customer completes checkout on an ecommerce website. |
The distinction matters because the fraud controls, authentication process, PCI responsibilities and provider pricing may differ depending on how the payment is taken.
Find Your New Processor
How does a virtual terminal work?
A virtual terminal replaces the card-reading function of a physical terminal with a secure browser-based interface.
An authorised employee typically:
- logs into the payment provider's virtual terminal;
- enters the transaction value;
- enters the customer's card information;
- provides any additional information required by the provider;
- identifies the transaction correctly as MOTO where appropriate; and
- submits the payment for authorisation.
The transaction is then sent through the payment-provider and card-network infrastructure for an authorisation decision.
A virtual terminal should not be confused with a physical card machine. The customer's card is not inserted, tapped or swiped and the terminal does not electronically read the card.
What businesses use manual card payments?
Manual payment facilities remain useful where a business legitimately needs to collect payments remotely without asking the customer to complete an ecommerce checkout.
Common examples include:
- telephone sales and reservations;
- hotel or hospitality bookings;
- deposits and balance payments;
- B2B invoice collections;
- professional-services businesses;
- medical, dental and other appointment-led businesses;
- travel bookings;
- call centres;
- membership organisations;
- remote customer-service teams; and
- businesses taking occasional payments where a full ecommerce integration is unnecessary.
However, the fact that a business can use a virtual terminal does not mean every remote payment should be processed manually.
The MAS Remote Payment Test
Before choosing a manual-payment setup, Merchant Advice Service recommends assessing seven areas:
Channel → Volume → Transaction Value → Security → Recurrence → Integration → Provider Fit
| Area | What to consider |
| Channel |
Why is the payment being taken manually rather than through a terminal, checkout or payment link? |
| Volume |
How many manually keyed transactions will staff process each day or month? |
| Transaction Value |
What are the average and maximum payment amounts, and what financial exposure could a dispute create? |
| Security |
How are card details received, entered and prevented from being stored or recorded unnecessarily? |
| Recurrence |
Is the payment genuinely one-off, or should the business use a proper recurring-payment or stored-credential solution? |
| Integration |
Does the payment need to connect with CRM, booking, invoicing, accounting or other business systems? |
| Provider Fit |
Does the provider support the business sector, MOTO model, transaction values, geography and required controls? |
MAS View: The right remote-payment method should reduce manual work and card-data exposure rather than introduce it unnecessarily. As payment volume grows, businesses should regularly reassess whether a virtual terminal is still the most appropriate solution.
Are manual card payments secure?
They can be, when processed through an appropriate payment solution with suitable security controls.
However, manual card payments create additional considerations because an employee may hear, see or enter cardholder information that the merchant would not ordinarily handle during a standard customer-led ecommerce checkout.
This makes process design particularly important.
Businesses should consider:
- who is authorised to take telephone or manual payments;
- where payments can be processed;
- whether telephone calls are recorded;
- whether card information can accidentally enter CRM notes, emails, spreadsheets or messaging systems;
- how access to the virtual terminal is controlled;
- staff training;
- provider fraud controls; and
- the business's wider PCI DSS responsibilities.
Can businesses store CVV or CVC numbers?
No.
The card verification value — commonly referred to as CVV, CVC, CID or similar depending on the card brand — is sensitive authentication data.
PCI DSS prohibits businesses from storing the card verification value after the transaction has been authorised, even if it is encrypted.
This is particularly important for businesses taking payments over the telephone.
If calls are recorded, businesses need to consider whether card-security information could be captured in those recordings and put appropriate controls in place to prevent or remove prohibited data.
Card details should also not simply be written down, copied into a CRM, placed in an email or retained for future use because it seems operationally convenient.
What is the difference between MOTO and an ecommerce payment?
Both are card-not-present transactions, but the customer journey is different.
In a conventional ecommerce transaction, the customer normally enters their own payment information into a checkout or hosted payment page.
In a genuine MOTO transaction, the merchant receives the payment information remotely — typically over the telephone or by mail — and initiates the payment on the customer's behalf.
This distinction affects how the transaction is identified and authenticated.
For example, 3D Secure does not operate on genuine MOTO payments in the same way it does on customer-initiated ecommerce transactions.
Businesses should not simply classify ecommerce transactions as MOTO to bypass authentication requirements. The payment channel needs to reflect the way the transaction was genuinely initiated.
Should businesses use a virtual terminal or payment link?
Increasingly, this is one of the most useful questions to ask.
A payment link allows the customer to enter their own payment information into a secure hosted payment page. This can reduce the amount of card information handled directly by employees.
A virtual terminal may still be preferable where:
- the customer genuinely wants to pay during a telephone conversation;
- the payment needs to be completed immediately;
- the business operates a telephone-sales or contact-centre environment;
- customers may struggle to complete a separate digital payment journey; or
- the merchant has a specific operational requirement for MOTO processing.
A payment link may be preferable where:
- the customer can comfortably enter their own card details;
- the business wants to reduce manual card-data handling;
- payments originate from invoices, emails, SMS or digital communication;
- staff do not need to complete the transaction on the customer's behalf; or
- manual processing is becoming operationally inefficient.
Are manual card payments more expensive?
They can be.
Businesses should not assume that a MOTO or manually keyed transaction will be priced identically to a standard ecommerce or card-present transaction.
The overall cost can depend on:
- merchant sector;
- card type;
- domestic or international cards;
- transaction values;
- monthly processing volume;
- provider pricing structure;
- gateway or virtual-terminal charges;
- fraud and chargeback profile; and
- the acquiring arrangement supporting the transactions.
Merchants comparing providers should assess the total payment cost rather than only the advertised percentage transaction rate. Our UK payment gateway fees guide explains the wider costs that may sit within an online or remote-payment arrangement.
Do manual card payments take longer to settle?
Not necessarily.
The act of manually entering a payment does not automatically mean that settlement will take several days longer than another card transaction.
Settlement timing is determined by the merchant's provider and acquiring arrangement, including the agreed settlement schedule and any risk controls applied to the account.
Some businesses may have longer settlement periods, reserves or other conditions because of their sector or risk profile, but these should not be confused with the time taken to key the transaction manually.
What are the fraud and chargeback risks with MOTO payments?
Because MOTO is a card-not-present environment, merchants need to consider fraud and disputes carefully.
Potential issues include:
- stolen card details;
- customers later disputing that they authorised a telephone payment;
- staff entering card details incorrectly;
- limited authentication compared with some customer-led ecommerce transactions;
- high-value transactions creating greater financial exposure; and
- inadequate records of what the customer purchased or agreed to.
Good operational controls can include clear order records, customer communications, appropriate refund policies, accurate transaction descriptions and provider fraud tools.
Businesses experiencing significant disputes should also review our guide to reducing chargebacks.
Find Your New Processor
Can a virtual terminal be used for recurring payments?
A merchant may initially take a customer payment manually, but repeatedly re-entering the customer's card details is not usually an appropriate long-term recurring-payment strategy.
If a business needs to collect regular payments, it should discuss proper recurring-payment, card-on-file or subscription functionality with its provider.
This allows the relationship between the initial transaction and subsequent payments to be managed more appropriately and reduces the temptation to retain sensitive information unnecessarily.
Businesses operating subscriptions should review our guide to subscription payment processing.
What about telephone payments in a call centre?
High-volume telephone-payment environments require more thought than simply giving every employee access to a virtual terminal.
Businesses may need to consider:
- call recording and suppression of sensitive payment information;
- role-based employee access;
- transaction limits;
- fraud monitoring;
- audit trails;
- integration with customer-service or CRM systems;
- secure IVR payment options; and
- how card data moves through the wider technical environment.
Where payment volume is significant, an IVR payment solution or integrated remote-payment workflow may reduce the need for employees to hear or manually handle card information.
When has a business outgrown manual card processing?
Manual payments are useful because they are flexible. That flexibility can also hide operational inefficiency.
A business should review its setup where:
- employees are manually entering large numbers of transactions;
- customers regularly need to call simply to make payments;
- payment information is being moved between several systems;
- staff are copying payment information from invoices, emails or CRM records;
- manual errors are increasing;
- payments need to reconcile automatically against invoices or bookings;
- the business is moving towards recurring billing;
- payment volumes have grown significantly; or
- PCI scope and card-data handling have become difficult to manage.
At that point, the question may no longer be “Which virtual terminal should we use?”
It may be:
“How should remote payments fit into our wider payment infrastructure?”
That could involve payment links, hosted payment pages, IVR, APIs or a more integrated payments solution.
How should businesses compare virtual terminal and MOTO providers?
Businesses should compare more than the headline transaction rate.
The MAS Virtual Terminal Provider Checklist
| Question | Why it matters |
| Does the provider support MOTO for our sector? |
Provider and acquiring appetite can vary by business type and payment channel. |
| Are our transaction values acceptable? |
High average or maximum values can affect underwriting and controls. |
| What are the complete transaction costs? |
Consider percentage fees, authorisation charges, virtual-terminal fees and other account costs. |
| What fraud tools are available? |
Card-not-present transactions require appropriate risk controls. |
| What is the settlement schedule? |
Cash-flow requirements vary considerably between businesses. |
| Does it support our countries and currencies? |
International card acceptance may affect both pricing and provider suitability. |
| Can it support payment links, recurring billing or IVR? |
The business may need more than one remote-payment channel. |
| Can it integrate with our existing systems? |
Growing businesses may need payments connected with CRM, accounting, booking or ERP systems. |
| What PCI support is provided? |
The provider should be able to explain how its solution affects the merchant's PCI responsibilities. |
| Can the arrangement scale? |
A system suitable for occasional telephone payments may become inefficient at significantly higher volume. |
MAS View: The best virtual-terminal arrangement is not necessarily the provider with the lowest keyed-transaction rate. Businesses should compare security, provider appetite, settlement, fraud controls, operational fit and the ability to move towards more automated payment channels as they grow.
How Merchant Advice Service can help
Merchant Advice Service helps businesses compare payment providers based on how they actually take payments.
For businesses requiring virtual-terminal or MOTO capability, relevant factors may include:
- business sector;
- monthly card turnover;
- average and maximum transaction values;
- percentage of payments taken by telephone;
- domestic and international activity;
- previous processing history;
- fraud and chargeback levels;
- settlement requirements;
- other payment channels required; and
- integration requirements.
Merchant Advice Service does not make underwriting decisions. The payment provider or acquirer ultimately determines whether it will accept the business and on what commercial and risk terms.
Find Your New Processor
Related Merchant Advice Service Guidance
Sources & Further Reading
- PCI Security Standards Council — Virtual Payment Terminal definition and guidance.
- PCI Security Standards Council — PCI DSS guidance on card-verification codes and sensitive authentication data.
- PCI Security Standards Council — guidance on sensitive authentication data in telephone-call recordings.
- PCI Security Standards Council — PCI DSS v4.0.1.
- GOV.UK Pay — Mail Order / Telephone Order payment guidance.
Editorial & Commercial Disclosure
Merchant Advice Service provides independent information and guidance about merchant accounts, card processing and payment-provider selection. We are not a payment processor, acquirer or card scheme.
MAS may receive a commission or referral fee from some payment providers where a business proceeds following an introduction. This does not determine the educational content, comparison principles or provider-selection framework used in this guide.
Payment-provider acceptance, pricing, settlement, fraud controls and MOTO availability are subject to individual provider and acquirer underwriting. PCI DSS requirements depend on the merchant's specific payment environment and should be confirmed with the relevant provider or qualified PCI professional where necessary.