Glossary
Payment terms and Exirom-specific terminology
12 min readUpdated Mar 26, 2026
Glossary
Payment industry terms and Exirom-specific terminology used throughout this documentation.
#Authentication & Security
| Term | Definition |
|---|---|
| 3D Secure (3DS) | An authentication protocol that adds a verification step during card payments. The cardholder is redirected to their bank to confirm the transaction (e.g., via SMS code or biometric). Reduces fraud and shifts liability to the card issuer. See 3DS Auth Flow. |
| ACS (Access Control Server) | The issuer bank's server that performs 3DS cardholder authentication. Decides whether to approve frictionless or require a challenge. |
| AVS (Address Verification System) | A fraud-prevention system that checks the billing address provided in the payment request against the address on file with the card issuer. Partial or full match improves frictionless 3DS approval rates. |
| Bearer Token | The JWT authentication token included in every API request as Authorization: Bearer {token}. Obtained via POST /api/v1/auth. Valid for 30 days. |
| CAVV (Cardholder Authentication Verification Value) | An encrypted authentication result generated after successful 3DS verification. Passed to the acquirer as proof that the cardholder was authenticated. Cannot be manipulated by the end user. |
| Checksum | An HMAC-SHA256 hash used to verify the integrity and authenticity of APM requests and callbacks. Computed over specific fields using your merchant secret key. See Checksum Guide. |
| CHD (Cardholder Data) | Sensitive card information including the full PAN, expiration date, and CVV. Must be handled according to PCI DSS requirements. Never store CVV; never log full PAN. Use tokenization to avoid handling CHD directly. |
| CVV (Card Verification Value) | The 3 or 4 digit security code on a payment card. Used to verify the cardholder has physical possession of the card. Also called CVC, CSC, or CVV2. |
| ECI (Electronic Commerce Indicator) | A value returned after 3DS authentication indicating the level of security used. Combined with CAVV to determine liability shift eligibility. |
| EMV 3DS | The current 3D Secure protocol standard maintained by EMVCo (consortium of Visa, Mastercard, Amex, and others). Replaces 3DS 1.0 with improved mobile support, frictionless flows, and richer risk data. |
| Frictionless Flow | A 3DS2 authentication path where the issuer approves the transaction without requiring cardholder interaction (no challenge screen). Achieved by providing complete billing and device data in the request. |
| JWT (JSON Web Token) | The token format used for Exirom API authentication. Obtained via POST /api/v1/auth and valid for 30 days. Included as Authorization: Bearer {token} in all API requests. |
| KYC (Know Your Customer) | Identity verification process. The kycVerified flag in payment requests indicates whether the customer has passed your KYC checks. Used for risk scoring. |
| Liability Shift | When 3DS authentication succeeds, responsibility for fraud-related chargebacks shifts from the merchant to the card issuer. Does not cover service/product disputes. |
| PCI DSS | Payment Card Industry Data Security Standard. A set of security requirements for handling card data. Integration type determines your compliance level: HPP = SAQ-A (simplest), Server-to-server = SAQ-D (most rigorous). |
| PSD2 (Payment Services Directive 2) | EU regulation requiring Strong Customer Authentication (SCA) for most online card payments in the European Economic Area. 3DS2 is the primary compliance method. |
| SCA (Strong Customer Authentication) | A PSD2 requirement mandating two-factor authentication for online payments in the EEA. Enforced by card networks and issuers via 3DS2. Exemptions exist for low-value, recurring, and trusted transactions. |
| Tokenization | Replacing sensitive card data (PAN, CVV) with a non-sensitive token. The token can be used for future charges without re-entering card details. See Tokenizing a Card. |
#Transaction Types
| Term | Definition |
|---|---|
| Payment | A transaction that collects funds from a customer's card or payment method. The core transaction type. Initiated via POST /api/v1/payments/card (cards) or POST /api/v1/payments/apm (APMs). |
| Payout | A transaction that sends funds from the merchant to a customer's card or bank account. Also called a "credit push" or "disbursement". Unlike a refund, a payout is an independent outbound transfer not tied to a prior transaction. |
| Refund | Returning funds from a previous payment back to the customer. Can be full or partial. Initiated via POST /api/v1/refunds/card. Unlike a chargeback (customer-initiated), a refund is merchant-initiated and does not incur penalty fees. Unlike a payout, a refund is always tied to a prior payment transaction. |
| Chargeback | A dispute initiated by the cardholder through their issuing bank. The transaction amount is reversed, and the merchant may be debited. Chargebacks can occur up to 120 days after the transaction. Unlike a refund (merchant-initiated), a chargeback is customer-initiated via their bank and may include penalty fees. |
| Authorization | The process of verifying that a cardholder's account has sufficient funds and that the transaction is approved by the issuing bank. An authorized transaction is not yet settled — funds are held (reserved) but not transferred. |
| Settlement | The process of transferring funds from the acquiring bank to the merchant's bank account. Typically occurs 1-3 business days after a successful transaction. The settlementAmount and settlementCurrency fields in transaction info responses show the settled values after FX conversion. |
| FX (Foreign Exchange) | Currency conversion applied when the order currency differs from the settlement currency. The exchangeRate field in transaction info responses shows the applied rate. |
| Rolling Reserve | A risk-management mechanism where a percentage of each transaction's settlement amount is held back by the acquirer for a fixed period (e.g., 10% for 180 days). Released gradually after the holding period. Protects against chargebacks and fraud losses. |
#Payment Methods & Integration
| Term | Definition |
|---|---|
| actionType | The apmResponseData.actionType field in APM payment responses. Determines the next step: REDIRECTION (redirect customer), QR (show QR code), or NONE (no customer action needed). See APM Payment Flows. |
| APM (Alternative Payment Method) | Any payment method other than traditional card payments. Includes e-wallets (PayPal, Skrill), bank transfers (iDEAL, SEPA), QR payments (PIX, UPI), mobile wallets (Apple Pay, Google Pay), and vouchers. |
| apmPayload | The payment-method-specific request object in APM payments. Structure varies by method — e.g., wallet credentials for e-wallets, QR data for QR payments. See apmPayload References. |
| apmResponseData | The APM-specific response object containing actionType, redirectUrl, iframeUrl, qrData, qrDeepLink, providerTransactionId, and other provider-specific fields. |
| Card Scheme / Card Network | The payment network that routes card transactions between acquirers and issuers. Major networks: Visa, Mastercard, Amex, Discover, UnionPay. |
| CNP (Card-Not-Present) | A transaction where the cardholder does not physically present the card (e.g., online payments). All Exirom card transactions are CNP. 3DS authentication is the primary fraud-prevention mechanism for CNP transactions. |
| HPP (Hosted Payment Page) | A pre-built, Exirom-hosted checkout page. The merchant redirects the customer to the HPP, which handles payment method selection, card input, and 3DS. Simplifies PCI compliance (SAQ-A). See Payment Intents Guide. |
| metadata | Arbitrary key-value pairs (Map<String, String>) attached to a transaction for your own use — e.g., order reference, campaign ID. Returned unchanged in responses and callbacks. Useful for reconciliation. |
| Payment Intent | A server-side object representing a pending payment for the Hosted Payment Page flow. Created via POST /api/v1/payments/intent and used to initialize the HPP checkout. |
| Recurring Payment | A payment that repeats on a schedule (e.g., subscriptions, installments). After the initial card tokenization and first payment, subsequent charges use the saved token without cardholder interaction. See Recurring Payments. |
| S2S (Server-to-Server) | Direct API integration where your backend communicates with Exirom's API. Requires handling card data (PCI DSS SAQ-D) for card payments, but provides maximum control over the checkout experience. |
| Smart Routing | Exirom's system for automatically selecting the optimal APM provider based on the payment method, country, and currency. Merchants send to a "SMART_" prefixed method and Exirom routes to the best available provider. |
#Industry Participants
| Term | Definition |
|---|---|
| Acquirer | The bank or financial institution that processes card transactions on behalf of the merchant. Receives the transaction from the payment gateway and routes it to the card network. |
| Issuer / Issuing Bank | The bank that issued the customer's payment card. Responsible for authorizing or declining transactions and for 3DS authentication. |
| PSP (Payment Service Provider) | The underlying provider that processes the transaction. Exirom routes transactions to the optimal PSP based on your configuration. A PSP provides processing infrastructure and acquiring relationships. Compare with a PayFac, which onboards sub-merchants under its own acquiring relationship. |
| PayFac (Payment Facilitator) | A master merchant that enables sub-merchants to accept payments under its umbrella merchant account. The PayFac is the Merchant of Record and handles onboarding, compliance, and settlement on behalf of sub-merchants. |
| Merchant of Record (MoR) | The entity that appears on the customer's bank or card statement as the seller. The MoR is legally responsible for the transaction, handles refunds/chargebacks, and must comply with card network rules. |
| Cashier | The payment orchestration layer that manages the end-to-end transaction flow — from receiving the merchant's request, through PSP routing, 3DS handling, callback delivery, and status updates. In Exirom's architecture, this is the core processing engine. |
#Identifiers & Tracking
| Term | Definition |
|---|---|
| requestId | A unique identifier you generate for each transaction request. Used for idempotency and tracking. Must be unique per transaction — reusing a requestId returns the original result instead of creating a new transaction. |
| transactionId | The unique identifier assigned by Exirom when a transaction is created. Used to query status (GET .../status/{id}), retrieve details (GET .../info/{id}), and correlate webhook callbacks. |
| MID (Merchant ID) | A unique identifier for your merchant account in Exirom. Passed as mid in card payment requests. You may have multiple MIDs for different business lines, currencies, or regions. Provided by the Exirom admin team. |
| accountId | Merchant account identifier used in APM requests (the APM equivalent of mid). Provided by the Exirom admin team. Passed in the request body for APM payment and payout requests. |
| Merchant Account | A bank account that enables a business to accept card payments. In Exirom, each merchant account is identified by a MID (for cards) or accountId (for APMs). You may have multiple merchant accounts for different currencies, regions, or business lines. |
| Sub-MID | A secondary merchant account created under a parent MID, typically used in PayFac setups. Each sub-merchant gets their own Sub-MID for transaction tracking, reporting, and settlement while sharing the parent's acquiring relationship. |
| BIN (Bank Identification Number) | The first 6-8 digits of a card number. Identifies the issuing bank, card brand, card type (debit/credit), and country. |
| PAN (Primary Account Number) | The full card number (typically 16 digits). Must never be stored in your systems unless you are PCI DSS Level 1 certified. Use tokenization instead. |
| Decline Code | A numeric code returned when a transaction fails. Indicates the reason for failure (e.g., insufficient funds, expired card, fraud suspected). See Decline Codes Reference. |
| Transaction Status | The current state of a transaction. Key values: NEW (created, not yet sent to processor), PENDING (sent to processor, awaiting response), PROCESSING (processor accepted, awaiting final result), CUSTOMER_VERIFICATION (3DS challenge or APM redirect required — customer action needed), SUCCEED (payment approved), FAILED (payment declined or authentication failed), REFUNDED (payment reversed), CHARGEBACK (dispute filed by cardholder). See Transaction Status Guide. |
#Webhooks & URLs
| Term | Definition |
|---|---|
| Webhook | An HTTP POST request sent by Exirom to your callbackUrl when a transaction reaches a final or significant state. Contains the transaction details and final status. Also called a "callback" in Exirom docs. See Webhook Best Practices. |
| Callback | See Webhook. In Exirom docs, "callback" and "webhook" are used interchangeably. Both refer to the HTTP POST notification sent to your callbackUrl when a transaction status changes. |
| callbackUrl | The HTTPS endpoint on your server where Exirom sends webhook notifications. Specified in payment requests. Must be publicly accessible and respond within 10 seconds. |
| Redirect URL | URLs used in the payment flow: successRedirectUrl (customer lands here after successful payment), failureRedirectUrl (after failure), and challengeUrl (3DS authentication page). Must be valid HTTPS endpoints. |
#Routing & Risk
| Term | Definition |
|---|---|
| Cascading / Fallback | Automatic retry of a failed transaction through an alternative PSP. Configured in the Exirom portal. Increases approval rates by trying multiple routes before returning a final failure. Also called "fallback routing". |
| Idempotency | The property that sending the same request multiple times produces the same result. In Exirom, the requestId field ensures idempotency — duplicate requests with the same requestId return the original transaction instead of creating a new one. See Idempotency. |
| Reconciliation | The process of matching transactions in Exirom with records in your own system and with settlement reports from acquirers/PSPs. Use requestId and transactionId to correlate records. The metadata field can carry your internal order IDs for easier matching. |
| Sandbox | Exirom's test environment at sandbox.api.exirom.com. Use test credentials and test card numbers to simulate transactions without moving real money. All integrations should be tested in sandbox before going live. |
Was this helpful?