Lost notifications are a common problem when integrating with bank gateways. Incorrect HMAC configuration or timeouts cause payments to go through while order statuses in Bitrix remain unchanged. We solve this by implementing duplicate API status requests and verifying each notification. The result: zero payment loss and savings of up to 12,000 BYN per year in commissions for an average store.
We were approached by an agricultural holding with a catalog of 10,000 items and a monthly turnover of 500,000 BYN. After connecting standard Belagroprombank acquiring, they faced notification losses: customers paid, but orders remained in 'awaiting payment' status. The cause was incorrect verification settings and gateway timeouts. We developed a custom handler with HMAC check and duplicate status requests. Notifications no longer get lost, and average commission savings amount to about 12,000 BYN per year due to correct payment routing.
Our team has been doing Bitrix integrations for over 6 years — more than 50 projects with payment gateways, including REST API and handlers compliant with Federal Law 54-FZ requirements. We guarantee stable operation and provide documentation for accounting.
Problems we solve
- Belkart limits — the gateway automatically detects the card type, but during testing it often turns out that lower limits are set for Belkart. We configure monitoring and alerts to react promptly.
- Two-stage payment — for made-to-order items, amount blocking rather than deduction is required. Without two-stage mode, customers wait for a refund if the item is out of stock. We implement a 'Confirm deduction' button in the admin panel.
- Notifications — the bank sends POST requests, but if the URL is unreachable or verification is not configured, payments are lost. We add HMAC verification and IP filtering, plus duplicate status requests via API.
How to connect Belagroprombank internet acquiring to 1C-Bitrix?
- Submit an application to the bank — sign a contract for internet acquiring (usually 7–14 business days).
- Get test credentials — endpoint and account data for the test gateway.
-
Develop a custom handler — we create it in
/local/php_interface/include/sale_payment/bapb_acquiring/. The handler registers the order, checks status, and processes refunds. - Configure notifications — specify the public handler URL and set up verification (HMAC or IP whitelist).
- Perform testing — check all scenarios: successful payment, decline, refund, two-stage mode.
- Activate production mode — after successful testing, switch to the production gateway.
Example of order registration via API:
{ "merchantId": "BAPB_MERCHANT_ID", "orderNumber": "BXORDER_34567", "amount": 156800, "currency": "BYN", "returnUrl": "https://shop.by/order/success/34567/", "failUrl": "https://shop.by/order/fail/34567/", "notificationUrl": "https://shop.by/bitrix/tools/sale_ps_result.php", "description": "Online store: order #34567", "sessionTimeoutSecs": 1200 } Why does two-stage payment cut refund time by 3 times?
For agricultural machinery stores where items may be made to order, the two-stage scheme saves time: first we block the amount, then after confirming availability we deduct it. With a single-stage scheme, upon cancellation the customer has to wait up to 8 business days for a refund. With two-stage — the block is released instantly, and money returns in 1–2 days. In Bitrix this is implemented via the 'Confirm deduction' button, which calls POST /orders/{orderId}/deposit.
How we sped up refunds for a garden equipment store
From practice: a Belarusian garden equipment store clicked 'Make refund' — the API returned success, but money arrived in 8 business days instead of 3. The cause: they used refund for a reserved (not deducted) amount. We fixed it by condition — void for status APPROVED, refund for DEPOSITED. Now refunds complete in 2–3 days.
Reporting and reconciliation
The bank provides registry API: GET /reports/transactions?dateFrom=...&dateTo=.... We automate downloading the report at the end of the day and compare with Bitrix data. If discrepancies appear, it's an immediate signal of unprocessed notifications.
What’s included in the work
- Custom payment handler with support for two-stage payment and refunds.
- Notification setup and verification (HMAC or IP whitelist).
- Automatic registry export for accounting.
- Setup and operation documentation.
- Employee training on refunds and reports.
- Technical support at launch.
Comparison of approaches: custom handler vs standard module
| Criterion | Custom handler | Standard module |
|---|---|---|
| Two-stage payment support | Yes | No |
| Void/refund based on status | Automatic | Refund only |
| HMAC notification verification | Yes | No |
| Automatic registry export | Yes | No |
| Belkart support | Full | Limited |
Timeline
| Step | Duration |
|---|---|
| Application to Belagroprombank | 1 day |
| Review and signing of contract | 7–14 business days |
| Handler development | 2–3 business days |
| Testing and debugging | 1–2 days |
| Production activation | 1–3 days after successful testing |
Server technical requirements
- PHP 8.1+, [REST API](https://en.wikipedia.org/wiki/REST) (Wikipedia), cURL, JSON. - MySQL/MariaDB, index setup for payment tables. - Outbound request access: bank IPs must be allowed. - HTTPS support for notification URLs.Why choose us
- 1C-Bitrix certificate and over 6 years of integration experience.
- More than 50 completed projects with payment gateways.
- Result guarantee: the handler works without failures, notifications are not lost.
- We provide full documentation and post-launch support.
Order an integration — we will assess your project in 1 day. Get a consultation on connecting Belagroprombank acquiring to 1C-Bitrix.