HighHelp API overview

This section describes the general principles of the HighHelp API: URL structure, request and response formats, and how the API relates to basic integration scenarios.

For more information about the entity model and terms, seeBasic Concepts.

Purpose of the HighHelp API

The HighHelp API is used for server-to-server (H2H) integration of payment scripts and support operations.

Using the API you can:

  • create and process P2P payments and payouts;

  • execute ECOM scripts via the H2H API and through the payment widget;

  • receive information about applications and their statuses;

  • request cash balance;

  • receive service data (lists of banks, supported payment methods, etc.).

When working through the HighHelp payment widget, some operations are performed on the widget side, but the same API endpoints are also used at the core of the widget. Payment and payout scenarios are available for ECOM H2H. For ECOM, only payment scenarios are available via widget (H2C).

Types of integration and documentation sections

Main integration options:

Basic principles of the API

Protocol and data format

  • All API calls are made over HTTPS.

  • Data format is JSON, UTF-8 encoding.

  • Requests and responses use a headercontent-type: application/json.

Examples of API URLs are provided in the integration guides, for example:

Specific base URLs for production and test environments are provided by your manager upon connection.

Versionirovanie and URL structure

The API version is specified in the path, for example:

  • /api/v1/payment/…​

  • /api/v1/bank/…​

The URL structure for payment transactions is as follows:

  • /api/v1/payment/{product}/{flow}

  • /api/v1/payment/{product}/{flow}/info

  • /api/v1/payment/{product}/{flow}/confirm-3ds-result

Where:

  • {product}-- product (p2p, ecometc.);

  • {flow}— direction or operation (payin, payoutetc.).

Service endpoints use separate paths, described inAPI service endpoints.

HTTP Methods and Responses

  • All current API endpoints use the HTTP methodPOST.

  • A successful response contains a JSON object with the operation status and ticket IDs.

  • Technical errors may be returned with HTTP codes from the range4xxor5xxand a body with a description of the error.

The business status of the operation is transmitted in the response fields:

  • status— main status (processing, success, decline, erroretc.);

  • sub_status— substatus (for example,new, requisites, awaiting_3ds_result, payout_processetc.);

  • status_description— text description of the status and reason for refusal, if necessary.

For a complete list of statuses and substatuses, see the sectionStatus codes.

Request Authentication and Signing

All requests to the HighHelp API must be authenticated and signed.

When accessing the API, the following headers are used:

  • x-access-merchant-id— checkout identifier (merchant project).

  • x-access-signature— digital signature of the request.

  • x-access-token— key by which the platform identifies a key pair.

  • x-access-timestamp— signature generation time (Unix time, UTC, in seconds).

The signature is generated based on the request body, normalized into a deterministic string encoded in Base64Url, and the valuetimestamp.

For a detailed normalization algorithm, signature generation rules, and code examples, seeAuthentication and Signature.

Alerts and asynchronous operations

For some operations, the processing result is transmitted asynchronously through notifications:

  • When creating payments and payouts, the API returns the primary status (status, sub_status);

  • when the status changes further, the platform sends an HTTP request to the URL specified in the parametersmerchant_callback_url, merchant_success_callback_url, merchant_decline_callback_url;

  • Each notification contains the current status of the application and additional information. data (amount, currency, details, authentication data, etc.).

Alerts are also signed and before processing in your integration it is recommended to:

  • check the digital signature;

  • implement idempotent processing (ignore already processed statuses);

  • log key fields (identifiers, statuses, amounts).

For details see:

Background information

Additional references that all API methods rely on:

What to read next

We recommend the following order of introduction to the API:

  1. Quick start— minimal scenario for making a test payment.

  2. Authentication and Signature— detailed header scheme and code examples for signing requests.

  3. Review of ECOM H2HAndGeneral requirements for P2P H2H— selection of integration scenario.

  4. API service endpoints— auxiliary operations.

  5. SDK integration examples— working examples of API requests in popular languages.