Integrating 1C-Bitrix with BelVEB: where payment breaks
Integrating 1C-Bitrix with BelVEB most often fails not at the connection stage, but at the junction of the payment gateway and the order logic.
The customer goes to the payment page, the bank debits the funds, but Bitrix does not receive confirmation — the order remains in the "awaiting payment" status. The money is gone, the goods are not shipped, and you have to sort this out manually using the statement.
The first typical failure is a broken session when returning from the payment page. If the user closed the tab or lost connection, the browser does not pass the result back, and the order hangs.
This is fixed not by "tweaking the button," but by a server notification from the bank: the gateway itself informs the system of success or failure, regardless of whether the buyer returned to the site.
The second is a desynchronization of Bitrix order statuses. The store and the bank interpret intermediate states differently: partial payment, hold, cancellation after debit.
Without an explicit mapping of the gateway's response codes to internal statuses, an order can "jump" between states or hang forever.
The third is repeated notifications. The bank has the right to send confirmation several times, and without protection against duplicates, the system counts a single payment twice or releases the hold too early.
A separate headache is reconciliation: a discrepancy between the bank's transaction log and the order history surfaces later, in accounting.
Let's break down how this is closed: server notifications, an explicit status map, and idempotent processing — that way a payment failure on the site stops turning into lost orders.
What a correct payment gateway integration delivers
A correctly assembled payment gateway changes not "convenience" but measurable metrics: the share of successful payments, the time from charge to order confirmation, and the number of manual reconciliations in accounting.
When the acquiring module BelVEB is connected to order placement at the level of statuses, rather than "on the side," the payment and the order live in a single scenario — this is the difference between working payments and constant disputes.
Payment success rate
A payment fails not at the gateway but at the junction: the customer went to the payment page, came back, and the order is in "pending" status.
We handle both the redirect and the asynchronous notification from the bank, so confirmation does not depend on whether the customer closed the tab. The share of payments reaching "paid" status stops being lost to returns and timeouts.
Order confirmation time
An order is moved to "paid" based on confirmation from the bank, not on the customer returning to the site. The manager sees the payment at the moment it actually went through — without manually checking the statement and calling the customer.
For the delivery service, this is the difference between "we're picking today" and "we'll check tomorrow."
Double charging and reconciliation
The class of failures that costs the most in reputational terms is a repeat charge when the page is refreshed or the network fails.
Idempotency by order identifier and correct handling of repeated notifications eliminate it at the logic level, not with "we'll refund it later." Transaction reconciliation against the bank statement runs on a schedule: discrepancies surface as a report, not as a customer complaint a week later.
What this delivers in numbers
Taken together: the share of successful payments grows thanks to eliminated breaks on the return, order confirmation time is reduced to the moment the notification arrives, and manual reconciliations are replaced by an automatic report.
Accounting gets consistency for every transaction, and support gets fewer requests saying "the money was charged but there's no order."
Connection methods: payment module, gateway, manual reconciliation
The method of accepting payment is determined by how the store receives confirmation of the transaction and who is responsible for matching the order with the payment.
For BelVEB, three schemes are used in practice: a ready-made payment module, integration via a payment gateway using the protocol, and manual reconciliation of payments.
The choice affects the speed of crediting, the volume of manual operations, and which refund and partial payment scenarios are available without modifications.
| Option | When it is suitable | Limitations |
|---|---|---|
| Payment module | A typical store on a current branch, the standard "pay for the order in full" scenario | Depends on the core version and module updates; non-standard discount and delivery logic requires modification of the handler |
| Payment gateway | Partial payments, holding, refunds from the admin panel, and your own personal account are needed | Requires correct configuration of the signature and processing of asynchronous notifications; if the webhook fails, the order status will not update on its own |
| Manual reconciliation | One-time payments, payment by invoice, non-standard terms | The order status is changed manually, the share of errors and the time to shipment grow; it does not scale as the flow increases |
The payment module covers most of the tasks of a small or medium-sized store: it is installed as an extension, configured via the payment mode in the admin panel, and transmits the status to the order itself.
Its weak point is its dependence on standard logic: if you have a non-standard cart calculation or several legal entities per order, the handler will have to be adapted.
The payment gateway provides more control: request signature, idempotency of repeated notifications, separate processing of cancellations and refunds. This is justified when there are many payments and automatic reconciliation is important.
Manual reconciliation remains a workable option for infrequent payments, but with a high flow it becomes a bottleneck — the order status lags behind the actual payment, and discrepancies have to be found manually.
How we implement payment acceptance: stages of work
The work proceeds from an audit of the current payment scheme to handing over a configured system with a confirmed test payment.
The order of stages is fixed: each subsequent one relies on the result of the previous one, so hidden discrepancies in internal reference data and order statuses surface at the beginning, not on launch day.
- Payment audit. We analyze how the order, payment, and status in the accounting system are connected: which details are sent to the payment gateway, where the transaction identifier is stored, and what happens on cancellation and partial refund. The output is a map of the current process and a list of places where the payment diverges from the order.
- Scheme design. We determine which scenario is needed: a one-time payment, an invoice to a legal entity, payment via a link, or from a personal account. We fix which events confirm success and which confirm failure, and how they are reflected in the order and in the accounting system.
- Payment acceptance setup. We connect the store in the bank's personal account and configure payment methods and confirmation scenarios. We place secret keys and connection parameters in a secure vault rather than in the code — when a key changes, edits do not require rebuilding the site.
- Implementation and status handling. We write the payment module and the handler for bank notifications: it receives the result, verifies the signature and amount, and moves the order to the required status. Duplicate and delayed notifications are recognized and do not create duplicate payments.
- Test payment. We run the full cycle in the bank's test environment: successful payment, failure, cancellation, refund. We check not only the fact of the charge itself, but also that the order, the email to the client, and the record in the accounting system received a consistent status.
- System handover. We hand over access credentials, the payment flow scheme, instructions for employees on handling disputed transactions, and the procedure for actions in case of failure. We show where to view the transaction log and how to reconcile a payment with an order.
- Post-launch support. For the first while we monitor payment processing and reconciliation, then move to scheduled support: module updates, response to changes on the bank's side, and handling of non-standard cases.
This order ensures a predictable launch: by the time the system is handed over, the payment scenario has already been tested on real transactions, not just on paper. Describe your payment scheme — we will get back to you with an estimate and a work plan.
What the client retains after implementation
After project handover, the client retains not only a working payment module, but also a complete set of materials that can be used to develop the system, hand it over to a new contractor, and pass audits. Below is exactly what we document and deliver together with the solution.
- Payment flow diagram — from order placement in 1C-Bitrix to payment confirmation and refunds: which events trigger a request, where the transaction status is stored, how repeated notifications from the bank are processed.
- Integration configuration — connection parameters for the acquiring service, settings for the test and production environments, the list of methods used and their purpose, so that the settings can be reproduced when deploying in a new environment.
- Payment documentation — a description of the order and transaction lifecycle, system behavior during failures and timeouts, rules for retries and status processing.
- Reconciliation procedure — the process for matching data from the bank's personal account with orders in the system, the frequency, the responsible parties, and the actions to take when discrepancies are found.
- Administrator guide — a step-by-step manual for employees: how to check a payment status, issue a refund, find the transaction log, and where to look when an incident occurs.
- Error and response matrix — typical acquiring response codes and what to do in each case: from retrying to contacting the bank's support.
- Change log and rollback point — what changed in the integration and when, and how to roll back to the previous working configuration without losing payment data.
Such a set of materials removes dependency on a specific contractor: any documentation engineer can reconstruct the integration logic and continue the work without reverse engineering.
If the bank's tariffs change or new payment methods are added during operation, the update is made in the same materials — they remain up to date rather than turning into an archive.
Case study: reducing stuck orders by 4x
The client is a retail store with delivery across Belarus, card payment via internet acquiring BelVEB. Before the project, orders were created in 1C-Bitrix, and payment confirmation arrived as a separate statement file, which an operator processed manually.
If a payment went through but the statement was delayed, the order remained in the "awaiting payment" status — and such stuck orders accumulated up to 18% of all orders per month.
What it was before
Payment and order lived in two disconnected loops. Only the payment that the operator managed to match with the order manually was considered successful — in fact, the share of successful payments held at 76%.
The rest were handled by hand: the amount, order number, and payment time were reconciled, some orders were canceled, some were refunded to the customer. Reconciliation took 2-3 hours a day, and peak sales days turned into a queue of unprocessed payments.
What was changed
A direct exchange of statuses between 1C-Bitrix and the acquiring was set up: payment is initiated from the cart, and the result is returned to the order automatically, without a statement or manual matching.
Idempotency was added — a repeated bank response does not create a duplicate payment, and stuck orders go into a separate queue with automatic retry of status checks. Only those cases where the bank did not give an unambiguous response were left for the operator.
What it became
The share of successful payments grew from 76% to 94%, and the number of stuck orders decreased by 4x. Manual reconciliations dropped by 80% — the operator focuses on customers rather than reconciling statements.
Order cancellations due to an "unclear" payment status practically disappeared, and customer refunds decreased proportionally to the number of stuck orders.
Metrics before and after: share of successful payments 76% → 94%, stuck orders — minus 75%, manual reconciliations — minus 80%, time for daily reconciliation — from 2-3 hours to 20-30 minutes.
How does card payment differ from payment via ЕРИП?
Card payment and payment via ЕРИП are two fundamentally different scenarios, and the difference becomes apparent already at the moment the payment is initiated.
With card payment, the buyer does not leave the site: the card data entry form opens directly in the online store, the acquiring bank authorizes the transaction within seconds, and payment confirmation arrives via a callback to the server and is immediately recorded in the order.
The status changes synchronously — the customer sees success, and the system is already ready to ship the goods.
ЕРИП works differently. The buyer receives an invoice with a unique number and goes off to pay it via online banking, a mobile app, or a bank branch. Time passes between placing the order and the actual receipt of funds — from several minutes to several hours, and sometimes days.
Payment confirmation does not arrive instantly but as a separate notification from the bank, so the order must be able to exist in an intermediate "awaiting payment" status and correctly transition to "paid" once the funds are credited.
Payment refunds also work differently. For a card payment, a refund is initiated from the store's admin panel and goes through the same channel as the payment — the money is returned to the same card.
With ЕРИП, a refund is more complicated: it is tied to a specific payment document, and funds can only be returned through the bank by processing a separate transaction.
Therefore, it is important for the system to store the payment document number and the history of its statuses; otherwise, a refund turns into a manual search.
In practice, this means that the 1С-Битрикс integration with БелВЭБ must support both scenarios simultaneously: synchronous confirmation of card payment and asynchronous reconciliation of ЕРИП payments against the statement.
Only then will orders not get stuck in an undefined status, and the accounting department will see the real picture of incoming funds.
Common technical questions about integration
Integration with acquiring is almost never a "set it and forget it" affair: the bank changes its tariffs, the store changes its payment scenarios, and accounting changes its reconciliation requirements.
Below are the questions that most often come up after launch, and how we address them at the configuration level rather than through manual edits.
How can payments be tested without making real charges?
BelVEB has a test environment: the payment gateway accepts requests and returns predefined responses — success, decline, timeout.
We deploy a stand with a copy of the catalog and cart, point it at the test address, and run the full cycle: placing an order, going to the payment form, returning to the site, changing the status, exporting to 1C.
We separately test decline and repeat payment scenarios — these are the ones that most often break in production.
What should be done when the tariff or bank details change?
The tariff, merchant identifier, and the set of available payment methods are parameters, not code.
We keep them in the module configuration and in environment variables, so changing the tariff comes down to editing the values and restarting the handler, without rebuilding the site.
If the bank changes the signature format or the set of fields in the response, we update the adapter and run the same test suite — regression takes hours, not days.
How are payment logs and error investigation structured?
Every request and response is written to a separate journal with the order identifier, amount, status, and time. It shows the entire chain: whether the request went to the bank, what came back, and at which step the order got stuck.
Errors are broken down by class — network, bank decline, amount mismatch, repeat payment — and each has a clear response: automatic retry, manual reconciliation, or a notification to the responsible person.
This removes the main support pain point: there is no need to guess whether the payment was lost or the customer closed the window.
If your case is not on the list — describe the task, and we will come back with an estimate and a work plan.
Let's discuss your 1C-Bitrix BelVEB integration task
For the 1C-Bitrix integration with BelVEB to go smoothly, it's important for us to see your current payment flow: how an order is placed, where the status is recorded, who reconciles incoming payments against the database.
Describe the task in your own words — we'll come back with a scope estimate and an implementation plan where each stage is tied to a result, not to an abstract "we'll set up payment."
What we deliver:
- A review of the current payment scenario and the points where the link between order and payment breaks.
- An integration scheme for 1C-Bitrix with BelVEB internet acquiring tailored to your catalog, delivery, and order status rules.
- A scope estimate broken down by stage: setup, test environment, rollout to production.
- An implementation plan with the order of checks at each step and a rollback point.
- A list of customizations needed if part of the logic is already implemented and needs to be built into the new scheme.
- A payment support procedure: how to read the transaction log, what to do when a status mismatch occurs, who receives the notification.
- Agreements on access and the division of responsibilities between your team and ours.
We don't need a finished technical document — a description of the process is enough: how you accept payments now, which methods are already connected, what isn't working for you.
Based on that description, our engineers will put together an estimate and propose a sequence of work. Let's discuss the task — and we'll come back with a concrete plan, timelines, and the composition of stages.