Glossary

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 Orchid 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 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 Orchid 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 Orchid 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 processing.

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

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 (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 Handling 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 Orchid.

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

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. 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 Orchid payment platform, tokens are generated for payment card data and are used for ensuring secure communication of this data between Orchid and merchants during payment processing. In addition, specialised API tokens associated with specific user accounts are used for accessing Data API.

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

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.

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.