What is the 57580.1-2017 standard and how is it related to cybersecurity

Standard 57580.1 is a national standard for information security in the financial sector, created taking into account current threats and the specifics of the activities of credit and other financial organizations (NFO). The Bank of Russia`s Directive No. 821-P, which entered into force in 2018, made it mandatory for all financial market entities, including banks and microfinance companies. This standard is not just a document — it defines the requirements for the implementation of organizational and technical measures to ensure the protection of information, including personal data and banking transactions in electronic form.

GOST was developed as a response to the growing level of threats: from data leaks to compromise of money processing systems. It works in conjunction with other documents and explicitly states what measures should be implemented to ensure the protection of the critical IT infrastructure of the financial sector. Standard 57580.1-2017 is a detailed methodology that defines the specific parameters of a basic set of information security measures. The document clearly regulates the gradation of information security levels depending on the type and class of information systems. This standard is of particular importance in the financial sector, as it provides practical guidance on meeting information security requirements when conducting monetary transactions.

How are the requirements of GOST 57580.1-2017/821-P implemented in practice

Key areas of implementation

The implementation of GOST requirements begins with building an information security architecture in relation to banking business processes. The most affected areas:

Access control: setting up the differentiation of rights by roles, control of privileged accounts.
Incident response and investigation: defining response procedures, connecting SIEM, organizing SOC.
Logging and auditing: maintaining logs for at least 1 year, monitoring administrators` actions.
Protection of communication channels: mandatory encryption, control of tunnels on the perimeter.

Real cases show that failures most often occur at points of human or process factor. One regional bank ignored the requirement to manage tenants in a cloud environment. As a result, unauthorized copying of client documents by the system administrator occurred, which was not included in the audit system. — the incident was revealed only during an external inspection.

What does the regulator check during the 821-P compliance audit?

The Bank of Russia evaluates during an on-site or documentary inspection:

The presence of an approved threat model and an intruder.
Documents: information security policy, information systems register, information security risk matrix.
Recovery readiness: incident logs, recovery plans.
Availability of information security event monitoring services: SOC, SIEM, CMDB.

Especially important: in 30% of cases, according to the Central Bank, The failure is due to the lack of current risk analysis and the lack of relevance of threats. A typical error is incomplete logs, especially in microservice and hybrid architectures.

How to minimize the costs of implementing requirements

A complete one-step implementation of a standard set of information security measures is costly and not always effective.

Recommended:

Select priority protection measures that correspond to the most critical systems.
Use standard solutions: connecting a cloud SOC instead of a full-time team, an open-source CMDB, and built-in IAM mechanisms in existing IT platforms.
Inventory processes: The flexible process of setting up privileges and storing data often provides more than an expensive SIEM without trained personnel.

Reasonable automation and control of the feasibility of organizational measures (for example, mandatory two-time review of access rights per quarter) provide significant savings on long-term support for the requirements of the standard.

How to understand if your organization meets the requirements of GOST 57580.1-2017/821-P

Compliance can be assessed without hiring external consultants. Start by answering the checklist:

Has the threat model and classification of IP criticality been approved?
Is there a person responsible for meeting the requirements of GOST 57580.1-2017/821-P?
Is access control implemented, logging and analyzing changes?
Are up-to-date risk matrices and incident logs maintained?
Is there an incident response and recovery plan?
Has a centralized monitoring system for information security events been implemented?
Are counterparties checked for compliance with information security requirements?
Have the regulations been agreed with the legal department?

If more than three answers are "no", meet with the participants in the process.:

The Information Security Department is the owner of standards and knowledge.
IT/DevOps services - implementers of technical measures.
Legal Service — legal grounds for interaction.
Guide — prioritization and financing of initiatives.

For Valex`s customers and partners, compliance with GOST 57580.1-2017/821-P means a real reduction in risks.:

users` personal and financial data are protected from leaks and modifications;
the system is ready for regulatory checks and audits;
platform integration into corporate structures does not require security improvements;
information security requirements relevant to the banking industry are supported;
compliance with the laws of the Russian Federation, including acts of the Central Bank.

