We have often encountered situations where a Belarusian online store loses up to 30% of orders simply because the list of payment methods does not include ERIP. For the local market, this is not just an option but a necessity — over 90% of all non-cash payments in Belarus go through the Unified Settlement and Information Space. Without ERIP, you cut off a significant part of the audience accustomed to paying via ATMs, internet banking, or mobile apps.
Why ERIP is more profitable than card acquiring
ERIP is not instant payment, but a process: the store registers an invoice through the bank agent's API, the buyer receives a number or QR code and pays it at any bank or terminal. Then the system sends a notification. The ERIP commission is 5–10 times lower (0–0.5%) compared to acquiring (1–3%). The average payment confirmation time is 5–15 minutes after payment.
Comparison with classic acquiring:
| Parameter | Card acquiring | ERIP |
|---|---|---|
| Instant payment | Yes (online) | No (requires manual payment) |
| Audience coverage | Cardholders | All citizens of Belarus |
| Commission | 1–3% | 0–0.5% |
| Refund | Standard | Through bank, slower |
Why ERIP is critically important for Belarusian e-commerce
According to National Bank, about 40% of the population does not use bank cards for online payments, preferring terminals and internet banking. ERIP provides access to this audience, increasing conversion by 10–20%. A typical online store receives 50–200 ERIP transactions per day, 70% of which are recurring.
How we implement ERIP integration in 1C-Bitrix
Since there is no single API, integration is built as a custom payment system handler for the sale module, adapted to the specific bank's API. Typical handler structure in /local/php_interface/include/sale_payment/erip/:
handler.php — logic for invoicing and status checking .description.php — metadata, name, icon .settings.php — bankApiUrl, merchantId, apiKey, serviceCode template/ — display of payment details to the buyer Example request to the bank for invoice registration
{ "merchantId": "YOUR_MERCHANT_ID", "serviceCode": "ERIP_SERVICE_CODE", "invoiceNumber": "ORD-12345", "amount": 125.50, "currency": "BYN", "description": "Payment for order No. 12345", "expireAt": "YYYY-MM-DDTHH:MM:SS", "callbackUrl": "https://yourshop.by/bitrix/tools/sale_ps_result.php", "returnUrl": "https://yourshop.by/personal/order/detail/12345/" } serviceCode — service code in the ERIP tree, assigned by the bank upon connection. It is used by the buyer to find the store in the ERIP menu ("Online stores → Category → Your store").
How to display payment details to the buyer?
After issuing the invoice, show:
- The ERIP invoice number (or QR code) for manual payment.
- Instructions: "Internet banking → ERIP → Search by number" or the path through the service tree.
- Invoice validity period (usually 24–72 hours).
- QR code for quick payment via mobile banking.
The template/ of the payment system component handles this screen. The standard "thank you for your order" page is not suitable here — you need a payment waiting page with dynamic status updates via AJAX or WebSocket.
How to process notifications and confirm payment?
The bank sends a POST notification to callbackUrl when a payment is received. The handler should:
- Verify the request signature (HMAC, RSA, or IP whitelist depending on the bank).
- Find the payment by
invoiceNumberorbillId. - Check the amount — the buyer may have partially paid.
- Call
$payment->setPaid('Y')only for full payment. - Update the order status according to business logic.
Partial payment — a specific feature of ERIP. The system allows partial payments. If this is undesirable, specify partialPaymentAllowed: false when registering the invoice.
From our practice: a Belarusian building materials store had a buyer pay an ERIP invoice, but the order was not confirmed due to a 1 BYN discrepancy from manual entry. The solution — add automatic manager notification for deviations up to 1% and a manual confirmation interface in the admin panel. In your project, we will foresee similar scenarios.
What is included in the work
- Analysis of the selected agent bank and obtaining API documentation.
- Development of a custom handler considering the bank's protocol specifics.
- Configuration of the payment details template and waiting page.
- Integration of webhook notifications and handling partial payments.
- Registration of the service in the ERIP tree (support from the bank side).
- Testing the full cycle: invoice issuance → payment → confirmation.
- Provision of setup and operation documentation.
Timeline and stages
| Stage | Duration |
|---|---|
| Obtaining API access from the bank | 3–10 business days |
| Handler development | 2–4 days |
| Integration and testing | 1–2 days |
| Registration of the service in the ERIP tree | 5–15 business days (bank + NCFO) |
Registration in the ERIP tree is the longest stage, independent of the developer. Start it in parallel with development.
Contact us to connect ERIP to your 1C-Bitrix online store — we will assess your project within 1 day and offer the optimal solution for your bank.
We rely on the official ERIP documentation and many years of experience with Bitrix payment systems.