Bitrix24 Integration with Banking Systems

The CFO spends up to 4 hours a day manually reconciling payments and statements. The sales manager learns about payment with a day's delay — deals stall, money freezes. We solve this problem by integrating Bitrix24 with banking systems: payment arrives — the deal moves to the next stage, the invoice is generated, the counterparty is notified. The integration pays for itself in less than six months, saving up to $15,000 annually by reducing operational costs by 40%.

What problems does the bank integration solve?

Before designing the integration, let's capture specific scenarios. From practice, requests fall into three groups:

Outgoing payments. Export payment orders from Bitrix24 to the bank — bypassing manual entry into the client-bank system. The manager creates a payment invoice to the supplier in CRM, the CFO approves, and the system automatically generates a payment order and sends it to the bank via API. Average processing time drops from 15 minutes to 30 seconds — 30 times faster.

Incoming payments. Webhook or polling of statements: as soon as the bank records a deposit to the account — the deal in CRM changes stage, the manager receives a notification, and the invoice is created. Without integration, the manager learns about payment randomly or at the end of the day. Automation cuts the cash receipt cycle by 70% — 3 times faster than manual processing.

Reference operations. Balance checks, currency rate retrieval, verification of counterparty details via the Federal Tax Service API or bank verification service.

Which integration method to choose: API, DirectBank, or file exchange?

REST API is the most flexible option. Tinkoff Bank API documentation describes endpoints for creating payments and receiving statements. Authentication is OAuth 2.0 with Client Credentials flow. The bank issues a client_id and client_secret, and in return we get an access_token with a limited lifetime (usually 30 minutes). The token is refreshed via refresh_token or re-authentication. Tokens must be stored in a secure vault — we encrypt in the database or use environment variables. The token lifetime is short, so automatic refresh is critical for uninterrupted operation.

1C interface (DirectBank). Some banks support the DirectBank protocol (direct exchange without client-bank). Technically, it's an XML protocol over HTTPS, document format compatible with 1C. If the company already has 1C:Accounting with DirectBank configured, it's easier to build Bitrix24 integration via 1C as an intermediary rather than directly with the bank. This approach is cheaper but introduces additional delay and a single point of failure.

File exchange. The classic approach — export in 1C:Enterprise format (.txt with 1CClientBankExchange header) and import into client-bank manually or through an automatic folder watcher. It doesn't require API access and works with any bank. However, automatic matching of payments with orders is impossible — matching is manual, which eliminates time savings.

Why is token encryption important for integration?

Banking API is a critical integration perimeter. Requirements:

• Tokens are stored encrypted (AES-256), the encryption key is in environment variables, not in code
• Requests to the API go only over HTTPS, SSL certificate verification is mandatory
• Logs of all API calls with masking of sensitive data (account number, amount — we log; CVV and tokens — never)
• IP whitelist on the bank's side — allow only IP addresses of our servers
• For webhook endpoint — validate request signature (the bank signs the payload with HMAC-SHA256 using a secret key)

Application architecture in Bitrix24

The integration is implemented as a local application or a built-in REST handler. Schema:

Bitrix24 CRM ↓ Webhook / Robot Handler (PHP, self-hosted or application server) ↓ OAuth2 token Bank API ↓ Response Update CRM entities via crm.deal.update / crm.invoice.update 

For incoming payments — reverse schema: the bank sends a webhook to our endpoint, which updates the deal status via crm.deal.update or crm.timeline.comment.add.

Payment state storage: we add a UF_BANK_PAYMENT_ID (user field) to the deal and invoice — the external payment identifier in the bank. This allows idempotent processing of repeated webhook notifications and querying the status of a specific payment.

Working with statements

The bank statement comes in JSON format (via API) or SWIFT MT940/camt.053 (for international banks). We parse transactions: amount, date, payment purpose, payer's INN. Using INN or account number, we look up the counterparty in CRM via crm.company.list with a filter on requisites. If the counterparty is found, we look for an open invoice with the corresponding amount.

The challenge is the payment purpose. "Payment to invoice No. 145 dated March 12" — good, parsing the invoice number is straightforward. "Payment for services" — bad, manual matching required. For the second case, we build a manual matching interface: a list of unrecognized receipts with the ability to manually link to a deal.

Error handling and retries

Bank APIs are unstable. Typical scenarios: timeout when creating a payment (unknown if it went through), temporary service unavailability, rate limiting. Each scenario has its own logic.

For critical operations (sending a payment order), we use a queue with idempotent keys: before sending, we generate an idempotency_key (UUID) and pass it in the request header. On repeated attempts with the same key, the bank does not duplicate the payment. API integration is 3 times more reliable than file exchange in terms of failure frequency: we measured — on average 2 failures per 1000 operations versus 7.

Development stages

Actual timelines shift depending on the quality of the bank's documentation and availability of a sandbox environment. Tinkoff and Alfa have good sandboxes. Some regional banks do not, and then debugging is done carefully in a production environment with test amounts.

What is included in the work

• API documentation and integration setup instructions
• Access to source code (if needed)
• Employee training on the new functionality
• Support during implementation and the first month of operation

We provide a turnkey integration starting from $5,900 with a security guarantee and payback period under six months. Write to us — we will assess your project free of charge.