Glossary

General terms

Customer

A person who uses the services of the merchant and who can use the functionality of the payment platform, usually for making payments.

Merchant

A company that has entered into a legal agreement with ECommPay to receive payment processing services via the payment platform. Can be one or more related legal entities.

Web service

A website, a mobile application, or any other technical service of the merchant which provides customers with services that, among other things, involve processing payments using the payment platform.

Payment platform

An information system of ECommPay which allows processing different types of payments as well as provides additional capabilities to increase payment acceptance, fraud prevention, and conversion rates as well as to boost customer loyalty and to enhance the merchant's ease of use.

Means of payment

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.

Payment instrument

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.

Payment method

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 Payments by using alternative methods.

Payment method type

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.

Operation day

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.

Payment platform terms

Project

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.

Payment

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). The funds can also be transferred from the customer to the third party (then the payment is classified as money transfer). 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.
  • money transfer—card-to-card money transfer.
  • 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.

Operation

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 refundare executed as part of a purchase. More information about payments and operations can be found at Payment models and statuses.

Credential-on-file (COF) purchase

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).

One-click purchase

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.

Autopurchase

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.

Regular purchase

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.

Callback

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.

Signature

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.

Terminal

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.

Token

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.

Payment card industry terms

Acquirer

A company which is a member of the card organisation (global or domestic) and which provides a range of services for processing card payments to merchants (directly or via providers).

Card organisation

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 — Mir and China UnionPay.

Issuer

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.

Merchant ID, MID

An identifier of the merchant assigned by the provider (which includes ECommPay) or by the acquirer and used for processing card payments.

Merchant Category Code, MCC

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.

Primary Account Number, PAN

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.

Payment Card Industry Data Security Standard, PCI DSS

A standard for protecting cardholder data.

PCI DSS is developed by the Payment Card Industry Security Standards Council (PCI SSC) and defines specific requirements for companies which process, store, or transfer payment card data. Compliance with the up-to-date requirements set forth by this standard is mandatory for all participants involved in processing card payments.

Verification code

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.

3‑D Secure

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).

ECommPay payment platform supports two versions of the protocol: 3‑D Secure 1 and 3‑D Secure 2.

Address Verification Service, AVS

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.

Mail Order/Telephone Order, MO/TO

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.