Glossary

HighHelp payment platform, which accepts requests from merchant systems, processes payments and transfers, interacts with banks and external payment providers and returns the result.

Payment gateway client — a company or service that integrates with an API and/or widget, to accept payments or make transfers.

The end user (merchant's client) who initiates the payment or transfer.

The person to whose account the funds are credited (in P2P and payouts may differ from the merchant).

Business scenario for moving funds (for example, payment for an order or transfer). Within the cash register, it is identified by the fieldpayment_id, specified by the merchant.

Technical unit of processing in a payment gateway (debit, credit, return, payout, etc.).

Merchant's internal settlement account in the payment gateway. In APIs and alerts, identified by the fieldproject_id. Credits, write-offs and payments for transactions are processed through the cash register.

The current cash balance in a specific currency. Includes the amount available for new transactions and the frozen part of the balance.

Part of the cash register balance reserved for unfinished transactions (for example, authorizations before debiting).

Logical unit of merchant integration (online store, service, application), linked to the cash register. Payment methods, keys and URLs for notifications are configured for the project (merchant_*_callback_url). In APIs and alerts, identified by the fieldproject_id.

An external payment partner (bank, payment system, etc.) through which the payment gateway conducts transactions.

A record of a transaction or payment in the HighHelp system. The application contains the parameters of the operation and its current status. Identified by fieldrequest_id.

An appeal regarding a completed transaction (dispute, request for clarification or revision of the result), created and processed in the system.

Embedded HighHelp payment form, rendered and served on the HighHelp side. The payer enters the data on the payment page of the widget, and the payment data is sent directly to the payment gateway.

The interface that the payer sees when working with the HighHelp payment widget. It is acceptable to use the wording “widget payment page”.

HighHelp web interface for merchant employees. Through your personal account you can view balances and transactions, search for payments, manage projects and cash registers, configure keys and URLs for alerts.

Transfers between individuals (person-to-person / peer-to-peer), for example from card to card or from account to account, initiated through a payment gateway.

Internet payments for merchant goods and services (e-commerce scenario, Internet acquiring).

A type of payment in which funds are transferred from the user's account to the merchant's account.

A type of payment in which funds are transferred from the merchant's account to the user's account.

Server-to-server integration (host-to-host), in which the merchant's backend directly calls the payment gateway API. The payment user interface is implemented on the merchant side.

Integration using a widget (host-to-client), in which the payment form is submitted by the payment gateway, is embedded on the merchant’s website or application, and payment data is sent directly to the gateway.

Identifier of the merchant's checkout in the HighHelp system. Sent in every request and notification.

Payment ID in the merchant system. Must be unique within one cash register.

Application ID in the HighHelp system. Generated when a request is created and returned in responses and notifications.

Data set for access to the cash register API: cash register identifier and keys that are used to generate a request signature (RSA keys for RSA-SHA256 or secret HMAC key for HMAC-SHA512).

A cryptographic signature generated on the merchant’s side based on the request data and the cash register key using the RSA-SHA256 or HMAC-SHA512 algorithm. Used to verify data integrity and sender authenticity on the payment gateway side.

A timestamp that is included in the request (for example, a headerx-access-timestamp) and is taken into account when verifying the signature to limit the validity period of the request and protect against repetitions.

HTTP notification (callback) from the payment gateway to the merchant side with notification of a change in the status of a payment or operation (success, refusal, completion of payment, etc.).

Endpoint on the merchant side, to which the gateway sends alerts. The address is set in the project settings or in the parameters of a specific operation (merchant_callback_url, merchant_success_callback_url, merchant_decline_callback_url).