Crypto payment integration in 1C-Bitrix: module, setup, webhook

Integrating crypto payments into 1C-Bitrix: where orders get lost

An order is placed, the buyer has sent cryptocurrency and sees confirmation in the network — but in the store it is still “awaiting payment.” The product is not reserved, the email has not gone out, and the manager learns about the problem from the customer.

The order has not been moved to paid — and this is not just status cosmetics: the reservation, shipment, and reconciliation with the accounting system fall apart.

The reason is almost always the same: accepting cryptocurrency on the site is an asynchronous flow.

The fact of confirmation in the network and the notification that the payment service sends to the store are two different events: there is a delay between them, and the handler may be unavailable. If the webhook is lost and there is no repeated status check, the transaction remains in limbo.

Stuck transactions accumulate quietly. Some customers leave without waiting, some write to support — and each such conversation takes up an engineer’s time and trust.

A separate pain is the discrepancy: payment went through in the network, but it is not in accounting, and the period has to be closed manually, using network statements.

Integrating crypto payments into 1C-Bitrix is not closed with a “connect” button, but with a scheme: matching an order and a payment by a unique identifier, idempotent processing of notifications, periodic reconciliation with the payment service, and pre-defined behavior for underpayment, overpayment, and cancellation. Below is how this is arranged and where it most often breaks.

What changes after connection: confirmations, reconciliations, declines

If crypto payment acceptance is built into 1C-Bitrix at the level of order business logic, rather than moved to a separate payment page, the entire flow changes: confirmation comes from the network, the module verifies the amount, recipient address, and required number of confirmations — the order automatically moves to “paid.” The manager learns about payment not from correspondence, but from the status.

The share of confirmed orders grows because the gap between “money sent” and “status updated” disappears. Automatic payment confirmation triggers based on a notification from the network, not a button click.

Crediting time is measured by waiting for the required number of confirmations — the customer sees progress and does not leave the page.

Reducing manual reconciliations is the second effect. Reconciling the wallet with the order table becomes a scheduled task: amounts, addresses, and transaction hashes reconcile, and discrepancies go into a separate list.

Only a few cases remain manual — underpayment, payment from someone else’s address, repeated sending.

Payment acceptance fault tolerance rests on idempotency: a notification may arrive twice, and repeated processing does not create a second order. A retry queue covers node unavailability or response timeout, and unresolved events are stored in a log rather than lost.

The result is that an entire class of failures — “payment went through, order not placed” — disappears. The share of incomplete orders decreases not by persuading the customer, but because every transaction is brought to a final status automatically.

Methods of accepting crypto payments: gateway, direct network, custodial service

In Bitrix, accepting cryptocurrency is not reduced to a “Pay” button: the module creates an invoice, provides the address and amount, and the webhook handler changes the order status — it receives confirmation from the network or from the provider and writes the transaction hash into the order properties.

After that, everything is decided by one question: where the private keys live and who confirms the fact of payment. This determines crediting times, the refund scheme, and the amount of support the team handles on its own.

The difference between the options shows up not at launch, but during refunds, repeated reconciliation, and handling the situation “the order is marked paid, but the transaction did not arrive.” Below are the real alternatives teams choose between.

In practice, methods are combined: the main flow goes through one option, the backup through another, and reconciliation lives as a separate procedure.

In Bitrix, any of them is a module with a webhook handler, a transaction log, and an order-to-hash link; only the key storage perimeter and the scope of support differ.

How implementation proceeds: from cart audit to handover of procedures

Implementation follows a fixed sequence: first we analyze how money acceptance is arranged in the store, and only then connect the cryptocurrency flow.

The order is fundamental — if you start with installing the module rather than auditing the payment flow, scenarios surface where an order goes into assembly without confirmed payment, and the discrepancy is found only from the statement.

Sequence of stages

1. Payment flow audit. We look at which handlers are already connected, where the order status is stored and changed, how refunds, partial payments, and retries are arranged, and what goes into the event log.
2. Payment scheme and approval. We fix the place of crypto payment in the order lifecycle: a separate payment method or a combined one, who fixes the exchange rate, how long the invoice lives, and by what rules it is canceled.
3. Payment module setup. We register the handler in the system, configure the store keys, notification addresses from the payment gateway, network selection, and the correspondence of order statuses to transaction statuses.
4. Payment scenario testing. We run successful payment, underpayment and overpayment, repeated notification, expired invoice, and customer cancellation — separately checking that the status transition triggers once and does not duplicate the order.
5. Testing in a closed environment. We work on a site copy with a test network and gateway sandbox: manual runs plus automated checks for idempotency and lost notifications.
6. Switching to production mode. We change keys to production ones, restrict access by roles, enable logging and notifications about orders that remain in an intermediate status for too long.
7. Handover of procedures. We provide the status scheme, instructions for managers, the procedure for discrepancies, and access to logs.

After handover, your team can add payment methods and handle incidents on its own, without contacting us for every operation.

What remains in the project after delivery: module, procedures, access

