Glossary

Money in the currency and form (cash, bank, electronic money) in which it can be used for payment processing in a specific situation.

In a broader sense, means of payment include stocks, precious metals, and other objects. However, when the payment platform is used for payment processing, it usually involves the use of money.

An object which allows its holder to manage means of payment (for example, cash, payment card, or e-wallet).

Thus, a banknote allows its holder to pay for goods and services up to any amount within the banknote's face value (or pay for the part of a larger amount), a payment card allows its holder to manage funds available in the linked account while an online banking account provides its holder with access to funds available in all their accounts with this bank, and so on.

A specific way to process payments with a unique set of characteristics for customers.

Each payment method is characterised by a set of properties in which supported payment and operation types, regions and currencies, payment instruments and user scenarios all play a significant role. As a rule, there is a certain product of the payment system or provider with its own trademark, specific traits and restrictions which corresponds to each payment method. For example, Apple Pay and Google Pay can be considered payment methods with specific payment scenarios important for customers.

The ecommpay payment platform supports a variety of payment methods; the up-to-date information about payment methods can be found at Methods.

A property of the payment method common for all user scenarios when this payment method is used.

For example, payments through payment terminals are typically relevant for one-time purchases made with several payment instruments (cash, payment cards, e-wallets); moreover, such purchases usually imply that customers may need certain time to get to the terminal after the purchase was initiated. In this example payments through terminals are a payment method type while payments through the terminals of specific payment systems are separate payment methods. Similar logic can be applied to mobile payments, online banking and other payment methods and payment method types.

A property of the payment card that identifies the source of the funds on the account linked to it and can influence the scope of its features and benefits.