Valek — does not just meet the requirements of GOST 57580.1-2017/821-P. The platform was initially built with these standards in mind, and therefore it is ready for the real challenges of the financial infrastructure.

Joomla module

System requirements:- Joomla version - from 3.0- Virtuemart version - from 3.0- PHP version - from 7.0
Installation:1. To install the payment acceptance module, you must download the archive from your Wallex account.2. Install via the module installer in the admin panel (Extensions -> extension manager -> Download package file, etc.)3. In the module management menu, activate the plugin (Extensions -> Extension Manager -> Management)4. Then go to the Virtuemart admin page and go to: Components->Virtuemart->Payment Methods->Add a payment method)5. Fill in the first tab and click "Save"6. Go to the "Configuration" tab (Settings)7. Fill in the fields and click "Save" (for further configuration, remember the value of the cid[] parameter from the address bar)
Set up links in your Wallex account - My Store-Settings1. Successful URL - https://joomla.retailcrm.club/index.php/compomemt/com_virtuemart 2. Callback - https://joomla.retailcrm.club/index.php?option=com_virtuemart&view=pluginresponse&task=pluginnotification&tmpl=component&pm = X (insert the value from step 8 instead of X at the end)3. Unsuccessful - https://joomla.retailcrm.club/index.php?option=com_virtuemart&view=pluginresponse&task=pluginUserPaymentCancel&pm = X (insert the value from step 8 instead of X at the end)

API For Developers

After your company has passed moderation, you can start receiving funds using the payment form. The link to the payment form is available in the company information and has the format https://wallex.zone/widget /{id}, where {id} is the digital identifier of your seller. In order for the form to work correctly and open, you must send the URL to the client, specifying in the request a set of parameters described below. The best way is to format the sending parameters using a POST request. This can be done using javascript or in a hidden form, although this form will also work if the parameters are simply sent by the GET method. But this method is not considered safe
Description of payment form parameters
client - client`s email address product - Purpose or payment or product name price - The price for one unit multiplied by 100 (if the price is 110.55 euros, this value will be 11055) quantity - Quantity, if greater than 1, then the final amount will be equal to quantity*price currency - Cryptocurrency code for payment (for example, usdt) fiat_currency - The code of the fiat currency (rub, kzt, try) for payment, by default - rub uuid is a unique payment number in our system. If you don`t use identifiers, just set a random value in this parameter language - Transaction language, by default - ru message - A short message to the user will be sent by email when paying description - A brief description of the service, will be shown in the payment form card_number - The card number of the payee (Used only for acquiring), the field is optional sign is a digital signature of the data, a sha1 cache string consisting of the specification of all request parameters and your SECRET KEY:

ALL fields are required

sha1(client+product+price+quantity+currency+fiat_currency+uuid+language+message+description+card_number+SecretKey)

With cryptoprocessing enabled, the following currencies are available: usdt,eth,vtc,so,magic,bb,dodge,kcs,xlm,ltc
After making the payment, the user will be sent for a Successful redirect or an Unsuccessful redirect, depending on whether the payment was successful or unsuccessful, respectively. The previously sent uuid parameter is added to the Successful Redirect and the Failed Redirect at the end so that you can identify the payment from your side. Therefore, the Success Redirect and Failure Redirect links should not contain GET parameters.
Usage example:

$link = 'https://wallex.zone/widget/69?data='.base64_encode(http_build_query([ 'client'=>'test@test.ru', 'product'=>'product', 'price'=>300*100, 'quantity'=>1, 'currency'=>'usdt', 'fiat_currency'=>'rub', 'uuid' => '1234qqqq', 'language' => 'ru', 'description' => 'test', 'sign' => sha1('test@test.ru'.'product'.(300*100).'1'.'usdt'.'rub'.'1234qqqq'.'ru'.'test'.'SECRET KEY') ]));

