Аккаунт в General iT
Войдите или создайте аккаунт для управления услугами в личном кабинете.
Страны не найдены. Попробуйте другое название или код.
MODULE FOR 1C-BITRIX
Pavel Shulaev
T-Bank Internet Acquiring Payment Acceptance Pro This module connects T-Bank acquiring (formerly Tinkoff Bank) to 1C-Bitrix sites of any edition, from First Site to Enterprise. It resolves standard integration tasks including correct VAT calculation in receipts, protection against duplicate bank notifications, automatic creation of the payment system, and migration from the official module.
T-Bank Internet Acquiring Payment Acceptance Pro
This module connects T-Bank acquiring (formerly Tinkoff Bank) to 1C-Bitrix sites of any edition, from First Site to Enterprise. It resolves standard integration tasks including correct VAT calculation in receipts, protection against duplicate bank notifications, automatic creation of the payment system, and migration from the official module.
The functionality includes QR code payments in digital rubles, support for the Honest Sign marking system, an operation log with T-Bank, and error notifications via the free rover.notifier module.
The product has been available since 2017 and is regularly updated to meet security requirements, bank standards, and Federal Law 54-FZ. Development is performed personally by Pavel Shulaev without outsourcing. This ensures deep architectural understanding and allows for direct resolution of non-standard scenarios, receipt issues, and API integration nuances with the author.
The module supports a wide range of payment methods. Bank cards from the Mir, Visa, and MasterCard systems are accepted. Payment via the Fast Payment System (SBP) by QR code is available, including within a popup widget. Wallets T-Pay, SberPay, Yandex Pay, and MIR Pay are integrated. The digital ruble is implemented as a separate payment method with its own unique QR code. Customers can complete a transaction in a popup window without being redirected to the bank's website. After order placement, the system automatically redirects the user to the payment page. Refunds are processed with an automatic update of the order status to the required state. Partial payments are supported. Seven display modes for the payment form are available, configurable separately for each payment system. This allows the simultaneous use of cards, SBP, T-Pay, and the digital ruble on the website.
Receipts and 54-FZ Law
The module ensures receipt printing via T-Bank with full compliance with 54-FZ Law requirements. All current VAT rates are supported, including calculated rates: 22/122, 10/110, 7/107, and 5/105. It works with all tax regimes: OSN, USN "Income", USN "Income minus Expenses", ESCHN, and Patent.
A complete catalog of calculation items and payment methods is implemented according to FFD, including version 1.2. This allows correct processing of marked goods, contributions, agency payments, and other operations. "Chestny ZNAK" marking codes are automatically extracted from the order shipment and sent to the receipt as a separate line for each item. This requires only FFD 1.2 and filled codes in the order; no manual entry is needed.
If the cash register does not know the VAT rate for an item, it will not be sent to the receipt automatically. The module notifies the user so the rate can be corrected in the catalog rather than searching for discrepancies in the OFD. Closing receipts are generated upon shipment, payment, or transfer of the order to a specified status.
Receipt sending does not conflict with the Bitrix cash register. The receipt is sent to the bank only after the tax regime and VAT rate are filled. If an active Bitrix cash register exists on the site, the module displays a corresponding warning in the payment system settings.
A receipt is sent to the bank even for orders lacking buyer contact details. In such cases, the seller's address is taken from the 'Store email for receipts' field; if this field is empty, the system uses the general site settings. The payment process does not stop due to missing contact information.
When payment is initiated from a Bitrix24 deal, the email and phone number for the receipt are automatically retrieved from the client card, as the order itself does not contain separate contact properties.
Two-stage and recurring payments
The module supports fund holding, allowing payment confirmation with a single click directly from the order card in the admin panel or automatically after a specified timeout in days. An order is marked as paid only after receiving confirmation from the bank. If the charge fails, the operator sees the specific reason and can retry the transaction, avoiding the situation where an order is marked as paid without actual funds received.
After initiating a payment with reservation, the buyer sees a clear message stating that funds are reserved on the card and will be charged once the store confirms the order, rather than an error message. Automatic confirmation of the reservation occurs after the specified timeout expires. Cancelling an order automatically releases the reservation.
The system remembers buyer cards: when a customer pays again, the bank offers the saved card. Card binding settings are available in a general mode or separately for each website.
Automation and flexibility
The module allows configuring order statuses for each event: payment, partial payment, holding, refund, and cancellation.
The order card includes a Send payment link button. If payment has not been completed or ended with an error that can be fixed by retrying, the buyer receives an email with a fresh payment link in a single click. The email template can be freely edited in the admin panel. If the template is missing, disabled, or not linked to the order site, the module notifies the user immediately rather than after a failed send attempt.
The module supports flexible templates for order links in the buyer's personal account. Components for placing the payment form are available for use in the order card, the personal account, any website page, and the Sites24 block.
The system prevents the creation of duplicate payments at the bank. As long as the buyer has not paid and the amount remains unchanged, page refreshes or resending the link result in the same payment. The reuse period is configurable, and the operator can forcibly issue a new link.
The payment system is created automatically during module installation. Its settings open immediately after creation, requiring the terminal and password to be entered.
The module allows migrating settings from the official T-Bank payment module without manual reconfiguration. The terminal ID, password, and receipt parameters are automatically transferred, and the previous payment system is deactivated. Ready-made icons are provided for each payment method, including cards, SBP, T-Pay, and pop-up widgets. The component operates independently of the 'Online Store' module, featuring its own logging and notification settings. Receipt generation and handling of marking codes are available without the 'Online Store' module; the receipt composition is defined by the payment component parameters or an event handler.
Failure notifications
The module alerts the administrator to issues that would otherwise be visible only in logs: payment amount mismatch with bank confirmation, bank notification rejection, missing closing receipt, failure to confirm or release fund reservation, refund to the buyer without order cancellation, VAT rate mismatch between the product and the cash register, and the buyer seeing an error instead of the payment form.
Two independent settings are implemented: critical failures are sent immediately, while buyer errors are grouped. This prevents the mailbox from flooding with identical emails during bank-side failures.
Delivery of notifications via email, SMS, or messengers (Telegram, WhatsApp, MAX) is handled by the free "Error Notifications" module (rover.notifier), which requires PHP 8.2. Without this module, the core functionality remains active, but notifications are not sent.
Payment operation visibility
The "T-Bank Operations" tab is available directly in the order card. For each payment, it displays the bank status and receipt time, the order status set by the module, the bank-confirmed amount, whether a closing receipt was sent, and the terminal used for the transaction.
A detailed operation log is maintained for each order. It records incoming bank notifications, their receipt confirmation, responses to status queries, order status changes, hold confirmations, and receipt dispatches, along with the initiator of each action: the bank, the operator, or a background agent.
Rejected bank notifications are displayed with their specific rejection reasons, explaining precisely why a payment failed to complete.
The log is generated continuously regardless of general logging settings. Storage depth is configurable, with old records automatically deleted. The log does not contain customer personal data or receipt composition details.
Reliability and security
The module prevents duplicate receipts when receiving repeated notifications from the bank. Notification reception is restricted to a whitelist of T-Bank IP addresses. Log rotation and automatic cleanup are implemented with protection of the log directory from direct access. Payment status is stored in a dedicated module table rather than site settings, preventing full data reads on every request even with tens of thousands of transactions. Background auto-confirmation of reserved payments continues despite errors; a failure on one order does not leave other orders unconfirmed. A separate "Debug" tab in the module settings handles logging and notifications without affecting main settings. This functionality is available in all editions, including those without the "Online Store" module.
Compatibility
All 1C-Bitrix editions are supported, including "First Site" and "Start". Composite mode is supported. Adaptive payment templates are provided, with a dedicated template for Sites24. Balance top-up on an internal account is supported. Multi-currency is enabled, and alphanumeric order numbers are handled correctly. Internal events are available for fine-tuning to specific needs.
Support
Full documentation for installation and configuration is provided.
A step-by-step guide for installation, payment system configuration, and verification of the first transaction is available on the Installation tab. Free consultation is provided before and after purchase, including assistance with connection, setup, and test payments. Support is handled by a human specialist rather than a script or an impersonal first-line service. In non-standard cases, the response is clarified directly with the module developer instead of being lost in a ticket queue.
For search: Tinkoff, T-Bank, t-bank, tbank
When needed, General iT can implement “T-Bank Internet Acquiring Payment Processing Pro”, configure the module and verify it against the current website setup.
UPDATE HISTORY
For platforms with multi-currency settlements: deductions, refunds, and automatic payments can be supplemented with custom data—the site subscribes to module events and adds Shops and other fields to Confirm, Cancel, and Init requests before automatic payments. If the handler fails or crashes, the request to the bank is not sent.
An error in the event handler code no longer goes unnoticed: it is recorded in the log and triggers a notification, and the operation completes with an error.
During installation, settings can be migrated from the basic version of the solution: if the website has its payment system, the installer will offer to create a new one based on it - field values and payment mode will be transferred along with it, and the original system will be disabled.
The payment result page no longer hides the website's navigation chain.
Typos in the payment system settings labels have been corrected.
The receipt is sent to the bank along with the order. For orders without buyer contacts, the payment system now has a field 'Store email for receipts' - this is the seller's address in the receipt, and if it is not filled in, the site's email is used. Previously, such orders were sent to the bank without a receipt, and the terminal with a connected cash register responded to the payment with an error.
The buyer's email and phone number are taken from CRM: when paying from a Bitrix24 deal, the order properties remain empty, and the module reads contacts from the client card - the order contact, or if it is absent, from the company.
Digital ruble payment has been added. This is a separate payment method with its own payment system: the buyer sees it as a line in the checkout and pays via QR code, similar to SBP. The method must be enabled in the bank's personal account for the terminal.
Re-displaying the payment form no longer generates duplicate payments at the bank. As long as the buyer has not paid and the amount, receipt composition, or settings have not changed, refreshing the page and re-sending the link return the same payment: the bank records one operation instead of many, and reconciliation with the statement refers to the same payment on which the funds arrived. The reuse period is set in the module settings, defaulting to two hours; setting it to zero disables it. The link-sending popup now includes a "issue a new link" checkbox, in case the buyer needs a fresh one.
Discovered vulnerabilities have been fixed.
Payment widgets have been rebuilt using the bank's current Integration.js script — the previous T-Bank version has been discontinued. The card form still opens in a window overlaying the page via a button; the site creates the payment, and in these modes, return addresses from the payment system settings now work.
Receipt data is sent to the bank according to tax settings, not based on the "Receipt printing allowed" checkbox. The receipt is sent to the T-Bank cloud cash register together with the payment as soon as "Tax system" and "VAT" are filled in; stores with the checkbox disabled will start receiving receipts. To prevent the module from sending receipts, leave both fields empty; the module will warn about an active Bitrix cash register in the payment system settings.
The VAT rate for delivery can be taken from the delivery service — the value with the same name in the "VAT for delivery service" setting. If there are multiple services with different rates, the rate from the payment system settings is used in the receipt, and the delivery name is no longer duplicated.
The bank draws the quick payment buttons: the payment method must be enabled in the acquiring personal cabinet, and text and CSS classes are not applied to the buttons. If the bank does not display a button, the buyer will see a link to the payment form in its place.
Deduction of reserved funds requires confirmation — the button in the order card displays the amount and order number; funds are sent to the bank after clicking "Deduct".
The T-Pay payment page no longer breaks due to a missing QR code — the bank has removed it from the response; the page retains a button to transition to T-Pay.
The "T-Bank Operations" tab no longer loses notifications: missed items are marked as missed, a refund updates the payment status, and there are no duplicate rows for a single event.
The "T-Bank Payment Form" block in Sites24 reappears on the page and collects the receipt itself — it is sufficient to specify the buyer's email or phone number, the tax system, and the VAT rate. Additionally, the kopeck calculation has been fixed: with a fractional price, the receipt amount previously differed from the payment amount, causing the bank to reject it.
The separate payment form now includes the 'Open payment page in a new window' setting, and custom CSS classes can be assigned to the payment button.
Error messages no longer contain markup; the list of unconfigured terminal settings is now displayed to the buyer as a plain text line.
Payment method icons have been redrawn, and the payment block preview in Sites24 has been updated. Cards, SBP, T-Pay, and pop-up widgets now share a unified design. The Bitrix icon is selected at the time of payment system creation; for existing systems, it will remain unchanged, and it can be replaced using the 'Logo' field in the payment system settings.
PostgreSQL support has been added.
Due to the expanded functionality, the module has been renamed to "T-Bank Internet Acquiring Payment Acceptance Pro".
Bank responses are visible in the "T-Bank Operations" tab. A notification containing the code and reason for rejection is added to the order card, and the code is decoded into words: "1051: insufficient funds on the card". Upon update, previous records are filled in.
The result page displays the correct payment status. A successful payment no longer appears as unsuccessful, and while the bank has not sent a status, the page waits for it automatically: with a countdown and up to three refreshes, alongside a link for manual refresh.
The payment type has become a payment system setting. One-stage and two-stage modes can be used simultaneously on the same terminal; an empty value retains the terminal's setting.
The log records the exchange with the bank—what was sent in the request and what the bank responded. This works when logging is enabled; the buyer's signature and contact details do not appear in the log.
Identified vulnerabilities have been fixed.
Other identified errors and inaccuracies have been fixed.
Codes for marking "Chestny ZNAK" in the receipt. If a product has a marking group assigned and codes are entered in the order shipment, the module transmits them to the goods transfer receipt — on a separate line for each unit. FFD 1.2 is required; when there are no codes, the receipt is generated as before.
VAT rates and tax systems are aligned with the bank's current list — 20%, calculated 20/120, and ENVD have been removed from the lists.
Products with a VAT rate unknown to the cash register no longer silently appear in the receipt. The module logs this and sends a notification with the product number so the rate can be corrected in the reference book, rather than searching for discrepancies in the OFD later.
A bug that sometimes occurred when transitioning to the payment page has been fixed: "Malformed salt, only [a-zA-Z0-9_.-]{3,50} characters are acceptable".
Action windows in the order card have become wider, and their height adjusts to the content.
Other minor inaccuracies have been fixed.
The payment system is created during installation. The module creates it automatically and immediately offers to proceed to its settings, where you only need to enter the terminal and password. It is created in a disabled state so that the buyer does not see it before it is configured.
Settings can be migrated from the tinkoff.payment module. If it is installed on the site, the installation offers to create a payment system based on its settings: the terminal, password, and receipt parameters are transferred automatically, and the previous payment system is disabled. Restrictions are transferred via a separate checkbox.
Own icons for each payment method — card, SBP, T-Pay, and pop-up widgets: there is no need to manually select images.
The receipt includes calculation method indicators for 'partial payment and credit', 'transfer to credit', and 'credit payment'.
The "T-Bank Operations" tab in the order card. For each payment, the bank status, the set order status, the confirmed amount, and the sending of the closing receipt are visible. Next to it is the operations log: which notifications were received from the bank and whether they were accepted, what the module did, and who initiated it — the bank, the operator, or the agent. Previously, this could only be found in the log if it was enabled in advance. The log is maintained independently of logging, and the storage depth is configurable.
Rejected bank notifications are visible with the reason for rejection — these explain why the payment "did not arrive".
Two-stage payments no longer appear unsuccessful to the buyer. After reserving funds, the order is not marked as paid, and the result page previously displayed this as an error. Now the buyer sees that the funds are reserved and will be charged after the order is confirmed by the store.
Sending the payment link checks the email template. If it is missing, disabled, or not linked to the order's website, the module reports this immediately instead of a failed send.
Payment status has moved to the module's own table. Previously, it was stored as rows in the site settings and read in full with every module access. During the update, data is transferred automatically.
After installation, a "Go to Module Settings" button is added.
An intermediate status has been added to the successful payment redirection page: Payment accepted by the bank; the status will be updated within a few minutes.
The hold confirmation has been redesigned: an order can no longer appear as paid if the bank failed to debit funds due to any error. If the bank rejects the transaction, the button in the order card displays the actual reason, remains in place, and the attempt can be retried immediately.
Fixed: reserved funds are no longer lost due to connection interruptions. A single connection failure no longer removes the payment from processing; the next attempt will pick it up again.
Discovered vulnerabilities have been resolved.
Security. Payment status verification has been moved from a custom public endpoint to Bitrix's standard service.
Fixed: an order that was not cancelled no longer appears as cancelled. If something blocked the order cancellation after a refund or hold release, previously this was silently lost and a success message was logged. Now the administrator receives a notification.
Fixed: the payment form layout in the Aspro theme — with automatic bank redirection disabled, an unclosed tag broke the page markup.
The onBeforeActionReverse event has been enhanced — the store handler can now override the result of hold release processing, as was already possible for payment, refund, rejection, and authorization.
Refactoring: obsolete and unnecessary module files have been removed.
Failure notifications. The module informs the administrator about issues that were previously visible only in the log: payment amount mismatch, bank notification rejected, closing receipt not sent, hold not released, buyer saw an error instead of the payment form. Delivery is handled by the free "Error Notifications" module (rover.notifier) — via email, SMS, or messenger. Two independent checkboxes on the "Debug" tab: critical failures are sent immediately, buyer errors are grouped.
The hold auto-confirmation agent no longer stops at the first error — previously, a failure on one payment left all others unconfirmed.
Settings now work in editions without "Online Store": the "Debug" tab with logging and notifications is available there as well.
Payment information processing security has been enhanced.
Discovered vulnerabilities have been fixed.
Installation and uninstallation errors have been fixed
One-click payment confirmation. A button 'Confirm payment in T-Bank' has appeared in the order card in the admin panel — for orders with two-stage payment (funds are reserved but not yet debited), there is no longer a need to wait for automatic confirmation via timer or access payment system settings: payment can now be confirmed directly from the order in an obvious way.
Manual sending of payment link. A new button 'Send payment link' — if payment has not yet been completed or ended with an error that can be fixed by retrying, the manager sends the buyer an email with a fresh payment link for the order with one click. The email template includes the amount, order number, and website name, and can be freely edited in 'Mailings' as a standard email event.
Fixed an error in the tinkoff.order.payform component, which caused the buyer to see an empty line instead of a clear error message when payment failed.
— Root certificates of the Ministry of Digital Development are connected
— Enhanced security verification of incoming notifications from the bank
— Other identified security issues have been fixed
— The robustness of the duplicate notification protection mechanism against load has been increased
— A limit on the depth of the stored log has been added (in days) + the log has been moved to a folder with a random name
— Translation into English has been completed
— Notices fixed for PHP 8.2
— Other minor errors have been fixed
— Refactoring
— Separate VAT selection added for deliveries
— Ability to pass VAT directly from the product to the receipt has been added
— A template has been added that displays correctly in the personal account of sites from Aspro
— A setting "Block repeated notifications from the bank" has been added to the module settings; it allows eliminating duplicate receipts when connecting a cash register via Bitrix. Available only for editions with the "Online Store" module
— The setting "Block repeated notifications from the bank" is forcibly enabled for those who installed the module before this setting appeared.
— New VAT values added: 22% and 122/22
— Option "Open payment page in a new window" added for card payment and T-Pay
USER EXPERIENCE
How does this solution work in a real project? Share your experience and help others choose.
There are no reviews of this solution on git.ru yet. Tell us what worked well and what could be improved.
Verified purchaseAdd a key if you wish. A verified review gets a badge, priority placement and more rating weight.
Open to every clientJust sign in to your account. A key is optional; all reviews are moderated.
YOUR PROJECT INFRASTRUCTURE
FROM THE SAME DEVELOPER
Pavel Shulaev
Starting with version 2.0.0, the module supports extension without modifying source code. The list of GeoIP services and their execution order are assembled via the onBuildServiceList event. You can connect custom services from other modules by registering an event handler and returning the full class name of your service. The module provides an API for location determination by IP address.
The Administrative Part Builder is a framework for rapid and flexible configuration of the administration interface for Bitrix modules. The tool fully handles the rendering of the graphical interface and the management of options.
Version 4.0.0: one-click connection to amoCRM without manual integration setup or key copying; a Getting Started page with three steps to the first order; built-in diagnostics with a Fix button and single-file report generation for technical support; automatic verification and repair of the amoCRM webhook to ensure reliable deal stage updates reach the order; simplified profile mode and help…
MORE FOR YOUR WEBSITE
The Sotbit Smart Filter SEO module is designed to increase online store traffic. The tool operates by generating numerous unique pages for smart filters.
SDEK integration module for 1C-Bitrix. SDEK is one of Russia's largest logistics companies, providing courier delivery and operating a network of pickup points. The module connects the online store with the SDEK personal account, offering the following capabilities: Providing customers with delivery options: courier, pickup point, or postmat.
The module is designed for the «1C-Bitrix: Site Management» platform and enables importing infoblock elements, including products, from Excel files. It also supports data loading into Highload blocks.
BEFORE YOU ORDER