Payment via ERIP breaks at the order confirmation stage
Most often the failure manifests like this: the customer pays for an order via ERIP, the money leaves, but in the personal account the order still sits in the "awaiting payment" status.
The manager sees an unpaid order, calls the customer, the customer sends a receipt — and only then does it become clear that the payment went through.
The cause is almost always that the 1C-Bitrix integration with ERIP is configured to accept a payment but not to confirm it: the system does not receive or incorrectly processes the bank's notification about the transaction status.
The second typical failure is duplicate invoices. When the payment is accessed again (page refresh, return from ERIP, a repeated click), the system creates a new invoice for the same order, and two payments with different numbers go to the bank.
The customer pays one, the second remains hanging, and the end-of-day reconciliation does not add up: accounting spends hours manually matching orders against the statement.
The third failure is lost bank notifications. If the payment confirmation handler does not respond in time or crashes with an error, the bank repeats the notification, but not indefinitely.
Once the attempts are exhausted, the payment remains without a status, and the order "gets stuck" forever. Idempotency matters here too: a repeated notification with the same identifier must not create a new payment or change an already confirmed status.
A separate cause is desynchronization between the website and the accounting system.
The order is placed in 1C-Bitrix, while the actual movement of money is recorded in 1C; if the exchange runs on a schedule rather than on an event, the payment status arrives with a delay and does not match reality.
We break down how this is closed: we set up the receipt of bank notifications, idempotent processing of order confirmation, synchronization of payment status, and notifications to the manager and the customer.
What correct 1C-Bitrix integration with ERIP delivers
Correct 1C-Bitrix integration with ERIP removes the main source of manual work in an online store — reviewing payments "by eye." When payment arrives in the system automatically, the order moves to "paid" status without operator involvement: the share of orders confirmed without a human reaches 95–98%, and the time to be credited in the order status is reduced from hours to 1–3 minutes after the bank confirms the payment.
A separate effect is payment reconciliation. Instead of exporting a statement from the bank and matching it line by line against orders, the system itself links the payment to the order number via a unique identifier.
Accounting gets a reconciled picture for each day, and discrepancies surface immediately rather than at the end of the month, when the customer has already forgotten what they paid and when.
Order statuses stop being a manual field. Payment, cancellation, refund, and partial payment are set based on the actual event from the payment system, not on a customer's call.
This eliminates a whole class of errors: an order doesn't go into assembly without money and doesn't sit "awaiting payment" after the money has already arrived.
For the client, 1C-Bitrix integration with ERIP means predictable load on operators: the more orders there are, the smaller the share of manual operations per order. Below we break down how this works and what is needed for setup.
Methods for Integrating ERIP Payment: Comparison of Options
There are three workable schemes for accepting payment via ERIP, and the choice between them is determined not by how "trendy" they are, but by who manages your invoicing and how often your product range changes.
Below is a comparison based on applicability conditions, not price: the cost of all three is made up of a different set of work items, and at the start this is not always obvious.
| Option | When it fits | Limitations |
|---|---|---|
| Direct connection to the bank | Your own billing, a stable flow of invoices, need for full control over statuses and export | An agreement with the bank, your own exchange module, modifications when the export format changes; connection requests are reviewed by the bank |
| Payment aggregator | Need to launch payment acceptance quickly, no resources for integration with the bank | Intermediary commission, dependence on its regulations and crediting timelines, limited customization of the scenario |
| Manual invoice export | A small number of payments, payment against issued invoices, one-off receipts | Manual labor, a delay between payment and order closure, matching errors as volume grows |
Direct connection
Here you generate the invoice yourself with an identifier in the "Расчёт" system and receive the payment status from the bank. This gives full control: you can close orders automatically, send notifications, and build reporting based on actual receipts.
The price for this is an agreement with the bank and an exchange module that will have to be maintained when changes occur on the bank's side.
Aggregator and manual export
The aggregator takes the work with the bank off your hands and handles the exchange itself: you integrate with a single point and receive statuses through its interface.
The limitation is the intermediary's regulations and commission, as well as less flexibility in non-standard scenarios. Manual invoice export is justified only at small volumes: it does not scale and creates a gap between payment and order closure.
Let's figure out which option covers your accounting scheme without unnecessary modifications.
Stages of implementing ERIP payment in 1C-Bitrix
Implementing payment via ERIP affects not only the checkout page, but also the exchange with 1C, order statuses, and payment reconciliation. That is why we work in stages — from analyzing the current scheme to handing over a configured system with regulations. Below is what the process looks like for the client.
-
Audit of orders and the current payment scheme. We look at how orders are generated, which statuses are used, where amounts are stored, and how data gets into 1C. We identify bottlenecks: manual reconciliations, duplicate orders, status discrepancies after payment.
-
Designing the payment scenario. We determine at which step the buyer goes to ERIP, how they return to the site, and what happens on cancellation and a repeated attempt.
We agree on the status logic: "awaiting payment", "paid", "cancelled" — so that accounting and the warehouse see the same thing.
-
Setting up the exchange with 1C. We configure order export, nomenclature synchronization, and correct transfer of amounts. The exchange runs on a schedule and by events — the order does not "hang" in an intermediate state.
-
Connecting ERIP payment. We integrate the payment module into checkout, configure invoice generation and receipt of payment confirmations. We check that the buyer sees a clear status and the system sees a correct mark.
-
Testing payments. We run through the scenarios: successful payment, cancellation, repeated attempt, delayed payment. We verify that amounts, statuses, and data in 1C match at every step.
-
Handover of the system and regulations. We hand over the configured system, instructions for managers, and the procedure for disputed payments. We show where to view the status and how to reconcile a payment.
-
Post-launch support. We support the first payment cycles, track discrepancies, and adjust the exchange if conditions or nomenclature change.
This order closes the main risk — a discrepancy between the site, payment, and accounting. Describe your order and 1C exchange scheme — we will come back with an estimate and a plan by stages.
What the client receives after integration setup
An integration is considered complete not when "the payment went through", but when the handover of the result does not depend on a specific engineer. Therefore, we document everything needed for operation, maintenance, and handover to another team.
- Exchange configurations: working profiles for the 1C-Bitrix integration with ERIP and the accounting system, parameters for mapping items, rates, and order statuses, settings for retry queues when the gateway is unavailable.
- Exchange scheme: a map of flows "cart → invoice → payment confirmation → closing documents" with idempotency points so that a repeated call does not create a duplicate payment.
- Access policies: separation of rights for payment methods and exports, dedicated service accounts, key rotation, and rules for storing transaction logs.
- Documentation: descriptions of payment and refund scenarios, a list of ERIP error codes with explanations and operator actions, and a manager's guide for manually reconciling stuck invoices.
- Maintenance regulations: frequency of reconciling payments with the bank statement, procedures for handling amount discrepancies, and control points after platform and module updates.
- Diagnostic tools: logging of payment gateway requests and responses, a test environment for running payment and refund scenarios without real charges.
- Rollback plan: the procedure for reverting to the previous payment method while preserving the correctness of already processed transactions.
We hand over each item in a form suitable for work: configurations — in the repository, schemes and policies — as up-to-date descriptions, regulations — with responsible roles specified. Describe your task — we will come back with an estimate and a plan for the set of artifacts.
Case Study: How We Eliminated Double Charges for Payments via ERIP
The client — a service provider with a customer portal on 1C-Bitrix — accepted payments via ERIP and handled requests manually.
The problem didn't manifest constantly, but in batches: when the session between the gateway and the website was interrupted, the buyer saw an error, repeated the payment, and both charges went through.
Refund requests piled up, accounting reconciled ERIP statements with orders manually, and some discrepancies only surfaced at month-end closing.
What It Was Like Before Implementation
The payment handler confirmed the order upon the buyer's return to the website, not upon actual crediting. If the buyer closed the page or lost connection, the order remained unpaid even though the money had already been sent.
A repeated attempt created a second payment, and there was no way to link them together — in the ERIP statement, both payments looked independent.
Refunds were processed manually: the accountant found the payment, initiated a refund in the bank's system, and separately updated the order status on the website. One operation took up to half an hour, and during mass failures the queue stretched for days.
What We Changed
We switched payment confirmation to an asynchronous scheme: the order is closed based on a notification from the payment gateway, not on the buyer's return to the website.
Each payment is assigned a unique identifier, by which a repeated attempt is recognized and does not create a second charge.
Then we added automatic reconciliation: a scheduled task once a day matches the ERIP statement with orders and flags discrepancies.
Refunds moved into the same loop — the operation is initiated from the order card, and the status is synchronized with the bank and the website without manual intervention.
What the Result Was
Double charges stopped: the class of failures in which a buyer pays twice is closed at the level of the confirmation logic. Reconciliation takes minutes instead of manual review, and discrepancies are visible on the first day rather than at month-end closing.
Refunds are processed from the interface in a matter of minutes, and accounting no longer needs to reconcile statuses across two systems.
How is payment via ERIP different from acquiring?
Acquiring is a card flow: the buyer enters card details, the acquiring bank authorizes the transaction online and responds at the moment of payment.
The funds are not credited immediately but through a settlement cycle, yet the "paid" status arrives synchronously, and the order can be processed in 1C almost instantly.
ERIP is structured differently: it is a payment system with a tree of services, where each service corresponds to a code in the hierarchy, and the payment is initiated on the bank's or infokiosk's side, not on the website.
The key difference lies in the confirmation mechanics. With acquiring, the website itself sends a request to the bank and receives a response via a secure channel.
With ERIP, the website only generates an invoice with a unique number and service code, the buyer goes to online banking and pays there, and confirmation arrives via a callback notification from the bank or by reconciling the payment register.
That is, payment is asynchronous: time passes between the buyer leaving for the bank and the "paid" status appearing on the website, and the order cannot be considered closed until confirmation arrives.
The crediting timelines also differ. Acquiring provides instant authorization, while crediting to the account follows the bank's regulations.
ERIP confirms the fact of payment within minutes, but the final crediting and reconciliation proceed in batches, so the integration must be able to wait and re-check the status rather than rely on a single response.
The integration requirements follow from this.
For ERIP, you need service registration in the tree, a correct code and account number, a handler for bank notifications, and regular register reconciliation — otherwise payments will "hang" without being linked to an order.
For acquiring, a payment module and callback processing are sufficient. In practice, many projects maintain both methods: acquiring for fast card payment, ERIP for those who find it more convenient to pay through the bank.
Common technical questions about payment integration
Payment integration almost never happens "in a vacuum": the client already has an accounting system running, with reference data, documents, and roles.
So the first question at the start is not "which module will we install," but "what exactly will have to change in the already deployed system." Below are the things that most often come up during the assessment stage.
What should I do if the exchange with ERIP fails at night and orders get "stuck"?
The first step is not to restart the exchange blindly, but to sort out the queue: which invoices have already been paid on the provider's side but not confirmed on ours. Each confirmation is idempotent — reprocessing the same payment does not create a duplicate order.
If the failure affected the exchange window, payments are caught up from the transaction log, and discrepancies are reconciled by invoice number. The client does not need to do anything manually in this case.
We already have a system deployed on 1C — will we have to rebuild it?
No. The integration is embedded into the current environment: the item, counterparty, and contract reference data stay as they are; only the layer for exchanging payment statuses changes.
We identify the connection points, describe the export formats, and only then touch the code. If the accounting database is non-standard, we first map out the data flows — otherwise any edit breaks the reports.
What is wrong with manual payment export, and when is it still acceptable?
Manual export does not scale: with dozens of transactions per day, discrepancies appear, and reconciliation takes hours. It is justified only at the start or for rare one-off payments, until automatic exchange is set up.
As soon as the flow grows, manual mode becomes a source of errors — the payment status arrives with a delay, and orders go to shipment before confirmation.
What limitations does the integration have, and how do you address them?
The limitations are set not by the payment gateway, but by the exchange regulations: polling frequency, history retention depth, database access rights. We move these parameters into configuration so they can be changed without editing the code.
We separately describe the behavior when the external side is unavailable — queue, retries, notifications to the responsible person. This way, an exchange failure remains an incident on monitoring rather than an accounting problem.
Let's discuss your payment integration task
To come back with an estimate and an implementation plan rather than generalities, we need a picture of your current setup: how orders get into 1C, where invoices are generated, who reconciles payments, and what happens when there's a discrepancy.
The more precise the inputs, the fewer assumptions in the estimate and the more predictable the timeline.
Describe the task — and we'll analyze it on the merits. It's enough to answer a few questions:
- Which 1C configuration is used and how it's connected to the website: exchange via a module, web services, or manual export.
- How payments are currently accepted: ЕРИП, acquiring, cash — and which order statuses are set manually.
- Where order and item records are kept: in 1C, in Битрикс24, or in both systems in parallel.
- Whether there are customizations in the standard exchange and who maintains them — this affects the scope of work.
- Which reports are needed in the end: payment reconciliation, export to accounting, notifications to managers.
- Whether there are restrictions on access, hosting, and the update schedule.
After the analysis, we'll come back with a work estimate and an implementation plan: the stages, what we do at each one, what will be required from your side, and how we'll verify the result before putting it into production. We'll agree on the next steps based on your answers — without unnecessary iterations.