Integration of 1C-Bitrix with the Raschet payment system (ERIP) (Belarus)

1C-Bitrix Integration with the Raschyot (ERIP) Payment System (Belarus)

"Raschyot" is the trade name of the ERIP system used in the context of retail payments. Some Belarusian banks and payment services provide access to ERIP under the "Raschyot" brand, and it is important for a developer to understand: at the technical level this is the same ERIP (Unified Settlement and Information Space), just with a different entry point and API from a specific agent bank. Terminology confusion often leads to a store connecting both "Raschyot" and "ERIP" as two separate payment methods, even though they share the same infrastructure.

Key Difference from Other Payment Systems

ERIP/Raschyot is not a card gateway. The customer does not enter card details on the website. Instead:

1. The store issues an invoice in ERIP via the bank's API
2. The customer receives a unique invoice number (code)
3. Payment is made through any bank connected to ERIP: Belarusbank, Priorbank, Alfa-Bank, MTBank, BelVEB, and others — via internet banking, mobile banking, ATM, or bank teller
4. Payment information is delivered to the store via a webhook

Key point: the "Raschyot" service assumes the customer finds your store in the ERIP service tree. To enable this, your company must have a registered service code in the ERIP tree. Without this code, the invoice-based system will not work.

Connecting Through an Agent Bank

There is no direct ERIP/Raschyot API. Interaction goes through the bank where the company holds its current account. Each bank provides its own protocol:

When developing the 1C-Bitrix handler, the protocol choice is determined by the client's bank. If a bank change is planned, the handler will need to be adapted accordingly.

Implementation in 1C-Bitrix

Placement: /local/php_interface/include/sale_payment/raschyot_erip/

Core initiatePay logic (REST protocol example):

public function initiatePay($payment, $request = null)
{
    $order = $payment->getOrder();
    $billData = [
        'merchantId'   => $this->getParam('MERCHANT_ID'),
        'serviceCode'  => $this->getParam('SERVICE_CODE'),
        'invoiceNo'    => $order->getField('ACCOUNT_NUMBER'),
        'amount'       => $payment->getSum(),
        'currency'     => 'BYN',
        'description'  => 'Order ' . $order->getField('ACCOUNT_NUMBER'),
        'expireDate'   => date('Y-m-d', strtotime('+3 days')),
        'callbackUrl'  => $this->getCallbackUrl(),
    ];

    $response = $this->sendRequest('POST', '/invoices', $billData);

    if ($response['status'] === 'created') {
        $payment->setField('PAY_SYSTEM_ID_EXTERNAL', $response['invoiceId']);
        $this->showEripRequisites($response['invoiceId'], $response['eripCode']);
    }
}

Displaying ERIP Payment Details

The customer needs clear instructions. Different audience segments use different channels:

• Internet banking: ERIP → Search → Enter invoice code or find via service tree
• Mobile app: QR code scanning
• ATM/info kiosk: ERIP → your service → enter order number
• Bank teller: give the teller your service code and order number

The payment system template in 1C-Bitrix must show all options, not just one — this reduces the volume of support requests.

Statuses and Confirmation Logic

Possible ERIP invoice statuses:

Partial payment in ERIP is allowed by default — if it should not be accepted, explicitly set this in the invoice creation request (partialPayment: false).

Double Registration: A Common Mistake

The store creates an ERIP invoice; the customer does not pay. The customer returns and clicks "Pay again" — the store creates a second invoice. Now there are two active invoices for the same order. The customer pays one; the other remains active. Three days later both expire — and the database is cluttered.

Fix: before creating an invoice, check whether an active invoice already exists for this order (store invoiceId in the payment fields of b_sale_payment). If one exists — display its details rather than creating a new invoice.

Real Case: ERIP Tree Registration

A Minsk retail store selling household chemicals. The technical integration took 3 days, but the launch was delayed by 3 weeks — the company did not know that registering a service code in the ERIP tree is a separate administrative process through the bank and the NKFO "Raschyot". Documents, approvals, tree testing. Recommendation: start ERIP registration in parallel with development, not after it.