> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/getting-started/glossary.md). # Glossary Definitions of terms you'll encounter in the docs and dashboard. Plain-language definitions of terms used across the platform. Click any entry to expand it. *** ## A — F
Account-to-Account (A2A) Pay by Bank ### Definition Account-to-Account (A2A) payments are electronic payments made directly from the payer’s bank account to the merchant’s bank account without using a payment card. A2A payments are typically initiated through Open Banking or other regulated bank payment services, allowing customers to authorize payments securely using their online or mobile banking application. ### Key Benefits * Direct bank-to-bank payment processing * No payment card required * Lower payment processing costs * Fast payment confirmation * Strong Customer Authentication (SCA) supported by the customer’s bank * Reduced risk of card-related fraud ### How It Works 1. The customer selects Pay by Bank during checkout. 2. The customer chooses their bank. 3. The customer is securely authenticated by their bank. 4. The payment is authorized. 5. The merchant receives the payment confirmation and completes the order.
Access Control Server (ACS) A component of the EMV® 3-D Secure (3DS) infrastructure, typically operated by or on behalf of the card issuer. The ACS authenticates the cardholder during the payment process, determines whether additional verification (a challenge) is required, and returns the authentication result to support secure transaction authorization.
Application Programming Interface (API) An Application Programming Interface (API) is a set of rules and endpoints that enables software applications to communicate with each other. In the Payment Gateway, APIs allow merchants to integrate their applications with the Gateway to perform operations such as creating payments, retrieving payment information, processing refunds, managing tokens, and receiving payment status updates.
Authentication The process of verifying the identity of the payer before a payment is authorized. Authentication helps confirm that the person initiating the transaction is the legitimate cardholder or account holder and reduces the risk of fraud. For card payments, authentication is commonly performed using EMV® 3-D Secure (3DS), which may include biometric verification, a one-time password (OTP), or other authentication methods provided by the card issuer.
Authorization Authorization is the process in which the card issuer determines whether a payment can be approved. During authorization, the issuer verifies the payment details, checks that the card is valid, confirms sufficient funds or available credit, performs fraud and risk checks, and returns an approval or decline response. For payments that are authorized but not immediately completed, the authorized amount may be reserved on the cardholder’s account until it is captured or the authorization expires.
Bank Identification Number (BIN) A Bank Identification Number (BIN), also known as an Issuer Identification Number (IIN), is the first 6 to 8 digits of a payment card number. The BIN identifies the card issuer and the card network, such as Visa or Mastercard. BIN information can be used to identify: * The card network (for example, Visa or Mastercard). * The financial institution that issued the card. The Payment Gateway may use BIN information to support payment routing, fraud prevention, and the display of card-related information.
Cancellation A Cancellation is the process of voiding an authorized payment before it has been captured. When a payment is cancelled, the authorization is released and no funds are transferred to the merchant. A payment can only be cancelled if it has been authorized but not yet captured. Once a payment has been captured, it can no longer be cancelled. If the merchant needs to return the funds after capture, a Refund must be initiated instead.
Capture Capture is the process of completing a previously authorized payment by requesting the transfer of the authorized funds from the cardholder’s account to the merchant. Depending on the merchant’s configuration, payments may be captured automatically immediately after a successful authorization or captured manually at a later time. A payment can only be captured after it has been successfully authorized.
Card Network (Card Scheme) A Card Network, also known as a Card Scheme, is a payment network that establishes the rules, standards, and infrastructure for processing card payments. Card networks connect card issuers, acquirers, merchants, and payment service providers to enable secure and reliable payment transactions. Examples of major card networks include: * Visa * Mastercard * American Express * UnionPay * JCB * Discover Card networks define the rules for payment processing, security requirements, dispute handling, and settlement, and apply network fees for transactions processed through their systems.
Card-Not-Present (CNP) A Card-Not-Present (CNP) transaction is a card payment in which the physical payment card is not presented to the merchant at the time of purchase. Common examples of CNP transactions include: * E-commerce (online) payments * In-app payments * Mail Order / Telephone Order (MOTO) payments Because the card is not physically present, CNP transactions generally carry a higher risk of fraud than Card-Present (CP) transactions. To help reduce this risk, merchants typically use security measures such as EMV® 3-D Secure (3DS), fraud prevention tools, and risk-based authentication.
Card number (PAN) The Primary Account Number (PAN) is the unique number assigned to a payment card. It identifies the card and is used to process payment transactions. The first 6 to 8 digits of the PAN represent the Bank Identification Number (BIN) or Issuer Identification Number (IIN), which identifies the card issuer and card network. For Card-Not-Present (CNP) transactions, the PAN is typically used together with the card security code (CVV/CVC) and, where applicable, EMV® 3-D Secure (3DS) authentication. {% hint style="warning" %} Merchants should avoid storing or processing raw PAN data unless they are authorized to do so and comply with the applicable PCI DSS requirements. {% endhint %}
Card-on-File (CoF) Card-on-File (CoF) refers to the secure storage of a customer’s payment card details or payment token for future transactions. This allows customers to make repeat purchases without re-entering their card information. Card-on-File can be used for: * One-click payments * Recurring payments (subscriptions) * Unscheduled merchant-initiated transactions (MIT) * Other customer-authorized repeat payments Merchants should not store raw card data unless they are authorized to do so and comply with the applicable PCI DSSrequirements. As an alternative, the Payment Gateway supports Tokenization, allowing merchants to store and use payment tokens instead of sensitive card data.
Card Verification Value (CVV/CVC/CID) The Card Verification Value (CVV/CVC/CID) is a 3- or 4-digit security code printed on a payment card. It is used primarily for Card-Not-Present (CNP) transactions to help verify that the customer has physical possession of the card. The security code is known by different names depending on the card network: * Visa – Card Verification Value (CVV/CVV2) * Mastercard – Card Validation Code (CVC/CVC2) * American Express – Card Identification Number (CID) * Discover – Card Identification Number (CID) For security and PCI DSS compliance, merchants must never store the card security code after a transaction has been authorized, even when using tokenization or Card-on-File services.
Cardholder A Cardholder is an individual or organization that has been issued a payment card by a card issuer and is authorized to use that card to make purchases or other payment transactions. The cardholder initiates the payment and, where required, completes the authentication process (for example, using EMV® 3-D Secure (3DS)) before the transaction is authorized.
Cards Payment Cards are payment instruments issued by a card issuer that enable customers to make cashless payments in-store, online, or within mobile applications. Payment cards can be physical or virtual and are typically issued as: * Debit cards * Credit cards * Prepaid cards Most payment cards operate on a card network, such as Visa or Mastercard, and may also be provisioned into digital wallets such as Apple Pay or Google Pay for secure contactless and online payments.
Chargeback A Chargeback is the process by which a cardholder disputes a card transaction through their card issuer, requesting that the transaction amount be reversed. Chargebacks may occur for various reasons, including: * Fraudulent or unauthorized transactions * Goods or services not received * Processing or authorization errors * Duplicate transactions * Customer disputes regarding the purchase When a chargeback is initiated, the merchant may have the opportunity to dispute it by providing supporting evidence, such as proof of delivery, transaction records, or other documentation. The evidence is submitted through the acquirer, which represents the merchant during the chargeback process.
Dispute A Dispute is the process by which a merchant challenges a chargeback initiated by a cardholder through their card issuer. If the merchant believes the transaction was valid, they may submit supporting evidence through their acquirer to contest the chargeback. Typical evidence may include: * Proof of delivery or service completion * Transaction and order details * Customer communication * Authentication results (such as EMV® 3-D Secure (3DS)) * Any other documentation supporting the validity of the transaction The card issuer reviews the evidence in accordance with the applicable card network rules and determines whether the chargeback should be upheld or reversed. {% hint style="info" %} Not all chargebacks are eligible for dispute. The ability to dispute a chargeback depends on the card network rules and the reason code assigned to the chargeback. {% endhint %}
E-commerce Payments E-commerce Payments, also known as Online Payments, are payment transactions initiated by customers through digital channels, such as websites, online stores, or mobile applications, to purchase goods or services. The Payment Gateway supports multiple online payment methods, including: * Payment cards * Digital wallets (such as Apple Pay, Google Pay, PayPal, and Click to Pay) * Open Banking payments using Payment Initiation Services (PIS) E-commerce payments are Card-Not-Present (CNP) transactions when a payment card is used and may require customer authentication, such as EMV® 3-D Secure (3DS), to enhance security.
EMV® 3-D Secure (EMV 3DS) ### Definition EMV® 3-D Secure (EMV 3DS), commonly referred to as 3DS2, is the global authentication protocol for online card payments (Card-Not-Present or CNP transactions). Developed by EMVCo, it enables card issuers to verify the identity of the cardholder before authorizing an online payment. By securely exchanging authentication and transaction data between the merchant, issuer, and card network, EMV 3DS helps reduce fraud while providing a smoother and more secure checkout experience. ### Key Benefits * Reduces online payment fraud * Increases payment authorization rates by reducing false declines * Supports Strong Customer Authentication (SCA) requirements under PSD2 * Improves the customer checkout experience through frictionless authentication * Optimized for web, mobile, and in-app payments ### Authentication Outcomes Depending on the issuer’s risk assessment, authentication may result in: * Frictionless Authentication – The transaction is authenticated without requiring any additional action from the cardholder. * Challenge Authentication – The cardholder is asked to complete an additional verification step, such as entering a One-Time Password (OTP), approving the transaction in their banking application, or using biometric authentication.
Fraud Fraud is the intentional use of deception to make unauthorized or illegal payment transactions. Fraud may target cardholders, merchants, issuers, or other participants in the payment ecosystem. Common examples of payment fraud include: * Unauthorized use of stolen or compromised payment credentials * Identity theft * Account takeover * Card testing attacks * Friendly fraud (chargeback abuse) To help reduce the risk of fraud, the Payment Gateway supports multiple security measures, including EMV® 3-D Secure (3DS), fraud prevention tools, risk-based authentication, tokenization, and real-time transaction monitoring.
*** ## G — P
Issuer (Issuing Bank) An Issuer, or Issuing Bank, is the financial institution that provides a payment card or payment account to a customer (the cardholder or account holder). For card payments, the issuer is responsible for: * Issuing the payment card * Authenticating the cardholder, where required * Authorizing or declining payment transactions * Managing the customer’s account, available funds, or credit limit For Open Banking payments, the issuer is the Account Servicing Payment Service Provider (ASPSP) that holds the customer’s payment account and authorizes payment initiation or provides account information.
Legal Entity A Legal Entity is an individual or organization that is legally recognized and capable of entering into contracts, owning assets, and conducting business activities. In the context of the Payment Gateway, a legal entity represents the merchant or business that enters into an agreement with the acquirer or payment service provider to accept payments. Information associated with a legal entity typically includes: * Legal name * Registered address * Business registration details * Tax identification information * Authorized representatives This information is used during merchant onboarding and ongoing compliance processes to satisfy regulatory requirements, including Know Your Customer (KYC) and Anti-Money Laundering (AML) obligations.
Know Your Customer (KYC) Know Your Customer (KYC) is the process of identifying and verifying the identity of customers in accordance with applicable regulatory requirements, including Anti-Money Laundering (AML) and Counter-Terrorist Financing (CTF) regulations. KYC checks may be performed during merchant onboarding and throughout the business relationship to verify the identity of individuals or legal entities, assess potential risks, and ensure compliance with applicable laws and payment industry requirements. Typical KYC information may include: * Identity and business registration details * Beneficial ownership information * Business activities * Supporting documentation required by the acquiring bank or payment service provider
Merchant A Merchant is a business or organization that has entered into a Merchant Agreement with SEB to accept electronic payments through the Payment Gateway. Merchants can accept payments for goods and services using the payment methods enabled by SEB, including payment cards, digital wallets, and Open Banking payments (where applicable). Once onboarded, merchants receive access to the Merchant Portal, where they can configure their shop, generate API credentials, manage payment settings, monitor transactions, and access reporting.
Merchant Category Code (MCC) A Merchant Category Code (MCC) is a four-digit code assigned to a merchant by the acquirer based on the merchant’s primary business activity. The MCC is used by payment networks and financial institutions to: * Classify the merchant’s business type * Apply card network rules and interchange fees * Support fraud prevention and risk management * Determine eligibility for certain payment products or cardholder benefits Your MCC is assigned during merchant onboarding with SEB and is associated with your Merchant Agreement. {% hint style="info" %} If you believe your assigned MCC does not accurately reflect your business activity, please contact SEB for assistance. {% endhint %}
One-Click Payments One-Click Payments allow returning customers to complete future purchases more quickly by using previously stored payment credentials. During the initial transaction, the customer provides their payment details and consents to their future use. For subsequent purchases, the customer can complete the payment without re-entering their full card details. Depending on the card issuer’s requirements and applicable regulations, additional authentication (such as EMV® 3-D Secure (3DS)) may still be required. One-Click Payments are implemented using Stored Credentials and are classified as Customer-Initiated Transactions (CIT).
Payment Gateway The SEB Ecommerce Payment Gateway is the platform that enables merchants to securely accept and manage electronic payments through a single integration. It provides access to multiple payment methods, including: * Payment cards * Digital wallets * Open Banking payments (Payment Initiation Services) The Payment Gateway securely processes payment requests, supports customer authentication, routes transactions for authorization and processing, and returns payment results to the merchant. It also provides services such as the Merchant Portal, Merchant API, Hosted Checkout, Web Plug-ins, Mobile SDKs, Tokenization, and EMV® 3-D Secure (3DS). Merchants access the Payment Gateway as part of their Merchant Agreement with SEB, which acts as the merchant’s acquiring bank.
PSD2 (Second Payment Services Directive) ### Definition The Second Payment Services Directive (PSD2) is a European Union regulation that establishes the legal framework for electronic payments and payment services within the European Economic Area (EEA). PSD2 introduced stronger security requirements for electronic payments, increased competition by enabling Open Banking, and enhanced consumer protection. ### Key Requirements PSD2 introduced several important changes for payment service providers and merchants, including: * Strong Customer Authentication (SCA) for most electronic payments * Open Banking, enabling licensed third-party providers to access banking services through secure APIs with the customer’s consent * Enhanced consumer protection and payment transparency * Standardized security requirements for payment service providers ### Merchant Impact For merchants, PSD2 primarily affects how online payments are authenticated. Depending on the payment method, customers may be required to complete Strong Customer Authentication (SCA)before a payment can be authorized. Authentication is commonly performed using technologies such as EMV® 3-D Secure for card payments or the customer’s online or mobile banking application for Open Banking payments. Certain transactions may qualify for regulatory exemptions where permitted by the issuer and applicable regulations.
PCI DSS Self-Assessment Questionnaire (SAQ) ### Definition The PCI DSS Self-Assessment Questionnaire (SAQ) is a validation tool published by the PCI Security Standards Council (PCI SSC). It enables eligible merchants and service providers to assess and confirm their compliance with the Payment Card Industry Data Security Standard (PCI DSS). The type of SAQ a merchant must complete depends on how cardholder data is accepted, processed, or transmitted within their payment environment. ### Common SAQ Types for Ecommerce The most common SAQs for ecommerce merchants are: * SAQ A – For merchants who fully outsource the collection, processing, and transmission of cardholder data to a PCI DSS compliant payment service provider. Merchant systems do not store, process, or transmit cardholder data. * SAQ A-EP – For merchants whose payment page can influence the security of the payment transaction, even though cardholder data is processed by a PCI DSS compliant payment provider. ### SEB Ecommerce Payment Gateway The SEB Ecommerce Payment Gateway is PCI DSS Level 1 compliant, the highest level of PCI DSS certification for service providers. Depending on the integration method you choose, your PCI DSS validation requirements may differ. Important: The applicable SAQ is determined by your complete payment environment and implementation. Merchants remain responsible for assessing their own PCI DSS compliance requirements.
*** ## R — Z
Recurring Payments Recurring Payments are payments that are automatically charged at agreed intervals (for example, weekly, monthly, or annually) after the customer has provided their initial authorization and consent. Recurring Payments are commonly used for: * Subscription services * Memberships * Utility bills * Other regularly scheduled payments The Payment Gateway supports recurring payments using Stored Credentials and Tokenization, allowing merchants to securely initiate future payments without storing sensitive card data. Depending on the payment scenario and applicable regulations, the initial payment may require EMV® 3-D Secure (3DS) authentication. Recurring Payments are classified as Merchant-Initiated Transactions (MIT) following an initial Customer-Initiated Transaction (CIT).
Refund A Refund is the process of returning funds to a customer after a payment has been successfully captured. Merchants can issue a refund for various reasons, such as: * A cancelled order * Returned goods * Service cancellation * Customer goodwill * Order adjustments Refunds are initiated by the merchant and processed through the Payment Gateway. Once completed, the funds are returned to the customer’s payment account in accordance with the card network or payment method rules.
Scheme Fee A Scheme Fee is a fee charged by a card network (such as Visa or Mastercard) for processing card payment transactions through its payment network. Scheme fees are determined by the applicable card network and are typically charged to the acquirer. Depending on the merchant agreement, these fees may be included in the merchant’s overall payment processing fees.
Sensitive Authentication Data (SAD) Sensitive Authentication Data (SAD) is security-related information used to authenticate a cardholder or authorize a payment transaction. Examples of Sensitive Authentication Data include: * Card Verification Value (CVV/CVC/CID) * PINs and PIN blocks * Full magnetic stripe (track) data * Chip (EMV) authentication data Sensitive Authentication Data is subject to strict PCI DSS requirements and must not be stored after payment authorization, even if the merchant is PCI DSS compliant.
Strong Customer Authentication (SCA) ### Definition Strong Customer Authentication (SCA) is a security requirement introduced by the Second Payment Services Directive (PSD2) to reduce fraud and increase the security of electronic payments within the European Economic Area (EEA). SCA requires customers to verify their identity using at least two independent authentication factors before certain electronic payments can be authorized. ### Authentication Factors SCA is based on the following authentication factors: * Knowledge – Something the customer knows, such as a password or PIN. * Possession – Something the customer possesses, such as a mobile device, hardware token, or one-time password (OTP). * Inherence – Something the customer is, such as a fingerprint, facial recognition, or another biometric characteristic. The authentication must use at least two of these three factors. ### How SCA Is Applied For online card payments, SCA is commonly performed using EMV® 3-D Secure (EMV 3DS). For Open Banking and Account-to-Account (A2A) payments, authentication is typically completed through the customer’s online or mobile banking application. Certain transactions may qualify for regulatory exemptions or may be considered out of scope, subject to applicable regulations and the issuer’s risk assessment.
Subscriptions Subscriptions are a type of Recurring Payment in which a customer is charged automatically at predefined intervals (for example, weekly, monthly, or annually) for an ongoing product or service. Common examples include: * Video and music streaming services * Software subscriptions (SaaS) * Memberships * Utility or service plans Subscriptions are processed as Merchant-Initiated Transactions (MIT) following an initial Customer-Initiated Transaction (CIT) in which the customer provides consent for future recurring charges.
Tokenization Tokenization is the process of replacing sensitive payment data, such as a Primary Account Number (PAN), with a unique, non-sensitive value called a token. The token can be safely stored and used for future payment transactions without exposing the original card details. Tokenization helps reduce the handling of sensitive payment data and enhances the security of payment processing. The Payment Gateway uses tokenization to support features such as: * Stored Credentials * One-Click Payments * Recurring Payments (Subscriptions) * Merchant-Initiated Transactions (MIT) {% hint style="info" %} A payment token has no intrinsic value outside the Payment Gateway and cannot be used to reconstruct the original card details. {% endhint %}
Transaction (Tx) A Transaction (Tx) is a payment operation processed through the Payment Gateway. A transaction represents the lifecycle of a payment, from initiation through authorization, capture, settlement, refund, or cancellation, depending on the payment flow. Transactions can be initiated using supported payment methods, including: * Payment cards * Digital wallets * Open Banking payments (Payment Initiation Services) Each transaction is assigned a unique Payment ID, which can be used to identify, track, and reconcile the payment throughout its lifecycle.
Webhook A **Webhook (also referred to as callback notifications)** is an HTTP notification sent by the Payment Gateway to a merchant-defined endpoint whenever a payment event occurs. Webhooks provide real-time updates about payment status changes. They enable merchants to automate business processes, such as: * Updating order status * Confirming successful payments * Processing refunds or cancellations * Triggering fulfilment or delivery workflows * Reconciling payment transactions Each webhook notification includes the Payment ID and the latest Payment Status. After receiving a webhook, merchants should call the Get Payment Information API to retrieve the complete and current payment details. {% hint style="info" %} To receive webhook notifications, merchants must configure a Callback URL in the Merchant Portal. {% endhint %}
*** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/getting-started/glossary.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.