Manual keyed entry is one of the oldest methods for accepting card payments and remains essential for telephone sales, service businesses, and situations where card readers fail. Understanding how it works—and its cost and risk implications—helps merchants deploy it wisely rather than by default.
How Manual Keyed Entry Works
Manual keyed entry follows a straightforward flow, but each step carries compliance and security considerations that merchants must handle correctly.
Collect card details from the customer
The merchant obtains the 16-digit card number (PAN), expiry date, CVV/CVC security code, and—where required—the billing zip code or full address. This happens verbally over the phone, via a written form, or through a secure web form.
Enter details into a terminal or virtual terminal
The operator types the card information into a virtual terminal, physical payment terminal with manual-entry mode, or a payment gateway's hosted keyed-entry interface. Modern systems encrypt data at the point of entry using P2PE.
Run AVS and CVV verification
The payment processor sends the card data to the issuing bank, which checks the CVV against its records and compares the submitted billing address against the one on file (AVS). Mismatches are flagged, and the merchant can decline or review the transaction.
Receive authorization response
The issuer returns an approval or decline code within seconds. Approval does not guarantee funds—it only confirms the card was valid at that moment with sufficient available credit or balance.
Settle the transaction
Authorized transactions are batched and submitted for settlement, typically at end of day. Funds reach the merchant's account within 1–3 business days depending on the processor and acquiring bank.
PCI DSS scope reminder
Any system that touches manually keyed card data is in PCI DSS scope. Never write card numbers on paper, store CVV after authorization, or transmit data over unencrypted channels.
Why Manual Keyed Entry Matters
Manual keyed entry fills critical gaps where card-reading hardware cannot operate, making it a necessary tool for a wide range of merchant categories.
According to Nilson Report data, telephone and mail-order channels still account for roughly 10–15% of total card-not-present transaction volume in North America, and the overwhelming majority of those transactions rely on manual keyed entry. For sectors like home services, healthcare billing, and B2B supply, keyed transactions are not edge cases—they are the primary collection method.
The fraud picture is significant. Javelin Strategy & Research found that card-not-present fraud losses in the U.S. exceeded $9 billion in a recent annual period, with manually keyed transactions representing a disproportionate share due to the absence of chip cryptography. This risk is why card networks impose higher interchange rates and why acquirers scrutinize keyed transaction ratios closely. A keyed transaction can cost a merchant 0.3–0.5 percentage points more in interchange than an equivalent chip transaction—at $1 million in annual keyed volume, that is $3,000–$5,000 in additional processing cost.
Despite the higher cost and risk, manual keyed entry delivers genuine business value: it eliminates lost sales from unreadable cards, enables remote selling without shipping hardware, and provides a reliable fallback that keeps revenue flowing when technology fails.
Manual Keyed Entry vs. Card-Present Transactions
These two transaction types sit at opposite ends of the risk and cost spectrum. The table below covers the most important dimensions for merchant decision-making.
| Dimension | Manual Keyed Entry | Card-Present (Chip/Tap) |
|---|---|---|
| Card location | Remote or unreadable | Physically at terminal |
| Interchange rate | Higher (CNP rate) | Lower (CP rate) |
| Fraud liability | Merchant bears liability | Issuer bears liability (EMV shift) |
| CVV verification | Required, manual input | Embedded in chip cryptogram |
| AVS available | Yes | Not typically used |
| Chargeback risk | Higher | Lower |
| Use case | Phone, mail, fallback | Retail, restaurant, in-person |
| PCI scope | Yes | Yes |
Types of Manual Keyed Entry
Manual keyed entry is not monolithic. Merchants encounter several distinct variants depending on channel and technology.
MOTO (Mail Order / Telephone Order): The classic use case. The customer provides card details by phone or on a paper form. Transactions are flagged with a MOTO indicator in the authorization message, which affects interchange category and reporting. Mail order telephone order transactions use specific MCC codes and transaction type flags.
Fallback keyed entry at point of sale: When a chip card fails to read after multiple attempts, point-of-sale terminals allow the cashier to key in the card number as a fallback. Some acquirers limit the number of permitted fallback transactions per merchant location per day to control fraud exposure.
Virtual terminal keyed entry: Browser-based virtual terminals enable back-office staff or remote agents to key card details received via email, fax, or phone. These systems are typically hosted by the payment gateway and reduce PCI scope for the merchant's own systems.
Recurring billing with stored credentials: An initial manual keyed entry can be used to tokenize a card for recurring charges. Subsequent transactions use the stored token and reference the original transaction, qualifying for lower interchange rates under stored-credential frameworks.
API-based keyed entry: Developers integrating payment gateways directly may pass card data programmatically via a server-to-server API call. This approach requires full PCI DSS SAQ D or equivalent certification and is typically reserved for high-volume, high-sophistication operations.
Best Practices
For Merchants
- Always collect CVV and run AVS. A full AVS match (street + zip) combined with a CVV match significantly reduces fraud risk and may improve interchange qualification.
- Set transaction velocity limits. Restrict the number of keyed transactions per hour per operator account to detect credential stuffing or insider fraud early.
- Train staff on social engineering. Fraudsters often call merchants posing as customers and pressure operators to override fraud flags. Establish clear escalation policies.
- Review your keyed transaction ratio monthly. If keyed volume exceeds 20–30% of total card volume without a clear business reason, investigate and discuss with your acquirer before they contact you.
- Use a hosted virtual terminal, not custom-built forms. Hosted solutions keep card data out of your environment and simplify PCI compliance dramatically.
For Developers
- Never log raw PANs or CVV values. Audit your logging pipelines before going live. A single debug log line capturing card data can trigger a PCI breach finding.
- Implement P2PE or tokenization at the field level. Use your payment gateway's hosted fields or JavaScript SDK so card data is encrypted in the browser before it touches your servers.
- Set
autocomplete="cc-number"and related attributes on input fields only when appropriate. For virtual terminal interfaces used by staff (not customers), suppress autocomplete to avoid browser storage of card data. - Distinguish MOTO from fallback keyed entry in your transaction metadata. Different transaction type codes apply—misclassification leads to incorrect interchange and potential disputes with your acquirer.
- Build AVS/CVV response handling into your decline logic. Do not simply pass or fail on the authorization result. Parse the AVS and CVV response codes and apply your own risk rules on top.
Common Mistakes
Storing CVV after authorization. PCI DSS Requirement 3.2 explicitly prohibits storing CVV values post-authorization, even in encrypted form. Many merchants violate this by logging full authorization requests that include the CVV field.
Skipping AVS on low-value orders. Some merchants disable AVS checks for transactions under a threshold to reduce declines. Fraudsters know this and deliberately keep test transactions small before running larger fraudulent charges.
Treating every failed chip read as a valid fallback scenario. Some card-present fraud schemes involve deliberately damaging the chip to force keyed entry, which shifts fraud liability back to the merchant. Train staff to inspect cards for obvious tampering before approving fallback entry.
Misclassifying keyed transactions in reporting. Lumping MOTO, fallback, and virtual terminal keyed transactions together makes it impossible to diagnose which channel is driving elevated fraud or chargeback rates.
Not reconciling keyed transaction totals against orders. Manual data entry introduces transposition errors—a mistyped digit in the card number or amount can cause a successful authorization against the wrong card. Implement end-of-day reconciliation that matches keyed transaction amounts to order records.
Manual Keyed Entry and Tagada
Tagada's payment orchestration layer routes manually keyed transactions intelligently across your acquiring and gateway connections to optimize authorization rates and minimize interchange costs.
Optimize keyed transaction routing with Tagada
Tagada detects when a transaction is manually keyed—based on the entry mode flag in the authorization message—and automatically routes it to the acquirer in your stack with the most favorable CNP pricing and the highest historical approval rate for that card BIN and country. This means your MOTO and virtual terminal volume stops being a flat-rate cost center and becomes an optimized channel. You can also configure Tagada's rule engine to apply stricter fraud scoring thresholds specifically for keyed transactions without affecting card-present authorization rates.
For teams building on Tagada's API, the entry_mode field in the transaction object accepts keyed, moto, and fallback values, enabling granular reporting and routing logic at the transaction level. This metadata flows through to your payment gateway integrations and chargeback management workflows, giving you full visibility into your keyed transaction portfolio without manual reconciliation.