Basic card types most frequently used in the payment industry nowadays are credit, debit, and prepaid cards. In addition, card networks may offer other types such as pay cards or cards with overdraft coverage. Together with such criteria as the card brand and the cardholder category (according to the issuer's classification), the type of the card can impact its conditions of use. For example, certain prepaid cards cannot be used for payouts, there can be additional fees for the holders of credit cards, and depending on the type of the card, various restrictions on the number and the amount of allowed operations can apply. On the other hand, with certain payments, there can also be restrictions imposed due to the MCC (Merchant Category Code) and the region of the merchant's business operation.

To ensure maximum efficiency when processing payments made with cards of different types, the merchant can do the following:

• Find out what restrictions are imposed on cards of different types in the merchant's industry, and, if it is relevant, inform the customers which cards are allowed and which are preferred for making different kinds of payments.
• Set up processing of callbacks with information about declined operations, and, when it is relevant, provide the customers with detailed information about the reasons for operation declines due to issues related to their cards (this information is communicated via specialised codes and messages.

Along with that, as always, you can refer to your ecommpay account manager and the technical support for more information.

A time span within which operations that have been processed are summed up.

This time span is equivalent to the period of 24 hours with the length variation due to daylight savings taken into account. The beginning and the end of the operation day in different cases varies depending on a number of factors (for example, the time zone in which the merchant operates). For more information about these factors, contact your account manager or the technical support.

A project which defines interaction between the merchant's web service and the payment platform.

Each project is characterised by a set of supported payment methods and other parameters which specify how payments are executed and how the interaction with the web service is organised (for example, the way callbacks are handled). The ecommpay technical support specialists are in charge of registering and setting up the project's parameters, and merchants are provided with the IDs of their projects for working with the platform.

In addition, depending on the context, the term project can be used in this documentation to refer to other things, for example, when web service development projects of the merchant are mentioned.

A series of actions performed in order to execute the merchant's request for transferring funds between the merchant and the customer or the customer and the third party.

The funds can be transferred from the customer to the merchant (then it is a purchase) or from the merchant to the customer (then it is a payout). Only processed purchases can be refunded, thus refunds do not constitute a separate payment type. At the same time, account verification is classified as a separate payment type which includes transferring a zero amount or placing a hold for a specified amount on the customer's card account and the subsequent cancellation of this hold.

At the moment, the following payment types are supported in the ecommpay payment platform:

• purchase—one-time transfer of funds from the customer to the merchant, in one or two steps, by using one of the interfaces.
• invoice—payment link purchase in one or two steps.
• recurring—COF purchase on demand or with automatic debiting.
• payout—transfer of funds from the merchant to the customer.
• account verification—payment instrument validity check.

More information about payments as well as requests and operations used for working with payments can be found at Payment models and statuses.

A sequence of actions which is logically complete and which is carried out as part of the payment execution.

To illustrate, three operations auth, capture, and refund are executed as part of a purchase. More information about payments and operations can be found at Payment models and statuses.

A payment which can be processed only if the customer consents to have their payment credentials stored and used; the debiting of funds is performed on the basis of the provided consent and can be initiated by the customer or by the merchant.

These payments can require authentication, i.e. verifying the authenticity of the payment instrument (for example, by entering the card verification code), or they can be processed without it. COF payments with authentication include purchases with token or saved payment instrument data; COF payments without authentication include recurring purchases (one-click, auto- and regular purchases).

A COF purchase with each debiting of funds initiated by the customer.

For example, an online cinema customer can pay for renting one or more movies using saved card data without providing the card verification code.

A COF purchase with nonscheduled debiting of funds for a fixed or variable amount initiated by the merchant once or multiple times.

For example, an autopurchase is relevant when the available balance of the customer's account gets lower than the specified threshold; in this case, the customer's card can be debited automatically to add funds to the account.

A COF purchase with a series of scheduled debiting payments for a fixed amount and without a specified date for the last payment initiated by the merchant.

For example, the card of an online cinema customer is charged monthly for a fixed amount to pay for movie streaming subscription.

A system message which is an HTTP POST request with a specific structure sent to a URL provided by the merchant when the specified conditions are met.

Callbacks pass information to merchants: for example, that they need to redirect the customer to the provider's website, that an operation was executed with a certain result, or that a token was created. The structure, URLs, and events that trigger callbacks are configured according to the merchant's needs. More information can be found at Callbacks.

A string generated from a set of data to be signed with the use of a secret key. It is used for ensuring authenticity and integrity of data which is transferred in requests and callbacks between merchants and ecommpay.

Certain specialised components developed by ecommpay make generating and verifying the signature easier. These components include CMS modules and SDKs for web services developed in various programming languages.

More information on generating signature can be found at Signature generation and verification.

A regulated process of disputing a financial operation in order to return its full or partial amount.

Chargebacks can be filed on the customers' or issuers' initiative to dispute separate operations. This can happen for various reasons, for example, when a customer is unhappy with the service quality or an issuer is unable to credit a customer's account for technical reasons.

For more information about chargebacks and the work with them, see the corresponding FAQ subsection.

A logical node that contains a set of parameters for displaying Payment Page depending on specific cases, properties of a particular project, and additional attributes.

The terminals can be created when the standard Payment Page layout is changed: for example, when it comes to applying customised text elements, changing the payment form design, or configuring the set of available payment methods. The terminals are set up by the technical support specialists; each terminal is assigned an identifier which is then provided to the merchant and should be specified in the terminal_id parameter for the payment form to open with the properties of a particular terminal.

An identifier that refers to the sensitive data to safeguard it.

In the ecommpay payment platform, tokens are generated for payment card data and are used for ensuring secure communication of this data between ecommpay and merchants during payment processing. In addition, specialised API tokens associated with specific user accounts are used for accessing Data API.

Other types of tokens can also be used in the payment platform. These tokens are generated by services of payment systems and providers, for example, Apple Pay and Google Pay tokens or the authorisation and payment tokens used for processing Telegram bot payments.

An organisation which acts as a global (or domestic) payment technology company that provides services such as authorisation, processing, clearing and settlement of financial payments as well as managing and processing diverse payment data.

Global and domestic card organisations establish cooperation between acquirers (on behalf of merchants) and issuers (on behalf of customers). Global card organisations include Visa and Mastercard, domestic card organisations — China UnionPay.

A company which is a member of the card organisation (global or domestic) and which issues payment cards in accordance with the card organisation’s rules.

Payment cards offered by the issuer can be used by customers for making payments.

A category of cards offered by the card network that differs from other categories by its name and a set of properties.

For example, Maestro and Mastercard are brands of the Mastercard network.

An identifier which characterises the primary business activity of the merchant and which is assigned by the acquirer in accordance with the rules of card organisations.

For example, code 7372 corresponds to computer programming, integrated systems design, and data processing services, while code 8299 corresponds to educational services. Depending on the code assigned to the merchant, different fees can apply to the processing of operations by the payment system, and certain operation types (for example, increasing the authorised amount) may not be allowed.

An identifier which provides information about the issuer of the payment card and the properties of this card.

PAN is generated according to the specific rules, is usually located on the front of the payment card, and is necessary for any operations with cards.

A standard for protecting cardholder data.

PCI DSS is developed by the Payment Card Industry Security Standards Council (PCI SSC) and sets requirements for all companies that process, store, or transmit payment card data. Complying with the PCI DSS requirements is absolutely mandatory for all parties involved in processing card payments.

Automated vulnerability scanning of the merchant's network infrastructure that is performed by the companies authorised to provide the scanning services (PCI SSC Approved Scanning Vendor, ASV).

ASV scanning must be performed quarterly and after every significant change in the network infrastructure. Significant changes are the ones that can increase the vulnerability of the cardholder data: for example, installing new software components or changing the network topology.

The list of the authorised scanning service providers is presented on the PCI SSC website. The ecommpay merchants can select these providers on their own and, if relevant, involve a provider that is in partnership with ecommpay. To activate this ASV scanning service, contact the ecommpay key account manager.

A code used for card authentication.

Card Verification Code 2 (CVC2), Card Verification Value 2 (CVV2), and Card Identification Number (CID) can be used for card-not-present operations. In case of physical cards, these codes are located either on the front or the back of the card while in case of virtual cards, they can be absent and provided to customers in a different way.

Online payment security protocol which is used for cardholder authentication and is based on a three domain model: it includes the acquirer domain, the issuer domain, and the interoperability domain (of the card organisation).

A service provided by global card organisations which allows merchants and acquirers to reduce the risk of payment fraud by comparing the postal address specified by a cardholder when making a payment with the address which is kept on file as current for this cardholder by the issuer.

A category of payments when a cardholder provides the merchant with the payment card data via telephone, mail, fax, or email in order to make a payment.

In certain cases MO/TO payments can be processed without card verification code.