After delivery, the project retains not only working code but also a layer that allows the crypto payment integration in 1C-Bitrix to be operated without us. Below are the artifacts the customer receives along with access to the repository and environments.

• Payment module configuration: accepted networks and tokens, confirmation threshold, exchange rate binding, payment waiting timeout, and underpayment behavior are moved into administrative settings rather than hardcoded.
• Payment flow scheme: from invoice issuance to order crediting — all statuses, branching points, and the place where protection against repeated processing of the same gateway notification is located.
• Access policies and roles: who sees acceptance details, who changes module settings, who exports the log; rights are separated on a least-privilege basis and configured identically in the test and production environments.
• Operation logging: every event is written with the order number, amount, transaction identifier, and status — any disputed operation can be reconstructed from the log.
• Incident handling procedure: step-by-step scenarios for a stuck payment, amount discrepancy, and network node unavailability — with response times, responsible parties, and escalation points.
• Set of checks and rollback procedure: acceptance scenarios on the test network, deployment instructions, and rollback to the previous module version while preserving settings.

Case study: share of incomplete orders and manual reconciliations — before and after

A store on 1C-Bitrix accepted payment in cryptocurrency, but payment confirmation remained manual: the manager received a notification from the payment service by email, reconciled the amount and wallet address with the order, and only then moved it to the “Paid” status.

At night and on weekends, the queue accumulated until morning, and some buyers managed to place the order again or left.

What it was before

Out of 1,200 orders with cryptocurrency payment, 214 got stuck at the confirmation step — 18% of orders in a pending state. Manual reconciliation took an average of 7 minutes per order, and discrepancies due to network fees were handled separately.

What was changed and what happened after

We connected a callback notification from the payment service: confirmation arrives at a separate address, the signature is verified, and the order status changes automatically. Only the exception queue was left for the manager — amount mismatch and repeated notifications.

The remaining 2% are payments with low network confirmations: they are not lost but wait for the required number of confirmations without human involvement.

What to do if crypto payments are already partially connected

Partial crypto payment connection is a common case: the module is already installed, and one or two payment methods work.

The danger here is not incompleteness but discrepancy — some orders hang in the waiting status, the manager closes them manually, and a repeated network notification processes the payment a second time.

Before migrating the payment flow, we record the current state: which handlers are called, where the order-transaction link is stored, and by what criterion an order is considered paid.

Usually only the confirmation layer has to be rewritten — the catalog, cart, and order history remain untouched.

We structure the work order so that payment acceptance does not stop: we enable the new handler in parallel with the old one for one payment method and compare the results, then switch the rest after a full match.

Accumulated orders are not recreated — we add the “order — transaction” link to existing records, and mark manually closed ones so automation does not touch them.

The native functionality of 1C-Bitrix is extended, not replaced: the payment page, emails, and reports remain in place; only the payment confirmation layer changes.

Limitations and disputable scenarios: when crypto acceptance is not suitable

A crypto payment is irreversible at the network level: a transaction cannot be revoked or canceled, so a refund is a separate outgoing transfer from your wallet. Before launch, it is worth answering whether there is an available balance for such refunds and who signs them.

If the share of cancellations after payment in the business model is significant, crypto acceptance will add manual operations rather than remove them.

The second limitation is confirmation time. Until the network has accumulated the required number of confirmations, the payment is not considered complete: under high load this is tens of minutes, and in some networks — hours.

During this period, the order hangs in the waiting status, the product is held in reserve, and the customer writes to support. A working solution is your own waiting timeout and automatic cancellation with reservation release.

The third layer is accounting. In 1C-Bitrix, a payment arrives via webhook, and it must be linked to the order, with the amount and exchange rate recorded at the time of crediting; otherwise revenue and inventory accounting will not reconcile.

Separately, there are provider-side checks: an address or coin may be flagged as suspicious, and funds are frozen on its side.

Let’s discuss the task: we will come back with an estimate, scheme, and work plan

To come back with an accurate estimate rather than a range “from and to,” we need to see the current payment acceptance flow.

Describe how the 1C-Bitrix store is arranged: which payment methods are already connected, where orders are stored, and whether there is an external service that receives notifications from payment gateways.

On the customer side, it is enough to prepare:

• a list of cryptocurrencies and networks whose acceptance is needed for implementing crypto payment acceptance;
• access to the administrative panel and the site’s test environment;
• a description of the current order path: from cart checkout to payment status change;
• wallet details or confirmation that they are issued by the payment provider;
• accounting requirements for documents and exports for crypto operations;
• contact of the engineer who currently supports the site — to coordinate core changes and updates.

In response, we will provide:

• an estimate of labor costs by stage and an overall work plan with timelines;
• a payment flow scheme: cart, invoice, network confirmations, webhook, order status change;
• a list of modules and changes required, with an assessment of impact on future platform updates;
• a procedure for checking on the test network and rollback scenarios if confirmation does not arrive.

You can discuss the task in a convenient format: correspondence, a call, or a review based on your scheme. The more accurately the current flow is described, the fewer assumptions will remain in the work plan.