Integrating Assist Belarus with Bitrix: where payment breaks
Integrating Assist Belarus with Bitrix breaks not at the connection stage, but at the operation stage: the store accepts payment, but the order remains in "pending" status, the item is not reserved, and the customer calls with a receipt in hand.
The cause is almost always the same — a desync between the payment gateway's response and the handler that changes the order status in the system.
The first typical failure is a lost payment status. The gateway debits the funds, but the notification does not reach the site: the server did not respond in time, a security filter kicked in, the handler crashed.
The order hangs as unpaid even though the money is gone, and the manager learns about it from the customer rather than from the system.
The second is duplicate charges and repeat orders. The customer sees an error on the return page, clicks "pay" again, and instead of one order there are two in the database with different payment identifiers.
The warehouse receives a double shipment request, and accounting gets a discrepancy on the statement.
The third is a desync between inventory and payment. The item's reservation is released by timeout before confirmation from the gateway arrives, and the position goes to another buyer. The result is a canceled order with payment and a dispute with the customer.
All three failures are fixed not by "tweaking the button," but by idempotent notification processing, an operations log, and scheduled reconciliation of order payment statuses. Let's break down how this is closed on the store's side.
What a correctly assembled payment flow delivers
A payment flow is not a "pay button on the site" but a chain: cart → order in Bitrix → request to Assist Belarus → confirmation → order status and warehouse documents.
A break at any junction produces the class of failures known as "paid, but the order was not created": the customer sees a charge, while the system shows an abandoned cart.
The share of successful payments in such a flow drops by 15-30% not because of the payment gateway, but because of status desynchronization and timeouts when returning from the payment page.
The key part is automatic order confirmation. The Assist notification handler receives a callback, verifies the signature, checks the amount and order number, and only then moves the order to "Paid".
Idempotency is mandatory: a repeated callback from the payment system must not create a second order or duplicate the charge.
If the customer closed the browser before returning, the order is still confirmed based on the server notification, not on the fact that the "thank you" page was opened.
Payment reconciliation closes the discrepancies between the Assist register and the statuses in Bitrix.
A nightly exchange reconciles completed transactions with orders and flags those where the payment went through but the status was not updated — they are visible and can be investigated further, rather than searched for manually in a statement.
The volume of manual reconciliations drops from a daily review of all transactions to handling isolated discrepancies.
We also configure the behavior for failures separately: payment page timeout, insufficient funds, customer cancellation. Each scenario returns a clear status and does not block a repeat payment attempt — the customer can pay for the same order again without creating a new one.
This is the measurable effect: a higher share of successful payments, order confirmation within seconds rather than after manual verification, and predictable reconciliation instead of digging through statements.
Integration options: comparing the approaches
There are three approaches to accepting payments via Assist Belarus, and the choice between them is not about how "beautiful" the code is, but about how non-standard your exchange with the payment system is and who will maintain the integration after launch.
| Option | When it fits | Limitations |
|---|---|---|
| Standard payment module | A standard scenario: a fixed set of statuses, checkout payment, no modifications to order logic | Does not cover partial payments, non-standard statuses, or the link with 1C — you will have to write the exchange manually |
| Customized exchange on the site side | You need your own order statuses, partial refunds, non-standard logic after payment confirmation | The logic is split between the site and the payment system — whenever the core is updated, it has to be re-checked |
| A separate intermediary service | Multiple sites or points of sale, high load, you need a unified payment log and independent updates | Requires a separate environment and monitoring — it is one more component to support |
What to look at when choosing
The key question is where the order status logic lives. If it is spread between the payment module and 1C, then any discrepancy in the exchange results in an order that is paid but not posted, and it has to be sorted out manually.
An intermediary service removes this coupling: the site and the accounting system communicate with a single node rather than directly with each other.
What the intermediary service provides
It keeps a unified log of all operations, so reconciliation with the payment system takes minutes rather than hours. As the number of sites grows, a new one connects to an already working exchange instead of dragging along a copy of the logic. The failure of one point of sale does not bring down payment acceptance at the others.
If you have a single site and standard orders, the standard module is enough, and we will not overcomplicate things. As soon as partial payments, multiple points, or a link with 1C appear, we consider the intermediary option.
Describe how your order and accounting are set up, and we will come back with an estimate and a plan for the chosen scheme.
How implementation works: stages of work
Implementing payments is not "connecting a module" but a sequence where every step is verifiable.
We start with an audit of the store: we look at the core version, the installed checkout modules, the current payment scenarios, and how the cart passes the order composition.
Already at this stage it becomes clear where the payment will be lost: a custom component template, a hand-written status handler, or the exchange with 1C that overwrites a paid order.
- Audit of the store and the exchange. We record the order status scheme, the points where the payment scenario is invoked, and how the data goes to 1C. We check whether the new payment method conflicts with the ones already working.
- Designing the payment scheme. We determine which scenarios are needed: full payment, partial payment, refund, retry after a decline. We agree on the step at which the order is considered paid and which status it receives in the accounting system.
- Setting up the exchange. We connect the payment gateway, configure request signing and the processing of notifications from the payment system. Separately, we handle idempotency: a repeated notification must not create a second payment or duplicate the order.
- Test payments. We run the entire cycle in the test environment: successful payment, decline, cancellation by the user, refund. We verify that the statuses in the store and in 1C match after each scenario.
- Checking on live traffic. We enable payment for a limited share of orders, review the exchange logs and reconcile the amounts. This catches discrepancies that the test environment does not reproduce.
- Handover to support. We provide the maintenance regulations: how to read the payment log, what to do when a status mismatches, how to roll back changes.
After the handover, the support team knows where to look for the cause if a payment did not go through or a status was not updated. Describe your task — we will come back with an estimate and a work plan.
What the client receives after the work is completed
After the work is handed over, you are left not with a "set of files" but with a working payment acceptance loop with a clear area of responsibility. Each artifact covers a specific scenario: launch, day-to-day operation, incident investigation, or refund. Below is exactly what we hand over.
- Exchange configuration between the website and the payment gateway: connection parameters, list of allowed IPs, request signature and timeout settings. We separately document which values change when moving to another domain or server.
- Order status scheme — a mapping table: status on the payment system side → status in Bitrix → system action (create payment, send email, allow shipment). It shows why an order did not move to "Paid" without reading code.
- Refund policy: who initiates it, what checks are performed before sending the request, how the result is recorded, and what happens if the payment system declines. With defined response times at each step.
- Manager's instruction — step-by-step, with real screenshots: how to verify a payment, what to do with a stuck payment, where to look when the amount does not match. Designed for an employee without technical knowledge.
- Access policy: roles and permissions for payment settings, action logging, key rotation procedure. Keys are not stored in plaintext in the repository.
- Integration documentation: a map of order flows from cart to confirmation, logging points, a list of external dependencies, and escalation contacts.
- Acceptance checklist with test scenarios: successful payment, decline, retry, refund — so you can verify the work yourself without waiting for us.
All of this is handed over to your version control system and wiki, rather than left in a chat thread. Describe your task — we will come back with an estimate and a plan, including the set of artifacts tailored to your process.
Case: store with manual payment reconciliation
An electronics store on 1C-Bitrix accepted payments via Assist Belarus, but order confirmation lived in a semi-manual mode: once an hour a manager exported the transaction registry from the payment gateway's personal account, reconciled it with orders in the admin panel, and manually changed statuses.
With a flow of 300-400 orders per day, reconciliation took 2-3 hours of working time, and on peak days — up to five.
Orders paid in the evening or on weekends hung in the "awaiting payment" status until the next morning, and some customers managed to place a repeat order or leave for competitors.
The root of the problem was not the gateway itself, but the fact that its payment result notifications never reached the order logic: the handler responded to the request but did not change the status, did not write a transaction, and did not trigger an email.
We rebuilt payment acceptance: we connected a notification handler with signature and amount verification, linked it to order statuses in Bitrix, and added idempotency — a repeated notification for the same transaction does not create a duplicate and does not reset an already confirmed order.
Separately, we built a watchdog reconciliation: once a day the system itself compares the gateway's transaction registry with orders and flags discrepancies, so that accounting sees only real exceptions.
| Metric | Before | After |
|---|---|---|
| Order confirmation time | up to 12 hours | 1-2 minutes |
| Share of successful payments | 71% | 89% |
| Manual reconciliation per day | 2-3 hours | 10-15 minutes |
| Orders with lost status | 4-6% | less than 0.3% |
A month after launch, the share of successful payments grew from 71% to 89% — mainly because the customer immediately saw confirmation and did not abandon the cart.
Confirmation time dropped to 1-2 minutes, manual reconciliation turned into handling isolated discrepancies, and managers switched from exports to working with customers.
We replicate the same setup for other Bitrix stores: the payment acceptance logic is transferred, only the credentials and status rules change.
How is card payment different from internet banking payment?
A card payment and an internet banking payment are two different scenarios from an integration standpoint, even though on the buyer's screen they look like two buttons.
In the card scenario, the payment is initiated inside the payment form, authorization happens in real time, and the result comes back almost immediately: confirmation arrives upon the actual charge, and the order status updates at the moment of the response.
With internet banking, the buyer leaves for the banking app, confirms the operation there, and the response may come back with a delay — sometimes within minutes, sometimes after the customer has closed the tab.
If the Assist Belarus integration with Bitrix is built only on the "left-returned" redirect, such payments get lost: the money is charged, but the order sits unpaid.
That is why payment confirmation in both cases is built not on the browser return, but on a server notification from the payment gateway.
We receive it, verify the amount, order number, and signature, idempotently handle repeated deliveries, and only after that move the order to "paid." The browser return is used as an auxiliary signal — to show the buyer the status, but not as a source of truth.
Refund scenarios also diverge. For a card payment, a refund is initiated programmatically from the admin panel or by an order cancellation event, and the refund status arrives as a separate notification.
For internet banking, a refund often goes through the bank and requires manual confirmation on the customer's side, so the system needs a separate "refund in progress" status and a clear transaction history.
We separate these flows at the logic level: different notification handlers, different order statuses, a separate payment log with attempts and gateway responses.
This provides predictable reconciliation with the bank and eliminates the class of errors where the payment exists but the order is not closed.
Common technical concerns before starting
Before starting, the same questions almost always come up — they are not about choosing a payment gateway, but about how to integrate it into an already running store without downtime and without losing orders. Below we have covered four scenarios that most often hold back the decision.
We already have a deployed store with orders — will we have to shut it down?
No. Integration happens at the level of the payment handler and the exchange module: we add a new payment method without touching the catalog, cart, or checkout. We switch over by a flag — until the new gateway is confirmed on live orders, the old one remains operational. Rollback is removing the flag, not restoring a backup.
Is there a test environment, and what do we check in it?
Yes, we work in the payment system's test mode: we run a successful payment, a bank decline, a timeout, and a repeated request.
Separately, we check that the order status in Bitrix changes exactly once — we suppress duplicate notifications from the payment gateway by transaction ID. Only after that do we enable the live environment.
How are refunds configured?
A refund is initiated from the order card in the admin panel and is sent to the payment system as a separate request. If the refund is partial, the amount is recorded in the order history, and the payment status is recalculated automatically.
For reconciliation, we keep a transaction log — discrepancies between the store and the payment system are visible immediately, not at the end of the month.
We have several legal entities — can the flows be separated?
Yes. We map each legal entity to its own store identifier in the payment system, and in Bitrix we link it to a site or warehouse. Orders and reports are not mixed, and accounting receives an export for the required legal entity without manual splitting.
Describe your configuration — how many legal entities, what refund scenarios, what is already deployed — and we will come back with an estimate and a work plan.
Let's discuss your task and come back with a plan
To make the estimate accurate rather than an "market average", we need to understand your store before work begins.
Describe which edition of 1C-Bitrix the project runs on, how the catalog and cart are set up, which payment scenarios are already in use and which need to be added.
Separately, it's important to know how the exchange with 1C is currently structured: export of items, stock and prices, order placement, statuses. This determines exactly where the payment module will fit and whether the checkout logic will need to be restructured.
Next, we build the full picture: which payment methods are critical for your customers, whether one-click payment, installments or partial prepayment are needed, and how refunds and cancellations should behave.
If the store already accepts payments through another system, we'll look at the current settings and transaction history — that way we'll understand what to migrate and what to rebuild from scratch.
As a result of the conversation, you get not general words, but a concrete work plan with stages, timelines and areas of responsibility. Below is what exactly we send after discussing the task.
- A timeline estimate for each stage: module integration, payment scenario setup, test payments, production rollout.
- A work plan with the order of actions and the points where your involvement or access is needed.
- A breakdown of payment scenarios for your store: full payment, prepayment, payment on delivery, refunds.
- A diagram of how the payment module interacts with checkout and the exchange with 1C.
- A list of accesses and data needed to start: test and production accounts, keys, details.
- Rollback options and the procedure if a payment fails or hangs on the bank's side.
- A separate item — what we do with already placed but unpaid orders at the moment of switching.
Describe your current store and payment scenarios — we'll come back with a timeline estimate and a work plan you can start with without rework on the fly.