Card-not-present payments cover much more than conventional ecommerce.
A business might take a remote card payment through an online checkout, a payment link, a virtual terminal, over the telephone, through an app or as part of a recurring-payment arrangement.
All of these can involve the cardholder and their physical card being somewhere other than the merchant's point of sale, but they do not necessarily have the same:
- payment journey;
- authentication requirements;
- fraud exposure;
- PCI DSS considerations;
- provider requirements;
- interchange treatment; or
- processing costs.
Understanding the type of card-not-present transaction you are actually processing is therefore more useful than simply describing all remote payments as CNP.
This guide explains the main card-not-present payment types, how they differ, what businesses should consider when comparing providers and where more specialist payment arrangements may be required.
What is a card-not-present transaction?
A card-not-present, or CNP, transaction is a card payment where the payment is processed without the card being read through a conventional face-to-face card-present transaction.
Common examples include:
- online ecommerce payments;
- telephone card payments;
- mail-order payments;
- virtual terminal transactions;
- payment links;
- cards stored for future use;
- subscription and recurring card payments;
- payments made through mobile apps; and
- some invoicing and remote-payment journeys.
The way the card details are collected and who initiates the transaction can be important.
For example, a customer entering their own card details into a secure online checkout presents a different payment journey from an employee typing card details into a virtual terminal during a telephone call.
Card-present vs card-not-present payments
In a conventional card-present transaction, the card or payment device interacts with the merchant's payment acceptance technology.
Examples include:
- Chip & PIN;
- contactless cards;
- Apple Pay or Google Pay at a physical terminal; and
- Tap to Pay arrangements where the customer's payment credential is captured as a card-present transaction.
Card-not-present payments happen remotely and require a different way of transmitting and authenticating payment information.
That distinction can affect:
- fraud controls;
- authentication;
- chargeback exposure;
- pricing;
- provider underwriting; and
- PCI DSS scope.
It is therefore important that the payment provider understands how customers actually pay rather than simply being told that the business takes card payments.
The main types of card-not-present payment
A CNP setup can fall into several different payment journeys.
Ecommerce: the customer enters their own payment details through an online checkout.
MOTO: the merchant receives payment instructions remotely, commonly by telephone, and processes the payment through an approved MOTO facility.
Virtual terminal: an authorised member of staff manually enters the customer's card details into a secure browser-based payment interface.
Payment link: the business sends the customer a link and the customer enters their own payment details on a hosted payment page.
Recurring or card-on-file: card credentials are stored or tokenised so that authorised future payments can be processed without the customer re-entering their card details every time.
These payment types should not automatically be treated as interchangeable. The most appropriate setup depends on how the customer authorises the payment and how the business needs to collect it.
Ecommerce card-not-present payments
Ecommerce is probably the most familiar CNP environment.
The customer normally selects goods or services, reaches an online checkout and enters or selects their payment credentials themselves.
The payment gateway then connects that checkout with the wider card-processing infrastructure.
A business choosing an ecommerce setup may need to consider:
- website or ecommerce platform;
- gateway integration;
- merchant acquiring;
- 3D Secure;
- Strong Customer Authentication;
- fraud screening;
- international customers;
- currencies;
- alternative payment methods;
- subscriptions;
- tokenisation; and
- settlement and reconciliation.
Businesses building or changing an online checkout can start with our Payment Gateway guide or explore payment gateway providers .
Telephone and MOTO card payments
Mail Order / Telephone Order, usually shortened to MOTO, is another form of card-not-present processing.
A typical example is a customer calling a business and providing card details so an employee can process the payment through an approved facility.
MOTO can be useful for businesses such as:
- professional services;
- travel businesses;
- hotels;
- healthcare providers;
- wholesalers;
- business-to-business suppliers;
- call centres; and
- companies collecting invoice payments by telephone.
MOTO should not simply be created by taking an ecommerce payment journey and asking staff to enter the customer's card details into it.
The provider should know that the business intends to take telephone or mail-order payments and configure the merchant facility appropriately.
Businesses relying significantly on telephone payments should read our dedicated MOTO Merchant Accounts guide .
Virtual terminal and manually entered card payments
A virtual terminal is a secure online interface that allows an authorised user to enter card details manually.
It can be useful where the business needs to take payments remotely but does not require the customer to complete an ecommerce checkout.
Common examples include:
- telephone payments;
- invoice collection;
- occasional remote card payments;
- business-to-business payments; and
- back-office payment collection.
However, manually handling card information creates different data-security considerations from sending the customer to a hosted payment page.
Our Manual Card Payments guide explains virtual terminals, MOTO and secure manual payment processing in more detail.
Payment links
Payment links provide another way to take a card-not-present payment without asking staff to collect card details themselves.
The merchant creates a payment request and sends the customer a link, commonly by:
- email;
- SMS;
- messaging service;
- invoice;
- CRM; or
- another customer communication channel.
The customer follows the link and enters their own payment details on a secure online payment page.
This creates a different payment journey from MOTO because the customer, rather than the merchant's employee, enters the card details.
See our guide to Pay by Link for merchants for the differences between payment links, MOTO and virtual terminals.
Recurring and card-on-file payments
Some businesses need permission to charge the same card again in the future.
Examples include:
- subscriptions;
- memberships;
- repeat bookings;
- instalments;
- usage-based billing;
- account customers; and
- other recurring-payment models.
These transactions are card-not-present, but the way they are processed can differ from an ordinary one-off ecommerce purchase.
The initial customer authorisation, stored-credential setup, recurring-payment rules and subsequent merchant-initiated transactions all need to be configured correctly with the payment provider.
Businesses should therefore tell a prospective provider if recurring payments or stored cards form part of the payment model rather than assuming any ecommerce gateway will automatically support the required arrangement.
Not sure which CNP setup your business needs?
A business taking ecommerce payments, payment links, telephone payments and recurring cards may need a very different provider setup from a company using only one remote-payment channel.
Merchant Advice Service can help you map the payment requirement before identifying providers that may be suitable.
Get personalised recommendations
Are CNP payments more expensive?
They can be, but it is too simplistic to say that every card-not-present transaction always carries a particular premium.
The actual cost of a card payment can depend on factors including:
- card type;
- consumer or commercial card;
- domestic or international card;
- payment channel;
- transaction classification;
- merchant sector;
- monthly processing volume;
- average transaction value;
- interchange;
- scheme fees;
- acquirer pricing;
- gateway charges;
- fraud tools; and
- the provider's pricing model.
Some providers publish different prices for online and face-to-face payments. Businesses on negotiated interchange-plus or IC++ arrangements may instead see the different components of the transaction reflected more directly in their statements.
The right comparison is therefore the complete cost of the payment setup, not simply whether the transaction is labelled card-present or card-not-present.
Our UK Merchant Fees Benchmark explains interchange, provider pricing and wider card-processing costs in more detail.
Strong Customer Authentication and 3D Secure
Online card payments can also be affected by Strong Customer Authentication, commonly referred to as SCA.
UK SCA requirements sit within the Payment Services Regulations 2017 and related technical standards.
For ecommerce card payments, 3D Secure is one of the main technologies used to support cardholder authentication.
A modern online payment journey may therefore involve:
- 3D Secure;
- frictionless authentication;
- customer challenges where required;
- exemptions where applicable;
- issuer decisions;
- transaction-risk analysis; and
- soft declines where further authentication is required.
Not every CNP transaction should be treated identically for SCA purposes.
Recurring transactions, merchant-initiated payments and MOTO arrangements can have different treatment from an ordinary customer-initiated ecommerce purchase.
The gateway and acquiring setup therefore needs to identify the transaction correctly rather than treating every remote payment as the same type.
For a fuller explanation, read our guide to PSD2, Strong Customer Authentication and 3D Secure .
PCI DSS and card-not-present payments
Card-not-present businesses still need to consider PCI DSS.
PCI DSS applies to organisations involved in payment-card processing regardless of business size or transaction volume.
However, the merchant's practical PCI DSS scope can vary considerably depending on how card details are handled.
Customer-entered payments
A business using an appropriately outsourced hosted payment page may have a very different card-data environment from one collecting and transmitting card details through its own systems.
Virtual terminal and MOTO
Where employees receive card details and manually enter them into a virtual terminal, the business needs procedures and technology appropriate to that environment.
PCI SSC provides a specific SAQ C-VT route for certain merchants whose payment processing is carried out through an eligible third-party hosted virtual terminal and who meet all of the relevant criteria.
Never retain security codes after authorisation
Card verification values such as CVV, CVC or CID are classified by PCI DSS as sensitive authentication data.
They must not be stored after authorisation, even if encrypted.
Businesses should confirm their own PCI DSS validation requirements with their acquiring bank or relevant payment provider rather than assuming that using a third-party gateway automatically removes all responsibilities.
Fraud and card-not-present payments
Remote payments can create fraud risks that differ from a face-to-face card-present transaction.
A business may need controls around:
- stolen card credentials;
- account takeover;
- unusual transaction patterns;
- high-risk geographies;
- multiple payment attempts;
- velocity;
- refund abuse;
- friendly fraud;
- chargebacks; and
- customer recognition of the transaction.
The appropriate controls depend on the payment channel and business model.
Possible tools can include:
- 3D Secure;
- gateway fraud screening;
- card verification values;
- address checks where supported;
- device and behavioural data;
- velocity rules;
- manual review;
- clear billing descriptors;
- refund controls; and
- chargeback monitoring.
More controls are not automatically better if legitimate customers are unnecessarily blocked. Businesses should review fraud performance alongside authorisation rates and customer conversion.
Merchant-entered vs customer-entered card details
This is one of the most useful distinctions when choosing a CNP setup.
Customer enters the card details
Examples include:
- ecommerce checkout;
- payment link;
- hosted payment page; and
- online invoice payment.
The customer interacts directly with the payment interface.
The merchant enters the card details
Examples can include:
- telephone orders;
- virtual terminal payments; and
- some back-office payment processes.
In this case, employees may come into contact with card information, which can create different security, operational and PCI DSS considerations.
If there is no genuine reason for the business to receive the card details itself, a hosted customer-payment journey such as a payment link may sometimes offer a simpler alternative.
Can a business use several CNP payment methods?
Yes.
A business might legitimately use:
- ecommerce for website sales;
- payment links for invoices;
- MOTO for telephone bookings;
- stored credentials for repeat customers; and
- recurring payments for memberships.
These do not necessarily need to be supplied through completely separate providers.
However, the chosen gateway and acquiring arrangement must support each required payment channel and the provider should understand how each transaction type will be used.
For more complicated businesses, reporting and reconciliation can also become important. Using several remote-payment channels is much easier to manage when transactions can be identified and reconciled accurately.
What should businesses compare when choosing CNP payment providers?
The lowest advertised transaction rate should not be the only consideration.
Payment channels
Does the provider support the combination of ecommerce, MOTO, payment links, recurring payments and virtual terminal functionality that the business actually needs?
Underwriting
Does the provider support the business sector, transaction values, customer geography and fulfilment model?
Authentication
How does the gateway handle 3D Secure, SCA, exemptions and authentication failures?
Fraud controls
What fraud-screening tools are included and how configurable are they?
PCI DSS
How will the proposed integration affect the merchant's card-data environment and validation requirements?
Recurring payments
Are tokenisation, stored credentials and merchant-initiated transactions supported correctly?
International payments
Are the required countries, cards and currencies supported?
Settlement
How quickly will funds be paid to the business and are reserves or other settlement conditions involved?
Pricing
Compare gateway charges, acquiring costs, transaction fees, minimum charges, chargeback fees and any additional functionality.
Integration
Does the provider connect with the website, booking platform, software or business systems already in use?
Start with the way your customers actually pay
“Card not present” describes a broad category. It does not tell you which gateway, merchant account or remote-payment setup your business needs.
Tell us whether you take ecommerce, telephone, payment-link, recurring or other remote card payments and we'll use that information to understand the requirement before looking at providers.
Find suitable providers Explore merchant account providers
How Merchant Advice Service helps with card-not-present payments
Merchant Advice Service helps businesses understand the payment requirement before identifying providers that may be suitable.
For CNP payments, that can include understanding:
- how customers pay;
- whether payments are customer-entered or merchant-entered;
- online checkout requirements;
- MOTO requirements;
- virtual terminal requirements;
- payment links;
- recurring and stored-card payments;
- monthly processing volume;
- average and maximum transaction values;
- customer locations;
- business sector;
- integration requirements;
- fraud controls;
- settlement requirements; and
- existing provider arrangements.
Depending on the requirement, the solution may involve a merchant account, payment gateway, specialist MOTO facility, virtual terminal or a combination of payment services.
Editorial & Commercial Disclosure
This guide provides general information about card-not-present payments, payment security, merchant accounts and payment gateways.
The way a transaction is classified, authenticated and priced depends on the payment journey, card, provider, acquiring arrangement and applicable card-scheme and regulatory requirements.
Merchant Advice Service does not process transactions, determine interchange, operate card schemes or make merchant-account underwriting decisions.
MAS is an independent payments information and provider-matching service. MAS may receive a referral fee or commission from some payment providers where a business proceeds following an introduction. Commercial relationships do not determine the factual information or provider-selection principles contained within this guide.
Businesses should confirm their own PCI DSS validation requirements, transaction classifications and contractual obligations with their payment provider or acquiring bank.
Information is provided for general guidance and should not be treated as legal, regulatory or information-security advice.
