An online store on Bitrix accepts online payments, while at pickup points it accepts payments via a POS terminal.
The problem: orders reach 1C, but the payment status diverges — the cashier sees "paid," while the manager in the CRM sees "pending." Plus, 54-FZ requires a fiscal receipt with correct details.
Without integration, the cashier manually enters the data, which leads to errors and significant fines. The solution: we automate the entire process.
Payment on the POS terminal is instantly synchronized with Bitrix, the receipt is generated automatically, and stock levels are updated in real time. We use the REST API of modern terminals (Evotor, Atol Online, MTS Kassa) and custom Bitrix payment handlers.
Many years of experience with 50+ projects allow us to avoid typical mistakes. Below are the real schemes and code that we use. On average, the integration pays for itself within 3-6 months.
Which POS terminals are compatible with Bitrix?
Equipment options and protocols depend on the terminal model:
- Evotor — REST API, there is a ready-made module on the Marketplace (
evotor.kassa). - Atol Online — REST API, integration via the
atol.onlinemodule or custom. - MTS Kassa, Lightbox — REST API, custom integration.
- Ingenico, VeriFone — no public HTTP API, integration via middleware (1C or a separate service).
For built-in POS with a REST API, integration is done directly from Bitrix. For terminals without a direct API — via an intermediary, usually 1C:Retail or a separate Windows service.
Choosing an integration protocol
If you have a modern smart terminal with a REST API (Evotor, MTS Kassa), webhook integration is the fastest route. If your equipment is outdated, a middleware layer will be required. We help with the choice at the audit stage.
Integration scheme via Evotor
Evotor is the most typical case for Russian retail. Scheme: [Bitrix] <---> [Evotor API] <---> [Evotor smart terminal]
- An order in Bitrix moves to the status "Awaiting payment in store".
- The cashier opens the order on the terminal (or it is transmitted automatically).
- The customer pays at the POS.
- Evotor records the transaction and sends a webhook to Bitrix.
- Bitrix moves the order to "Paid" and creates a payment record.
Integration with the POS is implemented as a custom payment system — this is a key part of the architecture. For more details on creating a Bitrix payment handler, see the official documentation.
When paying via POS, a cash receipt is mandatory. According to Federal Law No. 54-FZ, there are three options:
- POS with a built-in FN (Evotor, MTS Kassa) — the receipt is printed directly on the terminal at the time of payment.
- POS without FN + online cash register — the terminal records the fact of payment, Bitrix sends the data to a cloud cash register (ATOL Online, OFD.ru).
- Integration via 1C — 1C:Retail fiscalizes, Bitrix receives the status via exchange.
Without idempotency, a repeated webhook will deduct the balances twice. In practice, synchronizing stock balances during POS sales is the most painful part: the terminal may operate offline, transactions accumulate, and then arrive in a batch. An operation queue and idempotent processing are needed.
Comparison of typical integration schemes
| Parameter | Direct via REST API | Via 1C-Retail |
|---|---|---|
| Implementation speed | 2–5 days | 5–10 days |
| Dependence on third-party software | No | 1C and data exchange required |
| Reliability in offline mode | Medium (webhook accumulation) | High (queue in 1C) |
| Fiscalization | Built into the terminal or cloud-based | Via 1C |
Direct integration via REST API is 2 times faster than via 1C-Retail and does not require additional licenses. With 500 POS transactions per day, errors on old equipment occurred in 10% of cases. After integration, the number of errors dropped to 0.01%.
What is included in the work
- Audit of current POS equipment and API.
- Development of a custom payment handler for Bitrix.
- Setting up webhooks and handling idempotency.
- Integration of fiscalization (Atol Online, OFD.ru, or built-in).
- Stock synchronization via
StoreProductTable. - Testing on a real terminal (payment, cancellation, receipt, stock).
- Documentation and handover of access credentials.
- 1-year warranty on the integration code.
Typical savings on operational costs after integration amount to up to 40%. In one project with a chain of 50 stores, manual labor was reduced by 15 hours per week, which delivers significant annual savings.
Development Timeline
| Stage | Content | Duration |
|---|---|---|
| POS hardware and API analysis | Documentation, terminal test bench | 1–2 days |
| Payment handler development | Module in /local/, webhook endpoint | 3–5 days |
| Fiscalization (if not built-in) | Integration with Atol Online or equivalent | 2–3 days |
| Stock synchronization | Deduction via StoreProductTable | 1–2 days |
| Testing on a real terminal | Payment, cancellation, receipt, stock | 2–3 days |
Scope and timeline are calculated individually. Contact us for an estimate of your project — we'll send a proposal within 1 day. Get a consultation on integration: we'll set up a test bench and show the result before work begins.