As soon as the funds are credited to your account, our system sends a POST request to the specified URL callback link. The request contains the following set of parameters: status - success for successful payment, fail for cancellationclient - client`s email currency - Payment currencyamount - Amount of funds transferred uuid - the uuid that you sent when initializing the form commission - payment service commission product - Purpose of payment or, product name sign is a digital signature of the data, a shal cache string consisting of the specification of all request parameters and your SECRET KEY:.

sha1(status+client+currency+amount+uuid+commission+product+SecretKey)

To accept payments in cryptocurrency, the link parameters remain the same, the amount in the price parameter is transmitted in the currency specified in fiat_currency. Our system itself will recalculate the equivalent in the cryptocurrency passed in the currency parameter. At the moment, payments are accepted in ETHEREUM, BITCOIN and USDT (eth, btc, usdt).

Payout API

To create a payout, you need to send a request to the URL https://wallex.zone/payout/new containing a serialized json object in the body, with the following set of parameters:

For payment in the crypt:

merchant* - Store ID uuid - Unique payment identifier amount* - The amount of funds to be credited (in absolute value, floating point, type string, etc.: 123.45) currency* - Payment currency address* - Address for translation type* - Payment type (Crypta/fiat). With the value crypto sign* - Digital signature of data, sha1-hash of a string consisting of concatenation of all values of the request parameters and your SECRET KEY sha1(merchant+amount+currency+address+type+SecretKey)

For payment in fiat:

Before creating a payment in fiat, it is necessary to transfer USDT to the payment balance. Send a POST request to https://wallex.zone/payout/to_pay_balance JSON object: merchant* - Store ID amount* - The amount to be transferred to the payment balance (type string) sign* - Digital signature of data, sha1-hash of a string consisting of concatenation of all values of the request parameters and your SECRET KEY sha1(merchant+amount+SecretKey)
Payment in fiat can occur in 2 variants 1. - Conversion of USDT to the desired fiat at the time of payment at the rate of grantex 2. - Conversion of USDT to the desired fiat in advance by special request To convert, you need to make a POST request https://wallex.zone/payout/convert JSON object: merchant* - Store ID amount* - Amount to convert (type string) currency* - The currency to be converted into (RUB, EUR) sign* - Digital signature of data, sha1-hash of a string consisting of concatenation of all values of the request parameters and your SECRET KEY sha1(merchant+amount+currency+SecretKey)
To create a payment in fiat, you need to send a request to the URL https://wallex.zone/payout/new merchant* - Store ID uuid - Unique payment identifier amount* - The amount of funds to be credited (in absolute value, floating point, type string, etc.: 123.45) currency* - Payment currency (USDT, or if previously converted - RUB, EUR) bank* - Payment bank - Alfa cashin,Tinkoff,Sber,Kiwi,Tinkoff cashin,All banks of the Russian Federation,KZT,EUR number* - Bank card number (type string) month* - Month from the card expiration date year* - The year from the validity period of the card type* - Payment type (Crypta/fiat). With the value fiat fiat* - Payment currency (RUB, EUR) cardholder* - Name of the cardholder (to be filled in for euros) DateOfBirth* - Date of birth of the cardholder (to be filled in for euros), for example 1999-12-12 sign* - Digital signature of data, sha1-hash of a string consisting of concatenation of all values of the request parameters and your SECRET KEY sha1(merchant+amount+currency+number+bank+month+year+type+fiat+cardholder+DateOfBirth+SecretKey)
If all parameters are correct, the server will respond with the status 201 and send the payment request id
If the Callback field for payments is filled in in the store settings, then after processing the payment, data will be sent to this url status - 0 - created, 1 - awaiting moderation, 2 - rejected, 3 - completed id - payout ID error - Error description if any sign is the digital signature of the data, sha1 is the hash of a string consisting of the concaretation of all the values of the request parameters and your SECRET KEY sha1(status+id+error+SecretKey)

Getting the payout list

To receive payments, you need to send a request to the URL https://wallex.zone/payout/list containing a serialized json object in the body, with the following set of parameters:
merchant* - Store ID sign* - Digital signature of data, sha1-hash of a string consisting of concatenation of all values of the request parameters and your SECRET KEY sha1(merchant+SecretKey)
The response will contain an array of items containing:
id* - payout ID status* - 0 - created, 1 - awaiting moderation, 2 - rejected, 3 - completed, 4 - sending a callback, 5 - in the process of payment data* - Data transmitted when creating a payout commission* - Payment commission

Receiving payment

To receive the payment, you need to send a request to the URL https://wallex.zone/payout/get containing a serialized json object in the body, with the following set of parameters:
You can transmit either id or uuid merchant* - Store ID id* - Payment ID uuid* - Unique code specified when creating sign* - Digital signature of data, sha1-hash of a string consisting of concatenation of all values of the request parameters and your SECRET KEY sha1(merchant+id+SecretKey) or sha1(merchant+uuid+SecretKey)
The response will contain an array of items containing:
id* - payout ID status* - 0 - created, 1 - awaiting moderation, 2 - rejected, 3 - completed, 4 - sending a callback, 5 - in the process of payment data* - Data transmitted when creating a payout commission* - Payment commission

Getting a balance

To get the balance, you need to send a request to the URL https://wallex.zone/payout/balance containing a serialized json object in the body, with the following set of parameters:
merchant* - Store ID sign* is the digital signature of the data, sha1 is the hash of a string consisting of the concatenation of all the values of the request parameters and your SECRET KEY sha1(merchant+SecretKey)
The response will contain an array containing:
crypto - Crypto balance p2p - p2p payment acquiring - Acquiring balance payout - Payout balance

PHP SDK

Project OverviewWallet SDK - This is a software development kit that provides a set of tools and utilities for integration with the Wallex payment gateway.
Installationcomposer require sq-dev/wallex-sdk
FeaturesThis section describes the main functions and features of the Wall ex SDK.
Function 1: Create a payment widget

use Wallex\Widget;

$widget = new Widget(1, "secret_key");

$url = $widget->cretePayment(
    "client@mail.ru",
    "Xiaomi 9T",
    1000,
    1,
    "Hello thanks for order",
    "Xiaomi 9T",
    "USDT",
    "rub",
    "ru"
); // Returns payment url

Function 2: Payment confirmation

use Wallex\Webhook;

$payment = new Webhook($_POST);
if ($payment->isVerified("secret_key") && $payment->isSuccess()) {
    // Payment success logic
    //F.e:
    $client = $payment->getClient(); // Get client email
    User::where("email", $client)
        ->update(["balance" => $payment->getAmount()]);
}

Function 3: payouts

use Wallex\Payout;

$payout= new Payout($MerchantId, $SecretKey);

$payout->cryptoPay($address, $amount, $currency);

Contribution We welcome the contribution of the developer community to improving the Wallex SDK. If you are interested in adding your contribution to the Wall ex SDK, please follow these steps:
LicenseThe Wallex SDK is distributed under the MIT license.

What is the 57580.1-2017 standard and how is it related to cybersecurity

How are the requirements of GOST 57580.1-2017/821-P implemented in practice

What does the regulator check during the 821-P compliance audit?

How to minimize the costs of implementing requirements

How to understand if your organization meets the requirements of GOST 57580.1-2017/821-P

Issue an invoice for payment in 2 clicks

Contact us

Your request has been sent successfully!

Support is available in our Telegram Bot

Support is available in our WhattsApp

Phone number for contacting us

Reliable infrastructure

Compliance

What is the 57580.1-2017 standard and how is it related to cybersecurity

How are the requirements of GOST 57580.1-2017/821-P implemented in practice

What does the regulator check during the 821-P compliance audit?

How to minimize the costs of implementing requirements

How to understand if your organization meets the requirements of GOST 57580.1-2017/821-P

Issue an invoice for payment in 2 clicks

Contact us

Your request has been sent successfully!

Reliable infrastructure

Compliance

Start

Your request has been sent successfully!

Wordpress module

Opencart module

Joomla module

Drupal module

1C Bitrix module

API For Developers

ALL fields are required

Payout API

For payment in the crypt:

For payment in fiat:

Getting the payout list

Receiving payment

Getting a balance

PHP SDK

Python SDK