A practical reference for payment operations, risk, ecommerce, and card-present terms. Each definition links to relevant product pages and implementation context.
3-D Secure is an authentication framework used in ecommerce card payments to verify the cardholder during checkout. Programs such as Visa Secure and Mastercard Identity Check can shift fraud liability and lower chargeback risk when properly implemented. Teams usually tune it by transaction risk, customer friction tolerance, and expected conversion impact, rather than forcing the same challenge flow for every purchase.
ACH is the U.S. bank-to-bank electronic payment network used for credits and debits, including account verification, recurring pulls, and disbursements. Compared with cards, ACH usually has lower processing cost but different return windows and operational rules. Product and risk teams treat ACH as its own payment rail, with distinct authorization language, settlement timelines, and exception handling.
An ACH return code explains why an ACH transaction failed after submission, such as insufficient funds, invalid account details, or revoked authorization. Codes drive operational workflows for retry logic, customer messaging, and compliance records. Mature payment teams map return codes to clear playbooks so support, risk, and billing systems all respond consistently instead of treating ACH failures as generic declines.
Address Verification Service (AVS) checks whether a billing address entered at checkout matches issuer records for a card account. AVS results are often used as fraud signals, not automatic pass or fail decisions. The strongest programs combine AVS with CVV, velocity checks, and behavioral rules to reduce false declines while still stopping high-risk transaction patterns.
An acquirer, or acquiring bank, is the financial institution that enables a merchant to accept card payments and routes transactions to card networks. The acquirer handles merchant settlement, underwriting expectations, and risk exposure for accepted transactions. In practice, merchants often experience the acquirer through their processor or platform partner rather than direct daily interactions.
Authorization is the issuer approval step where available funds or credit are checked before capture and settlement. A successful authorization does not move money yet; it reserves the amount until capture. Payment operations depend on clean authorization handling because duplicate auths, stale auths, and poor reversal logic can inflate support tickets and hurt customer trust.
BIN stands for Bank Identification Number, the leading digits of a card number that identify the issuing institution and product type. BIN intelligence can support routing, risk controls, and card acceptance experiences. Teams commonly use BIN insights to detect prepaid or commercial cards, understand issuer behavior patterns, and tailor messaging when transactions fail.
Card-not-present (CNP) refers to transactions where the physical card is not tapped, dipped, or swiped, such as ecommerce, phone, and subscription payments. CNP payments usually carry higher fraud and dispute risk than card-present transactions. Teams reduce CNP risk by combining tokenization, CVV and AVS checks, adaptive authentication, and clear post-purchase communication.
Card-present (CP) transactions happen when payment credentials are captured directly from a physical card using chip, contactless, or magstripe reads. CP flows usually have lower fraud rates and different interchange economics than online transactions. Operationally, CP programs still require strong device management, fallback controls, and exception handling for terminal connectivity and reversals.
Cash discount programs display a standard price and provide a discount when a customer pays with cash. Merchants use this model to offset card acceptance costs while keeping pricing disclosure clear at point of sale and checkout. Success depends on compliant signage, correct receipt wording, and consistent implementation across in-store and invoice payment flows.
CCV or CVV2 is the card security code used mainly for card-not-present verification. It helps confirm a payer has the physical card details at checkout, but it is not a guarantee against fraud. Teams treat CVV as one signal in a broader risk strategy that also includes AVS, velocity controls, device context, and account behavior patterns.
A chargeback is a forced reversal initiated by the cardholder issuer after a dispute, such as fraud claims, service issues, or processing errors. Chargebacks impact margin, operations, and risk posture, especially at scale. Effective programs combine fraud prevention, strong merchant descriptors, rapid evidence workflows, and clear customer communications to reduce dispute volume and improve representment outcomes.
A decline means a transaction was not approved during authorization. Declines can result from insufficient funds, issuer risk rules, expired credentials, network issues, or formatting errors. Teams that improve approval rates focus on decline reason normalization, smart retries, account updater coverage, and customer-friendly recovery flows rather than blaming one processor or endpoint.
A payment descriptor is the merchant name or billing text shown on cardholder statements. Clear descriptors reduce friendly fraud and support burden because customers can recognize purchases quickly. Poor descriptors increase avoidable disputes. Teams tune descriptor strategy alongside receipt messaging and support contact details so cardholders resolve confusion without filing unnecessary chargebacks.
Dual pricing presents separate cash and card prices so customers can choose their preferred payment method with transparent pricing. It is distinct from blanket surcharges and must be implemented with compliant signage and consistent checkout behavior. Merchants often use dual pricing to protect margin while keeping acceptance broad across consumer payment preferences.
EMV is the global chip-card standard for secure in-person card acceptance. EMV transactions use dynamic data that is harder to counterfeit than static magstripe data, reducing certain fraud types. Operationally, teams still need fallback controls, terminal certification discipline, and user-friendly prompts so chip acceptance improves security without creating avoidable checkout friction.
Embedded payments means payment capabilities are integrated directly into software workflows rather than redirected to separate tools. ISVs use embedded payments to improve conversion, retain data context, and streamline merchant operations. Strong embedded programs pair clean APIs with onboarding, reconciliation, and reporting controls so finance teams and product teams can scale together.
A payment gateway is the service layer that securely transmits payment data between checkout experiences, processors, and networks. It handles transaction messaging, tokenization support, risk hooks, and integration consistency across channels. Teams evaluate gateways on reliability, API quality, observability, and how easily they can support card-present, ecommerce, and recurring billing in one platform.
Hosted fields are secure payment form inputs rendered by a payment provider but embedded into a merchant checkout page. They reduce PCI scope by keeping sensitive card data out of merchant servers while preserving branded UX control. Teams often choose hosted fields when they need flexible design and strong compliance posture without building direct PAN handling.
Interchange is the fee component set by card networks and paid to issuers for card transactions. It varies by card type, merchant category, transaction method, and data quality. Payment teams optimize interchange through qualification controls, Level 2/3 data where applicable, and smart routing or configuration discipline, rather than expecting one setting to solve every cost issue.
ISO stands for Independent Sales Organization, a channel partner that markets merchant services and payment acceptance solutions. ISOs typically focus on portfolio growth, merchant support, and relationship management while relying on platform providers for technology and processing infrastructure. Partner-first programs align incentives by avoiding direct merchant competition and enabling branded operational workflows.
ISV means Independent Software Vendor, a company that builds software products and may embed payment acceptance into its application workflows. ISVs typically care about API ergonomics, onboarding speed, reconciliation visibility, and merchant lifecycle tooling. Successful ISV payment programs unify technical integration with business operations so growth and support can scale together.
An issuer is the financial institution that provides payment cards to cardholders and approves or declines authorization requests. Issuers apply fraud controls, credit decisions, and account rules that directly affect approval rates. Payment teams monitor issuer behavior trends to improve retry strategies, customer messaging, and credential update coverage across their transaction portfolio.
Level 1, 2, and 3 processing describes increasing transaction data depth submitted with certain commercial and government card payments. Higher data levels can improve qualification and reduce effective processing cost for eligible transactions. Teams implementing Level 2/3 need reliable field mapping, invoice detail quality, and audit-friendly data controls to sustain results.
MCC stands for Merchant Category Code, a four-digit classification indicating business type for card processing. MCC affects interchange behavior, risk policies, and sometimes acceptance constraints. Accurate MCC setup is important for onboarding quality and pricing expectations. Teams should review MCC alignment when expanding offerings or changing sales models to avoid downstream operational surprises.
MID means Merchant Identification number, the unique account identifier used to route and settle transactions for a merchant setup. Multi-location or multi-brand portfolios may manage several MIDs based on business, risk, or reporting requirements. Clean MID governance supports reconciliation, support workflows, and terminal provisioning discipline across growing merchant operations.
MOTO stands for Mail Order / Telephone Order transactions, a card-not-present flow where payment details are provided by phone or non-web channels. MOTO has distinct risk posture and compliance handling compared with standard ecommerce checkout. Teams usually control MOTO through strict staff procedures, monitoring, and clear transaction source tagging in reporting.
NACHA is the organization that governs ACH network operating rules in the United States. Its standards define authorization, formatting, return handling, and compliance expectations for ACH participants. Product and operations teams working with ACH should treat NACHA rule awareness as core infrastructure hygiene, especially for recurring billing and dispute response workflows.
NFC, or Near Field Communication, is the short-range wireless technology used for tap-to-pay interactions between cards, phones, and terminals. NFC enables fast checkout and supports mobile wallet experiences in card-present environments. Reliability depends on terminal configuration, network readiness, and consistent user prompts to minimize failed taps and fallback confusion.
A network token is a card credential replacement issued through card network token services for safer digital transactions. Unlike static PAN storage, network tokens can improve lifecycle resilience and authorization performance when combined with account update mechanisms. Teams use them to reduce fraud exposure and improve continuity for subscriptions and card-on-file commerce.
Omnichannel payments unify customer payment experiences and merchant operations across in-person, ecommerce, invoices, and recurring flows. The objective is one coherent view of customer, transaction, and risk signals rather than disconnected channel silos. Well-designed omnichannel systems improve support efficiency, revenue visibility, and customer retention through consistent data and workflow design.
PAN stands for Primary Account Number, the full card number printed on a payment card and used as a core credential in card processing. PAN is highly sensitive data under PCI standards. Teams should avoid storing or handling raw PAN directly when possible by using tokenization, hosted fields, and vault abstractions that reduce compliance and security risk.
PCI DSS is the Payment Card Industry Data Security Standard, a baseline framework for securing cardholder data environments. Scope varies based on payment architecture and data handling choices. Teams that use tokenization, hosted fields, and provider-managed vault patterns can reduce exposure while still maintaining strong controls, audit readiness, and merchant trust.
PayFac means payment facilitator, a model where a master merchant entity enables sub-merchants under its umbrella. The model can speed merchant onboarding and embedded payment rollout, but it also concentrates risk, compliance, and operational obligations. Teams considering PayFac-like structures should align underwriting, monitoring, and lifecycle tooling from day one.
PIN debit is a debit transaction authenticated by a customer-entered PIN, typically in card-present environments. It often follows debit network routing rules and differs from signature debit processing behavior. Merchants and ISVs usually evaluate PIN debit for economics, acceptance consistency, and terminal readiness across specific merchant categories.
A processor is the platform that handles transaction routing, messaging, and lifecycle events between merchant-facing systems, acquirers, and networks. Processors influence reliability, response mapping, and reconciliation behavior at scale. Teams typically evaluate processor fit on uptime, feature parity, support quality, and how smoothly it integrates with gateway and merchant tooling.
Recurring billing automates repeated charges for subscriptions, installments, or ongoing service agreements on predefined schedules. The model improves revenue predictability but increases sensitivity to failed payments and credential lifecycle changes. Effective recurring systems include retry strategies, customer notifications, account updater integration, and analytics to reduce involuntary churn.
A refund reverses funds from merchant to customer after a completed sale, either fully or partially. Refund operations affect customer satisfaction, support workload, and reconciliation accuracy. Teams with strong refund controls track reason codes, automate notifications, and ensure reporting ties the original transaction to every adjustment for transparent finance and support workflows.
A retrieval request is a pre-chargeback inquiry where the issuer requests transaction documentation before escalating to a formal dispute. Fast, accurate responses can prevent avoidable chargebacks. Teams should treat retrieval requests as high-priority operational events with standardized evidence assembly and response timing so issues are resolved before they become financial losses.
SAQ stands for Self-Assessment Questionnaire, the PCI compliance validation format used by many merchants depending on their payment environment scope. SAQ type is driven by architecture choices, such as whether card data touches merchant systems directly. Teams can simplify SAQ burden by using tokenized and hosted payment patterns that minimize sensitive data handling.
Settlement is the stage where approved transactions are cleared and funds are transferred through the payment ecosystem to the merchant account. It follows authorization and capture, and it drives payout timing expectations for operators and finance teams. Clean settlement reporting is essential for reconciliation, merchant trust, and dispute readiness.
A soft decline is a temporary authorization rejection where a transaction may succeed if retried with updated context, timing, or authentication. Common examples include transient issuer controls or required step-up verification. Teams should distinguish soft declines from hard declines so retry policies protect conversion without creating duplicate attempts or customer confusion.
Subscription billing manages recurring charges tied to ongoing access, usage tiers, or contractual service periods. Beyond payment acceptance, teams must manage upgrades, downgrades, proration, failed payment recovery, and renewal communications. Operational quality in subscription billing has direct impact on churn, customer lifetime value, and support workload.
Surcharging adds a fee to certain card transactions to help recover processing costs, subject to network and jurisdiction rules. It requires careful compliance controls, clear disclosures, and reliable receipt formatting to avoid customer confusion or enforcement risk. Merchants should treat surcharging as a policy program, not just a terminal setting toggle.
Tokenization replaces sensitive payment credentials with non-sensitive tokens that can be stored and reused in controlled contexts. It reduces PCI scope and lowers data exposure risk while enabling subscriptions, saved cards, and cross-channel experiences. High-quality tokenization strategy also addresses lifecycle updates, failure handling, and transparent mapping for support operations.
Tokenizer commonly refers to a productized implementation of tokenization APIs and secure payment components used to collect and reuse payment methods safely. It usually includes hosted fields, token lifecycle tooling, and integration pathways for checkout or account management. Teams adopt tokenizer-style products to speed delivery without handling raw card data directly.
TPP can mean Third-Party Provider, often describing external service providers integrated into a payments stack for fraud, data enrichment, routing, or reconciliation. TPP integrations can add capability quickly but also increase operational dependencies. Teams should monitor TPP latency, error behavior, and fallback logic to maintain resilient payment flows during incidents.
Underwriting is the risk assessment process used to approve merchant accounts, determine controls, and set monitoring requirements before and during payment acceptance. It evaluates business model, processing profile, and compliance posture. Strong underwriting combines initial diligence with ongoing performance monitoring so risk decisions evolve with merchant behavior and volume shifts.
A payment vault is a secure storage layer for tokenized customer payment methods used in repeat transactions, subscriptions, and account updates. Vault design impacts compliance scope, customer lifecycle continuity, and support burden. Teams should evaluate vault systems on token portability, update coverage, and how clearly they expose payment method state to applications.
A virtual terminal is a browser-based payment interface that lets staff key in or process transactions without dedicated POS software. It is commonly used for phone orders, invoices, support workflows, and back-office payment operations. Teams rely on role controls, audit trails, and risk rules to keep virtual terminal use both efficient and secure.
A webhook is an event notification sent from a payment platform to a merchant system in near real time when transaction state changes occur. Webhooks power asynchronous workflows such as fulfillment, ledger updates, and customer messaging. Reliable webhook integration requires idempotency handling, retry awareness, and clear event versioning practices in receiving systems.
An authorization reversal releases a previously approved authorization hold when a transaction will not be captured. Prompt reversals improve customer experience by freeing funds quickly and reducing confusion around pending charges. Teams often instrument reversal quality as a reliability metric because poor reversal handling can trigger support tickets and merchant dissatisfaction.
Capture is the action that finalizes an authorized transaction for settlement. Some flows capture immediately, while others capture later after fulfillment or service confirmation. Payment operations teams watch capture timing closely because delayed or missed capture can cause expired authorizations, revenue leakage, and reconciliation mismatches.
Friendly fraud occurs when a legitimate cardholder disputes a valid transaction, often due to confusion, forgetfulness, or unclear merchant recognition. It can look like true fraud in dispute systems but requires different mitigation tactics. Clear descriptors, immediate receipts, responsive support, and strong order evidence are key defenses against friendly fraud losses.
A merchant account is the specialized account relationship that allows a business to accept card payments and receive settlement funds. It includes underwriting, processing terms, and operational controls tied to risk and transaction profile. Teams building payment software should model merchant account setup as a lifecycle process, not a one-time onboarding checkbox.
Payment orchestration is the coordination layer that manages routing, retries, data normalization, and provider interactions across multiple payment services. It helps teams improve resilience and approval performance without hard-coding provider-specific logic into every product workflow. Effective orchestration still depends on observability and disciplined fallback behavior under real production load.
Pre-authorization is a temporary approval used to verify funds or card validity before finalizing the exact transaction amount. It is common in hospitality, fuel, and variable-amount workflows. Teams should manage pre-auth expiry windows, incrementals, and final capture logic carefully so customer funds are not held longer than necessary.
Risk scoring assigns a relative fraud or loss risk value to a transaction based on multiple signals such as device patterns, historical behavior, AVS/CVV outcomes, and geography. It supports adaptive decisioning rather than simplistic allow/deny rules. Teams tune risk scoring continuously to balance fraud reduction with conversion and customer experience goals.
Routing in payments is the logic used to direct a transaction through specific processors, acquirers, or network paths based on cost, performance, or risk objectives. Good routing strategy can improve approvals and reduce operational friction. It should be backed by measurable policy and telemetry rather than one-off static configuration.
Stored credential transactions use previously saved payment details with customer consent for future charges, including recurring and one-click payments. Networks and issuers expect correct indicators describing initial storage and subsequent usage. Teams should maintain clear consent records and transaction flags to support compliance and maximize approval performance.
Terminal estate management refers to provisioning, monitoring, updating, and supporting payment devices across merchant locations. As portfolios grow, terminal operations become a major reliability and support lever. Teams that centralize device visibility, status events, and deployment controls can reduce downtime and improve card-present transaction consistency.
A velocity check limits suspicious transaction frequency by monitoring how often the same card, account, IP, or device is used in a defined time window. It is a practical fraud control for card-not-present environments. Teams tune thresholds by merchant segment and typical customer behavior to avoid blocking normal purchasing patterns.
No merchant-boarding. No residual surprises. No legacy stack.