> For the complete documentation index, see [llms.txt](https://docs.omni.integratedcommerce.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.omni.integratedcommerce.io/glossary/payments-and-transactions.md). # Payments and transactions Definitions of payment methods, transaction operations, identifiers, and amounts as used by the API. These terms describe how a customer pays a merchant and how the API records the request and result. Deposit and fee definitions are in [Settlement and fees](/glossary/settlement-and-fees.md). ## Account type The funding classification of a stored payment method or transaction response, exposed as `accountType`. Card values are `Credit` or `Debit`; bank-account values are `Checking` or `Savings`. Immediate hosted ACH responses can use lowercase `checking` or `savings`. This classification does not identify the card brand, and it can be absent when unavailable. ## ACH bank transfer A payment that moves money through the US Automated Clearing House network using a bank account. An ACH sale in this API requests a debit from the customer's account. Bank processing continues after the initial response, so acceptance does not confirm settlement. ACH supports sales and refunds, with no separate authorization, capture, or void operation. See [ACH bank transfers](/payments/ach.md). ## Amount breakdown A description of the parts already included in a transaction's requested amount: goods and services, tax, cashback, and tip. It supports reporting without increasing the charge. When provided, the components of `amountBreakdown` must add up to `amount`; they are not added to it again. ## Approved amount and partial approval The amount the payment system agreed to authorize or charge for a transaction response, exposed as `amountApproved`. A partial approval means it approved less than the amount requested and is reported with `responseCode: 2`. Inspect the approved amount and each response when deciding how much of the order has been paid. ## Authorization A card payment operation that asks the issuer to approve and reserve an amount for a later charge. An approved authorization holds the funds without completing the separate capture step or depositing money to the merchant. The API uses `Auth` as the transaction type. ACH has no authorization-only operation. See [Transaction types](/payments/payments.md#what-the-transaction-types-mean). ## Authorization code A code returned by the card issuer to identify its approval of a transaction, exposed as `authCode` when available. It is processor response information. Use the Fiska transaction ID or the supported original-reference fields when making a follow-up API request. ## AVS Address Verification Service is the card check that compares submitted billing address or postal-code information with issuer records. The `avsResult` describes the match outcome when returned. An address mismatch can coexist with an approved payment, so it does not replace the transaction's approval or decline code. ## BIN Bank Identification Number: an identifier for a financial institution in card-network processing. In statement reporting, `BinFee` is associated with the BIN under which the merchant's card payments are processed and is grouped under `NetworkAssessment`. See the [fee category definitions](/settlement-reporting/fee-charges.md#general-fee-categories) for the purpose of that group. ## Capture A payment operation that completes a previously approved card authorization by submitting the authorized amount, or a permitted portion of it, for charging and settlement. A capture references the original authorization. Its processing result and the merchant's later bank deposit are reported separately. See [Transaction types](/payments/payments.md#what-the-transaction-types-mean). ## Card brand and card network A card network connects participants in card payment processing and defines the rules for its cards. A card brand is the name identifying the card program, such as Visa or Mastercard. The API's `cardType` reports the card or tender classification when available; it is separate from `accountType`, which distinguishes credit and debit funding. ## Card not present and card present Card not present (CNP) describes a card payment taken without the card being presented to a physical payment terminal, such as an online checkout. Card present (CP) describes a payment where the customer presents the card to a physical terminal. The API provides virtual and physical endpoints for these channels. See [Choosing a channel](/payments/payments.md). ## Card on file A card stored earlier as a token so it can be used for a later payment without collecting its details again. The API's card-on-file request models also accept a bank-account token for a token sale, subject to the ACH restrictions. See [Tokenization](/payments/tokenization.md). ## Cashback and tip Cashback is the cash portion of a payment that the merchant gives to the customer. A tip is the gratuity included in the payment. In request `amountBreakdown` fields, both are parts of the total amount already requested. Terminal responses can report the amounts actually approved in `approvedAmountBreakdown`. ## Chargeback A reversal raised through the card issuer's dispute process against an earlier card payment. A merchant can incur a fee related to handling it. The term appears in statement fee reporting and in 3D Secure fraud-liability discussions; it is separate from a merchant-initiated refund through `POST /transactions/refund`. ## CVV The card security code used in card verification, also called CVV2 in some wording. The API reports the verification outcome in `cvvResult` when available. A match result is one verification signal and does not by itself establish payment approval. The result field contains an outcome, not the security code itself. ## EFT Electronic funds transfer. In this API's payment-method vocabulary, `VirtualEft` identifies a Canadian bank-transfer method when configured, and SDK error names use EFT for that flow. Its appearance in shared types does not establish support for every operation documented for cards or US ACH. Check the merchant's available payment methods and applicable service configuration. ## EMV and contactless EMV refers to chip-based card payment technology used for card-present processing. Contactless describes presenting a card or supported device by tapping it near the terminal. The certification test-card guidance covers physical cards for chip and contactless flows so the ISV can verify terminal interaction as well as the API result. See [Test cards](/going-live/test-cards.md). ## Invoice number and order number Identifiers supplied by your application to associate a payment with a business invoice or order. `invoiceNumber` and `orderNumber` support retrieval and reporting; they do not identify the API transaction itself. An order can require more than one payment operation, each with its own transaction ID and reference. ## Masked payment details A partially hidden card or bank-account number returned so the application can help a customer recognize a payment method. Fields such as `maskedCardNumber` and `accountNumber` are display information. Use the payment method's ID to charge a stored method; a masked number cannot substitute for that ID. ## Minor unit The smallest denomination of a currency. The API represents money as integers in minor units, so `1000` means $10.00 for both USD and CAD. The payment method supplies a transaction's currency; reporting objects include currency alongside their amounts. See [Amounts](/get-started/conventions.md#amounts). ## Omni-channel Using the same payment API across in-person and online payment flows. For example, a card token created through a physical terminal can later be charged through a token-sale request. The supported operations still depend on the payment method, particularly for ACH. ## Original transaction reference The identifier that links a capture, refund, or void request to the earlier transaction it acts on. Supply the supported `originalTransactionId` or `originalReferenceId` field as required by the endpoint. This is distinct from the new operation's own `referenceId`, which identifies that new request in your records. ## Payment channel and payment rail A channel is the way the customer presents payment information, such as on a terminal or in an online form. A rail is the processing system that carries the payment, such as a card network or ACH. The reporting API distinguishes the card and ACH rails with settlement `type` values `Card` and `Ach`. ## Payment method A merchant-owned resource that tells the API how to take a payment and which currency to use. It can represent a physical terminal, an online card or bank-transfer configuration, or a stored customer token. Requests select it with `paymentMethodId`. Read its `type` field to determine its kind. See [Payment methods](/payments/payment-methods.md). ## Physical terminal A payment device on which a customer presents a card for an in-person payment or tokenization. The API represents the device as a payment method with `type: Physical`, usually identified by a `pmt_trm_` ID. Physical sale and authorization requests send the operation to that device. ## PIN A Personal Identification Number entered by the cardholder when a card-present payment requires that form of verification. A failed PIN check can be reported as an authentication failure in a transaction response. The API result reports the outcome of verification, not the PIN entered by the customer. ## Receipt Printable information returned for a payment response, such as card-present receipt lines. It records details of that processing result for the merchant or customer. Some channels return an empty receipt, and a receipt does not establish that the merchant's bank deposit has occurred. ## Reference ID A reference used to connect a transaction request to your application's records, supplied as `referenceId` or generated by the API when omitted. Choose a unique value per merchant that you can use to retrieve an uncertain payment attempt. It is not an idempotency key: reusing it does not replay the earlier response or make a retry safe. See [Retrieving transactions](/payments/transaction-retrieval.md). ## Refund A merchant-initiated operation to return all or part of an earlier sale or capture to the payer. The request references that earlier transaction. For eligible card transactions still in the current batch, the refund endpoint performs a void; after settlement, it performs a refund. ACH uses a refund to reverse a previous sale and cannot be voided. See [Transaction types](/payments/payments.md#what-the-transaction-types-mean). ## Refundable amount The balance of an approved sale or capture that remains available to refund, exposed as `refundableAmount` once known. It becomes `0` after the original amount has been fully refunded or voided. An absent value does not mean unlimited refunds. A refund response reports the remaining balance on the original transaction. See [Checking what can still be refunded](/payments/transaction-retrieval.md#checking-what-can-still-be-refunded). ## Sale A payment operation that requests a charge to the customer. A card sale combines authorization and capture in one operation. An ACH sale initiates a bank-account debit whose final outcome arrives asynchronously. Approval of the payment and the later deposit to the merchant are separate stages. ## Subscription A billing arrangement for repeated charges according to a schedule. The shared error catalog refers to subscription state and billing failures, but these payment guides do not define a subscription-management API. A stored token is a payment method that can support later charges; creating one does not create a billing schedule. ## Token A stored payment method that lets the API reuse a customer's card or bank account through a `pmt_tkn_` ID. Your application uses this ID for later payments without receiving or resubmitting the full payment details. Card tokens support token sales and authorizations; ACH tokens support token sales. A payment token is separate from the short-lived `sessionId` used to open a form. ## Tokenization The process of securely storing a supplied card or bank account and returning a reusable token identifier. It can happen during a supported payment or through a dedicated tokenization request. The resulting token is available in the operation's payment-method result once creation completes. See [Tokenization](/payments/tokenization.md). ## Transaction The API record of a payment operation and its processing outcome, such as a sale, authorization, capture, refund, or void. Identified by a `trx_` ID, it connects the requested amount, payment method, references, and gateway responses. A transaction can record a decline as well as an approval. It does not by itself record a deposit to the merchant's bank account. See [Retrieving transactions](/payments/transaction-retrieval.md). ## Transaction request The instruction submitted to start a payment operation, together with its progress while processing is underway. A request can exist before a retrievable transaction record is available, particularly during hosted checkout or ACH processing. An empty transaction lookup therefore does not prove the request had no effect. ## Transaction response One processing result inside a transaction's `transactionResponses` array. It carries the response code, approved amount, and payment-method details available for that result. A transaction can have multiple responses; inspect the entries to determine what was approved, declined, or left pending. ## Unreferenced refund A request to send money back to a payment method without identifying an original sale or capture. The public API currently documents unreferenced refund operations as unavailable. Use the supported referenced refund flow for an eligible original transaction. ## Virtual terminal A configured online payment method that starts a hosted session for collecting payment details. Card configurations use `type: Virtual` and commonly a `pmt_vrt_` ID; US bank-transfer configurations use `type: VirtualAch` and commonly a `pmt_ach_` ID. The session can be presented through the Hosted Payment Form or Payment SDK. ## Void A cancellation of an eligible card sale, authorization, or capture while it is still in the processor's current batch. The void operation acts on the full original transaction amount. ACH does not support voids. See [Transaction types](/payments/payments.md#what-the-transaction-types-mean). ## Related * [Accounts and API access](/glossary/accounts-and-api-access.md) - merchants, account holders, and ownership * [Hosted forms and SDK](/glossary/hosted-forms-and-sdk.md) - collecting payment information * [Webhooks and outcomes](/glossary/webhooks-and-outcomes.md) - interpreting approval, decline, and processing states * [Settlement and fees](/glossary/settlement-and-fees.md) - connecting payment activity to bank deposits